FunkinCrew
Game's save data reset in some circumstances (when opening old versions of the game?)
Issue Checklist
- [ ] I have properly named my issue
- [X] I have checked the Issues/Discussions pages to see if my issue has already been reported
Platform
Itch.io (Downloadable Build) - Windows
Browser
None
Version
0.5.2
Description (include any images, videos, errors, or crash logs)
I was playing the new patch. Everything was fine. My settings and scores were saved from previous versions of the game no problem. However, I closed out of the game and accidentally booted up an older version of the game (0.5.0). It for some reason was completely silent, as the volume was set to 0. All of my key binds were reset. All of my scores were reset. The new erect songs said the 'New' text on them. I thought nothing of it at first. Maybe if was just an error with the newer data mixing with old versions. But when I went back to the current patch (0.5.2) everything was reset there too. It wiped my save file entirely. I had to replay weekend 1 to access the Pico songs again, and even their scores were gone too. I did a test, and this happened every time I opened the old version. It just resets everything. I don't think there is any way of getting my scores back, but if anyone has any ideas, I'm all ears.
Steps to Reproduce
- Open an older version of the game (pre 0.5.2)
- Discover that your saves are now fucked
Yes, I know that someone reported a similar issue, but they just closed their game, and it happened. My problem seems to be reproduceable.
This bug was also mentioned in a comment https://github.com/FunkinCrew/Funkin/issues/3524#issuecomment-2408637532
I had this happen to me too while testing something, but I didn't think too much of it since I usually don't downgrade and just assumed this was a normal consequence of downgrading versions. I was thinking of suggesting an enhancement of adding a warning that playing on older versions could corrupt save files by detecting if the save file is from a newer version or not, but this also seems like a good place to mention it.
to prevent all data from being deleted due to an update there would be 2 ways: the game creates 2 separate saves, if the first one breaks the second one must not be modified and the save remains intact. prevent the file itself from breaking even if I think it could be complicated (im not a developer)
New versions should start telling users to back up .sol files...
New versions shouldn't wipe people's save data.
Also, I tried testing this and wasn't able to reproduce it just by downgrading, so I'm not sure what exactly happened here. Can anyone test and see if they can reproduce it themselves?
I was able to reliably wipe my save data by simply opening the GitHub release of 0.5.2.
New versions definitely shouldn't be wiping save files, but it's always good to help people become aware in case a save wipe bug escapes somewhere! If not a warning, it would be good to at least implement a backup save system, as someone suggested.
New versions should start telling users to back up .sol files...
New versions shouldn't wipe people's save data.
Also, I tried testing this and wasn't able to reproduce it just by downgrading, so I'm not sure what exactly happened here. Can anyone test and see if they can reproduce it themselves?
I'm not sure if this would produce different results, but I downgraded from 0.5.2 to 0.5.0. and it wiped it. Not sure if that's what you did or not, but just wanted to let you know.
I was able to reliably wipe my save data by simply opening the GitHub release of 0.5.2.
I have not been able to wipe my save data reliably, by using the Github or the Itch release.
Here I show my save file on the itch.io downloaded copy of 0.5.2 Then, I open up the 0.5.2 GitHub Windows Release build and my save file is wiped. (I opened up 0.5.2 again afterwards and all the ranks were gone)
https://github.com/user-attachments/assets/49f37c5f-013c-4934-b5fd-9ed752d81fb0
Here I show my save file on the itch.io downloaded copy of 0.5.2 Then, I open up the 0.5.2 GitHub Windows Release build and my save file is wiped. (I opened up 0.5.2 again afterwards and all the ranks were gone)
there.goes.my.save.mp4
I wonder, since the GitHub release is technically a debug build (see https://github.com/FunkinCrew/Funkin/issues/3672), does the game output an error (or anything, really) in the console when attempting to load the save before wiping it?
I wonder, since the GitHub release is technically a debug build (see #3672), does the game output an error (or anything, really) in the console when attempting to load the save before wiping it?
I've tested it and the traces for both release builds and those builds are the same.
That's because despite GITHUB_BUILD define setting FEATURE_DEBUG_FUNCTIONS, FEATURE_LOG_TRACE is only enabled if the build is explicitly a debug one.
https://github.com/FunkinCrew/Funkin/blob/09b42f3f08076da07be91fd897c8e36c4a4f49c0/project.hxp#L476-L477
~~I also got my data wiped but I've fortunately backed it up.~~
Running 0.5.0 (last version to have traces enabled) also wipes my save but I've noticed that running it twice shows different logs.
When wiping data
source/funkin/save/Save.hx:46: [SAVE] Loading save... source/funkin/save/Save.hx:837: [SAVE] Loading save from slot 1... source/funkin/save/Save.hx:846: [SAVE] Save data is empty, checking for legacy save data... source/funkin/save/Save.hx:953: [SAVE] Checking for legacy save data... source/funkin/save/Save.hx:958: [SAVE] No legacy save data found. source/funkin/save/Save.hx:856: [SAVE] No legacy save data found.
When running again
source/funkin/save/Save.hx:46: [SAVE] Loading save... source/funkin/save/Save.hx:837: [SAVE] Loading save from slot 1... source/funkin/save/Save.hx:863: [SAVE] Found existing save data. source/funkin/util/VersionUtil.hx:64: [SAVE] Version data repair not required (got 2.0.5)
It seems like it thinks there's no save data so it just writes default data on top of the old one? I can't tell for sure just from these logs.
It looks to me that something was changed about the save system in 0.5.2 that makes it unreadable to older versions. This save wiping will always occur unless people are moved to a patched 0.5.3 that reverts this change.
So I've been debugging this and apparently there's an error that doesn't get properly handled when parsing the save data back into objects. I've added a trace and this is what it's throwing: Enum not found funkin.ui.debug.stageeditor.StageEditorTheme
So, somehow the new stage editor accidentally broke save loading in older versions.
Confirming this also happens with versions older than 0.5.0, like 0.4.1.
I accidentally triggered this bug and I haven't been backing up my .sol file. Whoops.
So I've been debugging this and apparently there's an error that doesn't get properly handled when parsing the save data back into objects. I've added a trace and this is what it's throwing:
Enum not found funkin.ui.debug.stageeditor.StageEditorThemeSo, somehow the new stage editor accidentally broke save loading in older versions.
Not sure why that happens, I had practically copied the theme part from the Chart Editor. I'll look more into it, thanks for finding this out! Actually it may be because the stage editor didn't exist in older versions, so it just loads the old save data.
Actually it may be because the stage editor didn't exist in older versions, so it just loads the old save data.
This would probably explain it. Save data gets encoded using the Haxe serializer, which saves the class names of the elements that it includes.
Steps that I can take to solve this:
- Replace all instances of enum values in the save data with enum abstracts, so they can always be deserialized.
- Add more safeguards and error checking.
I also need to figure out what exactly happens when the game fails to deserialize the save data. It might not be recoverable.
I also need to figure out what exactly happens when the game fails to deserialize the save data. It might not be recoverable.
If it helps I know why it just wipes all the data. These are the lines of relevance: https://github.com/HaxeFlixel/flixel/blob/f5087ea69e42750893ac4ec29dc4367714ab815b/flixel/util/FlxSave.hx#L464-L466
The error happens, is caught, but is just ignored, so sharedObject.data is not populated and stays empty, that empty data later overwrites the save file's data hence the wiping.
Yeah, looking at this snippet, it's clear that this is an issue which I can build new safeguards against for the future, but I cannot recover the save data for people affected. The game has already overridden the file with an empty save.
I have created an upstream issue at HaxeFlixel/flixel#3269 tied to this one.
I think it would be neat to make a separate, backup save file for highscores in case the main save file gets reset due to playing pre-0.5.2 versions. Maybe for settings as well but highscores are primarily the things people care for. This would also be useful in the future when eventually more enum fields get added. Might make a pr for this later ,,,
I think it would be neat to make a separate, backup save file for highscores in case the main save file gets reset due to playing pre-0.5.2 versions. Maybe for settings as well but highscores are primarily the things people care for. This would also be useful in the future when eventually more enum fields get added. Might make a pr for this later ,,,
Please do! Backups are absolutely essential, especially for rank-saving games like Funkin'
I think it would be neat to make a separate, backup save file for highscores in case the main save file gets reset due to playing pre-0.5.2 versions. Maybe for settings as well but highscores are primarily the things people care for.
The game ALREADY writes save data to other slots when there are issues, using the archiveBadSaveData function, and the debug_queryBadSaveData function just below it. I made these functions back when the Unserializer was handling Maps wrong or something.
That said, having a second backup save file wouldn't solve this particular problem in the slightest. HaxeFlixel tried to load the save data, failed, and as a result of the way saves are coded in Flixel, told Funkin' that there was no save data. There is no way Funkin' could detect that right now, and even if it did it has no way of reading that save data (because again, the save data reading function is broken).
This would also be useful in the future when eventually more enum fields get added.
This issue actually makes a strong argument that NO enum field should be used in the save data ever. Every existing use of an enum field should absolutely be replaced with an enum abstract (which will always be parseable by the Unserializer).
Might make a pr for this later.
Definitely won't argue with this though. I will work on something myself to improve save data handling (IMO this will have to be an emergency v0.5.3 update).
The game ALREADY writes save data to other slots when there are issues, using the archiveBadSaveData function, and the debug_queryBadSaveData function just below it. I made these functions back when the Unserializer was handling Maps wrong or something
I wasn't aware of this, my bad. I thought the only other backup saving process was the scores.json file that gets created/updated every time the song is completed.
After checking a bit further, the function you mentioned only works on bad datas and doesn't even attempt to replace the data of the newly made save file. My solution would be to just make a backup of scores every time a song is completed, and that when an issue occurs and a save file is unsalvagable, it reads the score backup and sets the newly made data's scores to the ones from the backup.
That said, having a second backup save file wouldn't solve this particular problem in the slightest.
I'm not sure if there is a solution to this for ALL versions (previous versions included due to the issue being caused due to downgrading) that is unless the FlxSave system is updated. This error will always exist between versions 0.5.2 and every version beforehand.
This issue actually makes a strong argument that NO enum field should be used in the save data ever. Every existing use of an enum field should absolutely be replaced with an enum abstract (which will always be parseable by the Unserializer).
True, I think a good call would be to replace all the theme enums to simple bools and deprecate the current fields.
After checking a bit further, the function you mentioned only works on bad datas and doesn't even attempt to replace the data of the newly made save file.
We save the bad data to save slot 1000 (incrementing if one already exists there). This should create a Funkin1000.sol I believe, and in the future we can work on built-in recovery mechanisms but in the meantime that file still exists.
My solution would be to just make a backup of scores every time a song is completed, and that when an issue occurs and a save file is unsalvagable, it reads the score backup and sets the newly made data's scores to the ones from the backup.
...
Say you did this while this bug is active. The first save is unable to be read due to containing an invalid enum in the save data, then the game tries to load the backup save. Why wouldn't the backup save have the same problem? You can't read the save either way.
I'm not sure if there is a solution to this for ALL versions (previous versions included due to the issue being caused due to downgrading) that is unless the FlxSave system is updated. This error will always exist between versions 0.5.2 and every version beforehand.
I agree. I am working on fixing FlxSave now and issues like this should be prevented moving forward.
True, I think a good call would be to replace all the theme enums to simple bools and deprecate the current fields.
Using enums to strings would work better in case we add more themes aside from Light and Dark.
We save the bad data to save slot 1000 (incrementing if one already exists there). This should create a Funkin1000.sol I believe, and in the future we can work on built-in recovery mechanisms but in the meantime that file still exists.
From what I've seen, Funkin1000.sol save file only gets created if the current save file does not satisfy the version needed, not if any field within the satisfied version is broken. The backup system I suggested saves all the settings (figured it'd be better instead of only scores) in SaveBackup.sol after every flush() call, and if it fails to load both the new system and the legacy file it resorts to using this backup.
...
Say you did this while this bug is active. The first save is unable to be read due to containing an invalid enum in the save data, then the game tries to load the backup save. Why wouldn't the backup save have the same problem? You can't read the save either way.
Fair point. I had replaced all the enums in the save file typedefs with an enum abstract (also moved the editor themes to be in one single enum abstract in case of more editors in the future using different themes) so that shouldn't be a problem anymore. I kept in the original enum fields for backwards compatibility.
I agree. I am working on fixing FlxSave now and issues like this should be prevented moving forward.
Thank you.
Using enums to strings would work better in case we add more themes aside from Light and Dark.
My dumbass forgot ChartEditorLiveInputStyle is also an enum my bad lol
Either way currently done with my solution, will do more testing before I make a pr.
@JustKolosaki I just pushed a branch up that you can test with if you like, bugfix/save-data-fixes. I'm still doing some testing on it.
On that branch, loading save data will migrate save files from either v0.5.2 or v0.5.1(or earlier) to use enum abstract strings instead of enums where relevant. I also change the version number so moving to an older version of the game makes it complain about the save data version as it should.
For future reference, the bad save data I was testing with:
@JustKolosaki I just pushed a branch up that you can test with if you like,
bugfix/save-data-fixes. I'm still doing some testing on it.On that branch, loading save data will migrate save files from either v0.5.2 or v0.5.1(or earlier) to use enum abstract strings instead of enums where relevant. I also change the version number so moving to an older version of the game makes it complain about the save data version as it should.
For future reference, the bad save data I was testing with:
I may or may not have already fixed the thing but I will definitely still give testing this branch a shot, thanks!
ok, the problem has been fixed, the problem is that if you roll back you keep the save file but you can't play mods that are older than the current version since you can't change the save path