Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Maggarg - Eater of chicke]

This is for suggestions that you would like to see, but aren't sure that someone else has posted or if they can be implemented.

For example, I'd like engravable buildings like walls and stuff, and because you can't really engrave wood, allow it to be carved.

[jspace]

Hey, this was just the thread I was looking for.

I've got a good one: multithreading.
However, it's a challenge to implement for most programmers and it might require a huge rewrite. But, it would let some people play on something like a laptop which doesn't normally have great single threaded performance.

Wishful thinking I suppose.

PS. Is it sad I want a faster PC to play this game?

[Ixoran]

I've got one.
Enemies should generate a "Threat range" of many tiles so dwarves don't get themselves killed trying to loot other dead enemies...

Ie: an enemy should "Threaten" ten tiles around him and civilians will not enter this threat range.
Item's in a threatened area will be treated as forbidden for pathing.

Maybe when run time options are made, we can get an auto forbid for all items in this threat range?

hmmm?

[Kagus]

I'll post here since I'm feeling exceptionally lazy right now and I don't want to use the search button.


We currently have images on items made from leather, bones, shell, wood, and all sorts of other hard materials, but what about using dye to paint on images?  Then we'd be able to get some seriously annoying strange moods that demand dye along with all the other stuff...

[perilisk]

I've got one.
Enemies should generate a "Threat range" of many tiles so dwarves don't get themselves killed trying to loot other dead enemies...

Ie: an enemy should "Threaten" ten tiles around him and civilians will not enter this threat range.
Item's in a threatened area will be treated as forbidden for pathing.

Maybe when run time options are made, we can get an auto forbid for all items in this threat range?

hmmm?

I was thinking something like this, but then I thought it makes more sense to just autoforbid any items dropped or spawned by the death of a creature, excluding vermin, creatures struck down in a butcher's shop, hunter's kills, etc. Whatever killed it, which might not even be a creature, could still be ready to kill the next dwarf, or have just moved several tiles closer to the civilians. Better to let the player intervene once the danger is determined to be over. Then again, if players forget and get a lot of miasma that could be annoying, so the threat range makes more sense there. Archers would have a huge threat range, though.

It would also be nice to explicitly toggle outdoor hauling for dwarves; I have plenty of peasants whose lives I can risk once we start getting goblin ambushes, but I still want my legendary crafters to bring things to their shops. We do have some options to make life easier, and the burrow concept will help a lot, but I'd still like dwarves who can haul to and from anywhere, so long as somewhere is in the safety of the fort.

On a sort of quasi similar note, it would great if we could designate Security Breach zones, that would be treated as "outside" as far as Orders are concerned. The entrance dance is less of an issue if you make it happen well beyond the gauntlet of bridges, traps, siege engines, archer towers, etc.

[Draco18s]

I've got a good one: multithreading.

Toady said he didn't understand multithreading and has no interest in trying to multithread DF.

PS. Is it sad I want a faster PC to play this game?

No.

[Drakale]

More random insanities than get naked and die of hunger.

Examples include: Pyromania, Schizophrenia, Agoraphobia, Autism, Dementia, Delirium,  Obsessive-Compulsive, Depressive, Delusionnal
, Arachnophobia ( in fact, in the DF world it is pretty sane to fear spiders)


A legendary dwarf turned pyromaniac would spell doom for your fortress.

An engraver turned Obsessive-Compulsive could want to engrave purring maggots on every single walls of your fortress.

... Drakale goes insane!
Drakale is delusionnal!
Drakale starts posting on the internet.

[Surma]

Pyromania wouldn't work currently because the dwarves don't understand that ‼items‼ currently, it's rather easy to destroy an entire fort due to an unfortunate dwarf getting lit on fire through various means.

Obsessive-Compulsive is more or less in... I've seen far too many engravings of 'this is an engraving of a dwarf and cheese. The dwarf is raising the cheese'

Depressed -is- in, what do you think melancholy is currently?

As for Autism, that's usually something a person (dwarf in this case) is born with, not something that can be gained from a bad mood.

The rest are interesting, the phobias however would probably be something a Dwarf has from birth, similar to the likes/dislikes.

So that leaves schizophrenia, dementia, delirium, and delusions. Which I view as perfectly acceptable insanities.

For example, I'd like engravable buildings like walls and stuff, and because you can't really engrave wood, allow it to be carved.

I fully endorse the above.

[Granite26]

I've got a good one: multithreading.

Toady said he didn't understand multithreading and has no interest in trying to multithread DF.

Modern compilers do most of the work for you on this.  It's a huge speed improvement, plus it's almost required for any sort of interface while the world is running

[LeoLeonardoIII]

They should include some way to find out whether someone else has posted the same thing I'm about to post.

Some kind of method to sift through all the other posts ... you could probably have a text input box and the program would try to match what you type into it against all the text ever posted on the board.

You could call it a Sift Box! And put it somewhere easy to spot. Maybe the upper right corner of the screen, as a standard, so everyone would know where to look no matter whose website you were on. And programs on your computer could put their Sift buttons on the upper right, too.

This is going to be so sweet, I'm emailing Microsoft right now.

[Mikademus]

I've got a good one: multithreading.

Toady said he didn't understand multithreading and has no interest in trying to multithread DF.

Modern compilers do most of the work for you on this.  It's a huge speed improvement, plus it's almost required for any sort of interface while the world is running

The topic of multi-threading comes up every so often. And no, modern compilers don't take care of multi-threading issues for you. Though you can win great efficiencies by proper and suitable multi-threading architecture, this is most so when in a orthogonal architecture, say where physics calculations, terrain loading, pathfinding, etc are relatively independent on other aspects.

Theoretically, DF would be very amenable to this: pathfinding and water updates, etc, could be on threads. However, Toady has said he doesn't want multi-threading, and this very likely means that the code base isn't prepared for it. And there is nothing that will kill any app as much as trying to retrofit unsuitable code with threads.

[jspace]

The topic of multi-threading comes up every so often. And no, modern compilers don't take care of multi-threading issues for you. Though you can win great efficiencies by proper and suitable multi-threading architecture, this is most so when in a orthogonal architecture, say where physics calculations, terrain loading, pathfinding, etc are relatively independent on other aspects.

Theoretically, DF would be very amenable to this: pathfinding and water updates, etc, could be on threads. However, Toady has said he doesn't want multi-threading, and this very likely means that the code base isn't prepared for it. And there is nothing that will kill any app as much as trying to retrofit unsuitable code with threads.

I did mention(or at least alluded to) that it likely require a huge rewrite. It really is something that needs to be implemented right away. Development on this started what, 2002? 2003? No one had multicore systems back then. I think it could be done, but after everything else has been finished. Then again, games like this are never really finished are they?

[Neonivek]

In the end ALL speed issues hillariously will be moot

Because in the years it will take dwarf fortress to actually come out in full... everyone here should have a computer that could run multiple Dwarf Fortresses in the most laggy of situations at once without noticing slow down...

At least if I understand the advancement of computers correctly...

[Mikademus]

I did mention(or at least alluded to) that it likely require a huge rewrite. It really is something that needs to be implemented right away. Development on this started what, 2002? 2003? No one had multicore systems back then. I think it could be done, but after everything else has been finished. Then again, games like this are never really finished are they?

It does not HAVE to be rewritten. It would probably BENEFIT from a well-done implementation of threaded execution, but that's and advantage, not an essential necessity. Now, I just want to present you with reality for a second. Toady has said he is not the best programmer. That says two things: his code probably isn't structured very well, and (2) he has most likely been learning while coding. Given that the DF code probably is a huge pile of mixed pasta weighing in in the multiples of 100KLoC range, do you still think is is reasonably or even possible to implement what you're asking for? And don't ask for "but just add a thread for new stuff" - you will not gain anything from MT unless it is implemented thoughtfully!

[Kholint]

Because in the years it will take dwarf fortress to actually come out in full... everyone here should have a computer that could run multiple Dwarf Fortresses in the most laggy of situations at once without noticing slow down...

Ironically that's *exactly* why multithreaded programming is such a sought-after thing, especially when it comes to DF.
Moore's law won't hold- we can't keep whiling away the years watching our gigaherts climb steadily higher. I wouldn't want to make any predictions myself (we all know how scientists in the 50s imagined we'd be sitting in computers the size of mountains today ), but as a very vague estimate just to give you some idea of the problem, certain sources say the limit might be 10ghz per processor. That's not that far off from where we are right now.

In essense, there is a limit to how complex DF could potentially get (and how capable our PCs are of running it), because, assuming we don't find some wonder technology that lets us keep pushing our single core processors faster and faster, there'll be an upper limit on how horribly hot things get inside our poor little circuits.

It would be worthy to note that multithreading doesn't always require a ground-up implementation. A decent amount of the speed increases and benefits can be felt just by adding it in subtly here and there on the very fringes of the program. It's not nearly as good as a ground-up approach but it's a lot more practical!

Just as a note: I'm not trying to defend the supposed urgent need for toady to implement multithreading in DF. But I'm also not defending further bad design choices (going strictly single threaded) just because there have been bad design choices in the past (apparently unstructured, messy code). :p