From Dogeek on Reddit:
Save compatibility
You heard me. Save compatibility is coming! It took me a while to figure out a way to actually achieve this, but this seems foolproof. Due to the new system, 0.19.0 will obviously not be compatible with 0.18.6 saves (sorry, one last restart!) but later versions will be compatible.
How does it use to work?
Saving was really never such a big issue, but loading was. You see, the system that was in place before used a function to restore the machines to their loaded state, and its location arrays, pregancy, all that stuff. The machines were restored with direct attribute accessing. This is bad, because every state machine is very linear, in that it needs to track what state it is now, what trigger does it respond to, and what state it can be in next. All in all, if any of these objects had their reference broken (by a reload for instance), the machines would break. On top of that, if the machine was changed significantly, loading its state from a save would also break, because the "current state" in the save file would not be a possible "current state" in the new machine.
How does it work now?
Instead of reloading the machines and setting all of its attributes directly, like the old system used to do, the new system uses a brand new object that is instanciated only at the start of the game (in a new game). That object is a sentinel, in that it will never change, it will always be the same and never be reset. Now, whenever a trigger is successfully activated on a machine (meaning that the machine advances to the next state), that trigger is added to a list of triggers for that machine, that is stored in that fsm_data object. Whenever the game is loaded, progress is restored by first :
The whole process is timed, and printed out to the console, to help us get some debug info.
On top of that machines, states and triggers are now instanciated at init time. That means that the machines, states, and triggers will be reinstanciated when you start the game, and won't be stored in the save files any longer, reducing the amount of bloat that stacks up in there, it also adds the small benefit that jenny's choices (dominant/submissive) will now apply when viewing her scenes in the cookie jar.
This new system has a bunch of benefits. As I said, it achieves save compatibility, at least to a degree that means that the vast majority of changes we make to the codebase won't break saves anymore. It also allows for smart restoration of the saves. Let's say you progress Roxxy up to her end state, well that is saved as a list of triggers, and if we add some states in the middle of her machines, the loading system will place roxxy right at the beginning of her new content automatically, which also means that you'd have to redo the rest of her story as well (sorry, I'm a coder not Gandalf the White).
You must be registered to see the links
Save compatibility
You heard me. Save compatibility is coming! It took me a while to figure out a way to actually achieve this, but this seems foolproof. Due to the new system, 0.19.0 will obviously not be compatible with 0.18.6 saves (sorry, one last restart!) but later versions will be compatible.
How does it use to work?
Saving was really never such a big issue, but loading was. You see, the system that was in place before used a function to restore the machines to their loaded state, and its location arrays, pregancy, all that stuff. The machines were restored with direct attribute accessing. This is bad, because every state machine is very linear, in that it needs to track what state it is now, what trigger does it respond to, and what state it can be in next. All in all, if any of these objects had their reference broken (by a reload for instance), the machines would break. On top of that, if the machine was changed significantly, loading its state from a save would also break, because the "current state" in the save file would not be a possible "current state" in the new machine.
How does it work now?
Instead of reloading the machines and setting all of its attributes directly, like the old system used to do, the new system uses a brand new object that is instanciated only at the start of the game (in a new game). That object is a sentinel, in that it will never change, it will always be the same and never be reset. Now, whenever a trigger is successfully activated on a machine (meaning that the machine advances to the next state), that trigger is added to a list of triggers for that machine, that is stored in that fsm_data object. Whenever the game is loaded, progress is restored by first :
- Preloading the fsm_data object, to add any new keys in its internal dictionnary (keeps errors out if new data, like the dating system, need to be saved there)
- Resetting the machines to their initial state, i.e. with their state being in their original delays, with the machines in their start state, etc.
- Executing every trigger stored in the internal dictionnary for every machine, effectively advancing the machine to the state you saved it in.
- Deserializing the PregnancyManager() and OutfitManager() objects into the machine
- Restoring the machine vars as saved in the fsm_data object.
The whole process is timed, and printed out to the console, to help us get some debug info.
On top of that machines, states and triggers are now instanciated at init time. That means that the machines, states, and triggers will be reinstanciated when you start the game, and won't be stored in the save files any longer, reducing the amount of bloat that stacks up in there, it also adds the small benefit that jenny's choices (dominant/submissive) will now apply when viewing her scenes in the cookie jar.
This new system has a bunch of benefits. As I said, it achieves save compatibility, at least to a degree that means that the vast majority of changes we make to the codebase won't break saves anymore. It also allows for smart restoration of the saves. Let's say you progress Roxxy up to her end state, well that is saved as a list of triggers, and if we add some states in the middle of her machines, the loading system will place roxxy right at the beginning of her new content automatically, which also means that you'd have to redo the rest of her story as well (sorry, I'm a coder not Gandalf the White).
