DFHack
Persistent JSON
Replace histfig-based persistent data with json-based persistent data in a way that's efficient and automatically converts old histfig data to json for old saves
@lethosor Please check that this works on OSX.
edit: Once it compiles on travis, that is.
There's a bunch of the braces-on-the-same-line-as-statements style here too - I don't mind it myself (I tend to use it for other things), but we do have something about that in Contributing.rst...
Yes: "Opening and closing braces on their own lines or opening brace at the end of the previous line." So either style is explicitly allowed. Granted, my eye twitches at the braceless if statements, but that's not mentioned at all.
Overall, my worst objects are to the behavioral changes in the plugins. Migrating persistent data to the new system could have been done without making half of them auto-enable themselves. In that vein, I'm wondering if we can salvage this by splitting it into multiple commits: https://github.com/eswald/dfhack/commits/json-persistent
Oh, sure enough. I must have missed that change (359d739c8d624bc6a0a4145d5a55785ae95b6ed6).
It's not supposed to change behavior of persistent enabling. I merged the two variables because it was confusing to have two.
It is likely I will never finish this. If there's another one that does the same thing, such as https://github.com/DFHack/dfhack/pull/1402 or https://github.com/DFHack/dfhack/pull/955, and it is otherwise ready for merging, I would not be at all offended if that one were used and this one were closed. I don't remember how much work was left to be done before this one would be ready. If the same functionality can be achieved with less effort than completing this version of the feature, then that's a better way to do it.
Hi! Thanks for checking in. My plan is to get #1402 in for now, since it's fairly compact and addresses the issues of keeping data in fake histfigs (which can't handle binary data and is truncated at 16KB, among other things). It also keeps the existing API more or less intact for users of it, from what I can tell, which makes it less painful of a transition. Hopefully we can come up with a new JSON-based storage/config API that fits all of our use cases at some point. This PR and #955 do have useful things in them, though. I'll see if I can manage to get some of those in once I've dealt with this.
I remember the hardest part was making lua interface well with this, replacing a certain lua file with an implementation in C++, so that would be a good candidate of what to take from this PR. I remember I did convert ALL plugins to use the new system, even though it was only a small optimization in size of DF saves, mainly just to illustrate how it's done for new plugins. There may have been some minor changes in plugin behavior but those were unintended.
It was also nice to have operator[] stuff for persistent data, but I think that was done for me by the json stuff we already had? I forget.
I thought I remembered doing a little extra stuff that I hadn't yet pushed, so I checked. It looks like I just deleted a comment in EventManager.cpp and uncommented if ( !World::isFortressMode() ) return CR_OK in autogems.cpp. I'm sure that can safely be thrown out.
That's all the summary information I can remember that might be useful for salvaging part of this.
I tagged this PR in an issue so we can keep a reference to the cpp-based persist-table, but since it is not likely to happen anytime soon, I'll close this PR
