dfhack
dfhack copied to clipboard
DFHack
Json persistent data format
Provides an API for saving persistent data in a dfhack-specific .dat file in the save game folder. Based on, but meant to replace, pull request #927. This one doesn't convert all of the histfig-based persistent data, but converts autogems and stockflow as examples of the C++ and Lua API, respectively.
Other than the fact that I'm incredibly late finding the time to finish up my old PR what's the advantage of this one over the old one?
The C++ API is taken directly from your original PR, just cleaned up a bit, which is why I left your name on that commit.
The autogems conversion no longer changes the plugin's behavior. To be fair, I haven't rewritten any of your other plugin conversions yet, and probably won't until I see whether this goes in.
The Lua API now exposes the whole tree, not just the persist-table part, which made the stockflow conversion possible. It's also significantly different; numbers and strings are now converted to Lua numbers and strings, .empty can now be used as a key, booleans and non-empty tables can be used as values, and an array interface has been added. The __call and __pairs interface methods are entirely new, though _children has been kept for persist-table compatibility.
The persist-table integration no longer relies on a separate plugin. Something about scripts depending on a potentially unloaded plugin was bothering me. It also avoids keeping a reference to the root table in Lua memory, which would have been problematic when a world gets unloaded.
Finally, breaking it up into a series of logical steps felt nicer. Granted, I have considered breaking the presave event portion out of the C++ API, but even at 144 lines that first commit is much easier to understand. Except for the Filesystem.h change; I have no clue whether that's important for anything here, but it was in the original pull request, so in it went.
So I realize this has been sitting around for a long time, but I think it's a good idea and would prefer it to #927. Originally I thought these were for user configuration, so I was hesitant about them, but as a replacement for the current (mostly user-inaccessible) persistent API, I think it's fine.
My only real concern is that one bad tool could corrupt the entire persistent "tree"/file. It might be possible to make each current key in the root tree a separate file.
I'll try to tackle this soon (maybe after r2), assuming nobody beats me to it, and handle that change as well as fixing autogems and whatever else needs fixing (autogems looks like the only important file with merge conflicts).
This PR would still be welcomed, but it would need updating for the current code base. I tagged it in an issue so we don't lose track of it, but I'll close this PR for now
