Print

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

[sheepish_gorilla]

Although officially none of the updates since 40.x are savegame breaking, I'm now noticing a lot of strange behavior (just had a ragequit being tired of it all). In the 44.12(-r04 LNP) I started to continue a save from 44.05. Yet I'm having a lot of inexplainable problems. Mostly around stockpiles.

Example 1: there is copper armor on the ground > I have goblinite stockpiles set up correctly to accept these (0 wheelbarrows, accept from anywhere) > I have 20 idle dwarfs, while having autohauler acitvated. Still these items are left alone for over 6 months.

Example 2: I had furniture planned, waiting for masterful doors and coffers. Instead, suddenly there are iron doors and coffers built on those spots. I did not have any of these in storage. when deconstructing them, they reduced to iron bars :S

Anyway, so my question is: is this commonplace and should I just start a new fortress? Or do others experience these problems even outside of the updates, so a restart doens't guarantee these problems to be fixed? (I've put a lot of effort in finally getting a perfect fort with all the stockpiles, hauling routes and custom workflow recipes set up, I'd hate to start over. But if I must, I will. But in that case it might be useful to know whether these problems will still occur even when starting a fresh fortress on the last update)

[Bumber]

Both examples involve DFHack features.

For Example 2 in particular, the issue is that iron is the default undefined material. DF took those DFHacked "planned" furnitures and interpreted them as real ones.
For Example 1, are your dwarves' hauling labors even enabled? Does your new version have autolabor active?

[sheepish_gorilla]

Hmm,  you're right, they seem more of a DFHack thing.

in the stockpile example 1, I have autolabor disabled, but autohauler enabled. So there were 40-ish dwarves with hauling enabled, yet still a lot of them were idle. Since yesterday I have deleted the old stockpile and created a new one (saving&loading the original stockpile settings), and suddenly it was being used again. (I'm really hoping I don't have to repeat this for the other stockpiles )

In example 2, when I loaded up the old save, the planned furniture wasn't built in metal right away, the metal doors were built in the months after continuing. But after removing them and planning new furniture with the original settings (no material specified, just a minimum quality of masterful), it worked again.

[PatrikLundell]

A common reason for stockpiles failing to receive items is fat fingering them to accept from links only.

[Saiko Kila]

You got your answer, but generally it depends. I have saves from 0.40 which will crash the game if I try to load them into 0.44.12, and have saves which load without problems (including from the same fortress, but older or never). However, the internal representation of fortress when examined with dfhack is different - the older the original save version, the more of data is represented as "userdata" in dfhack, instead of proper data types, which means it can't really be interpreted; DF stores the data differently after conversion than for "native" games. Which can cause problem with scripts and plugins, because some data is not accessible to them.

The problem with need to rebuilt some stockpiles or designations is also one I've encountered. It was also true for older versions.

[sheepish_gorilla]

Interesting! even without my mentioned problems, the way you describe old data is read, it seems like that causes chunks of unusable data in memory (=lag) so still useful to know!

[Saiko Kila]

Interesting! even without my mentioned problems, the way you describe old data is read, it seems like that causes chunks of unusable data in memory (=lag) so still useful to know!

I wouldn't say they are unusable - they are usable by the game itself (apparently not always 100% correctly), but often not by dfhack. DF reads old data, but after conversion keeps it in partially different format, which may cause some problems, sometimes.

I don't think that Toady tests the game thoroughly with saves made in all previous but still formally compatibles versions, because that would be quite tedious. I appreciate that he still maintains this compatibility for so long, because this allows me to run favourite forts in never versions, but most other similar games do not maintain such compatibility, since it's much work (the only one I know which maintains long-term compatibility is UnrealWorld).