[1.1.74] failing to load player-data after save (infrequent)
Posted: Sun Jan 01, 2023 4:26 am
When launching factorio recently, after some single-player-mode play in my prior session, I was greeted with this error:
Window title: Data error
Text content: Failed to load the player data file. Campaign progress might be lost.
(screenshot attached.)
There's also this error in the factorio-current.log (full log also attached):
This was a surprise, as I hadn't modified that file from what Factorio had last saved. I expected it to load up normally, and have the default action be to continue the save I'd most recently saved. Instead, I had this error screen, and then also the release notes screen. Strangely, after dismissing both of these, the default action was, still, to load the most recent save prior to that. (Or perhaps that's not so strange -- it seems to select the most-recently-modified-file in the saves/ folder, which is, of course, the save I'd last saved.)
Luckily, I happen to keep my player-data.json and other things in git, so I was able to revert to the previous file to investigate why it failed. Took me a while to narrow it down, but I eventually discovered that the culprit was the "last-played" section, and in particular the "save-name" field. I suspect that the problem may be that some code is rejecting one of the following things that stood out to me as potentially suspicious in the save-name data:
Here's the offending line, and the command I used to get it (with my prompt listed as ': $; '):
And, in case that doesn't come through properly what with the 8-bit data in that, here's a hexdump:
I'm 100% certain that that's the offending line, as if I delete that one line (and the comma from the previous line, for JSON syntax reasons), it loads up without error. (Though when it does so, it goes ahead and deletes the whole "last-played" section after exiting without playing.)
I don't wish to share the exact save name (it contains some vaguely personal information), but it's very similar to:
("redactd" is the same number of characters as the information I redacted.)
I tried loading that save and re-saving to the same name a few times, and was unable to reproduce the problem. Here's a log of a few attempts (the same grep after launch-load-save-quit cycles, each appended to a file):
This invites a question I've long wondered about: why are these names mangled, anyway? If I save to a nice short filename (like "a"), it gets reflected in the file accordingly:
I presume this is somehow related to filename mangling that... some system or other that you're attempting to maintain compatibility with uses? If so, couldn't you do that mangling when reading this back in? And/or if you're needing to encode some information in here, do so using something more standard like base64 or url-encoding or something? (Side note: a fix for this might also allow this request to be accomodated.)
Anyway, whatever transformation is happening there is opaque to me, and isn't a pure function based on only the name (and I don't know what other variables may be involved) so I don't know how to reproduce this, though I've tried (as shown).
Hopefully this is enough information to reproduce things on your end, and/or otherwise track down the problem.
Thank y'all for all you do! I know Wube has a track record of fixing even obscure edge cases like this.
And of course, I have a workaround for now. (I'm just glad I was saving the player-data.json file to git, because otherwise a lot of the information above, plus some console history and stuff, would have been lost to me, when it got re-generated.)
Thanks!
Window title: Data error
Text content: Failed to load the player data file. Campaign progress might be lost.
(screenshot attached.)
There's also this error in the factorio-current.log (full log also attached):
Code: Select all
0.988 Error PlayerData.cpp:230: Failed to load player data: Unterminated string at /home/lindes/Downloads/factorio/git-based/player-data.json:529
Luckily, I happen to keep my player-data.json and other things in git, so I was able to revert to the previous file to investigate why it failed. Took me a while to narrow it down, but I eventually discovered that the culprit was the "last-played" section, and in particular the "save-name" field. I suspect that the problem may be that some code is rejecting one of the following things that stood out to me as potentially suspicious in the save-name data:
- the data had a "slash" ('/') in it (and the save was not in a subdirectory or anything);
- it also had a "backtick" ('`') in it.
Here's the offending line, and the command I used to get it (with my prompt listed as ': $; '):
Code: Select all
: $; grep -a save-name player-data.json
"save-name": "�lK\u0006\u0000\u0000\u0000\u0000a��/�H�`O-1c"Code: Select all
: $; grep -a save-name player-data.json | ot -tx1c
0000000 20 20 20 20 22 73 61 76 65 2d 6e 61 6d 65 22 3a
" s a v e - n a m e " :
0000020 20 22 b6 6c 4b 5c 75 30 30 30 36 5c 75 30 30 30
" 266 l K \ u 0 0 0 6 \ u 0 0 0
0000040 30 5c 75 30 30 30 30 5c 75 30 30 30 30 5c 75 30
0 \ u 0 0 0 0 \ u 0 0 0 0 \ u 0
0000060 30 30 30 61 bb e5 2f 82 48 ff 60 4f 2d 31 63 22
0 0 0 a 273 345 / 202 H 377 ` O - 1 c "
0000100 0a
\n
0000101
I don't wish to share the exact save name (it contains some vaguely personal information), but it's very similar to:
Code: Select all
redactd-2-01-SOLO-1c.zipI tried loading that save and re-saving to the same name a few times, and was unable to reproduce the problem. Here's a log of a few attempts (the same grep after launch-load-save-quit cycles, each appended to a file):
Code: Select all
: $; cat save-names.log
"save-name": "�lK\u0006\u0000\u0000\u0000\u0000a��/�H�`O-1c"
"save-name": "�\u0003�\u0006\u0000\u0000\u0000\u0000�HR�\u001a��oO-1c"
"save-name": "�\n�\u0005\u0000\u0000\u0000\u0000��]����FO-1c"
"save-name": "N��\u0004\u0000\u0000\u0000\u0000��r�2��O-1c"
"save-name": "\u0015P8\u0007\u0000\u0000\u0000\u00008��?,\u001c�O-1c"
"save-name": "�%�\u0003\u0000\u0000\u0000\u0000�'O�!\u001e��O-1c"
Code: Select all
"save-name": "a"Anyway, whatever transformation is happening there is opaque to me, and isn't a pure function based on only the name (and I don't know what other variables may be involved) so I don't know how to reproduce this, though I've tried (as shown).
Hopefully this is enough information to reproduce things on your end, and/or otherwise track down the problem.
Thank y'all for all you do! I know Wube has a track record of fixing even obscure edge cases like this.
And of course, I have a workaround for now. (I'm just glad I was saving the player-data.json file to git, because otherwise a lot of the information above, plus some console history and stuff, would have been lost to me, when it got re-generated.)
Thanks!
