This PR enables the builtin save backup system to work properly.
There were two main pieces missing on our end to make this happen:
First, when a new cycle save is persisted to file, the game writes the save data twice to the sram buffer and uses double the "page" size of a regular new cycle save. This translates into sram flashing both the main save and the backup save in one operation.
I've added a check within our save manager write method to check if the "page" size is this "special" value, and if so, perform a second save operation to the matching backup slot.
The second piece is that the game computes checksum values on saves and performs multiple check points. The file select menu does the following:
If a checksum fails, the save is discarded
If the main save and the backup save have mismatching values, the backup save is updated to match the main save
We were hard coding the checksum calculation to 1 which meant that backup saves where not created/updated. Additionally, in some of the variables that the game compares with the checksum, a value of 1 is used to indicated no backup save exists.
I've reverted the checksum calculation back to vanilla so that all this logic can run properly again. Because the checksum can be invalidated if someone modifies their save file externally, or a save migration changes the save, I've opted to always recompute the checksum upon parsing the save json. This way the game never thinks the save is "invalid". I think this is a worthy compromise to not make editing save files "painful".
This PR also expands the json parsing/typing try/catches to handle a few move edge cases with invalid json files.
This PR enables the builtin save backup system to work properly.
There were two main pieces missing on our end to make this happen:
First, when a new cycle save is persisted to file, the game writes the save data twice to the sram buffer and uses double the "page" size of a regular new cycle save. This translates into sram flashing both the main save and the backup save in one operation.
I've added a check within our save manager write method to check if the "page" size is this "special" value, and if so, perform a second save operation to the matching backup slot.
The second piece is that the game computes checksum values on saves and performs multiple check points. The file select menu does the following:
We were hard coding the checksum calculation to
1which meant that backup saves where not created/updated. Additionally, in some of the variables that the game compares with the checksum, a value of1is used to indicated no backup save exists.I've reverted the checksum calculation back to vanilla so that all this logic can run properly again. Because the checksum can be invalidated if someone modifies their save file externally, or a save migration changes the save, I've opted to always recompute the checksum upon parsing the save json. This way the game never thinks the save is "invalid". I think this is a worthy compromise to not make editing save files "painful".
This PR also expands the json parsing/typing try/catches to handle a few move edge cases with invalid json files.
Build Artifacts