Bay 12 Games Forum

The game seems to save all your seeds in \Dwarf Fortress\gamelog.txt, which might help as a workaround.

Quote from: Orange-of-Cthulhu on December 08, 2022, 07:41:34 am

My personal non-verified belief is that trees and junk amount to a lot of FPS death.

I'm pretty sure all items are simulated also regarding their tempature and dryness/wetness and so on. So if you have thousands and thousands of items like avocado pits and xxxsockxxx and so on, it's got to use computing power.

I started atom smashing junk straight from the z-screen, where you can really have thousands and thousands of leftover junk items generated for instance by avocados. Some plants generate a waste item, you also get peach pits for instance. And you can easily have 10K of those lying around sucking computing power without even being aware of it.

Another belief I have is that TREES slow down the game. I read somewhere the game simulated the growth of branches and twigs and so on, so a single tree must take up computing power.

I had some forts that were in heavily forested areas and grind slowly to a half, destpite the population not growing a lot. Since then I've taken to do very heavy-handed forest management, preventively clearing most of the surface from trees - and it seems to work.

No, no, this is pretty verified. The slowest parts of a 6x6 fort I ran for 25 years were:

1. some sort of map activity that I'm like 50% sure was tree/plant growth
2. temperature

So this is, in fact, borne out by the data.

But this can be mitigated massively by just playing on a smaller embark.

You mix up mods and utilities. These are two very different things. And, regardless, there not time to implement even half of what ought to be implemented of the basic functionality, so any utility functionality that makes it in would have to be very low hanging fruit (a sand indicator might be such a thing, but don't count on it, especially given the bugs associated with that area of the code: touching the code means having to decide on implementing something that's known to be buggy, or address the bugs, which takes time that's not abundant).

There are a number of utilities that a lot of people use, and a fair bit of that can be considered cheating by at least some players, and there's a significant number of players that don't use any utilities at all. An example that's been discussed is management of labor, where Toady as an aversion to spreadsheet type functionality (e.g. Dwarf Therapist), instead leaning towards internal logic (there are a couple of DFHack plugins for automatic reassignment of labor based on what jobs the logic think needs doing). If one of those approaches is taken while blocking the other, a significant portion of the existing players will be unhappy with the decision (I would be if the one that's wrong for me is chosen).

There are no mods that "everyone" use. There are popular mods that quite a few people use, but, just as with tile sets, there are wildly different preferences. I'd be rather surprised if even half of the players are using any one mod (and suspect not even half of the players use any proper mod at all).

The plan includes mod support, i.e. support to add/remove mods in some easier fashion than the current one, which is the normal way to deal with mods. The game strives to make as much of it as possible moddable, to gradually make more and more of the definitions available as RAW files.