Open Moburma opened 11 months ago
Hm, I thought I fixed that.. clearly I did not tested it properly.
The encryption key is saved in two places: user settings file and keys.dat
.
Maybe the key should be in user settings only, to avoid confusion.
You probably know the workaround, but just in case: You can load the mortal game properly if you first log in (or load ordinary save) in which you used the same login.
You can load the mortal game properly if you first log in (or load ordinary save) in which you used the same login.
I thought that might be the case, but it doesn't work. I tried again just now to make sure.
What I'm doing:
Only some specific scenarios actually work.
I logged in and started the mortal game from that, then re-opened the game and loaded it from menu. And that worked. But if I tried to load after logging in, it didn't worked.
Do we have a bug in loading user settings file?
Oh. I see. We do:
LbFileWrite(fh, &ingame.Cheats, sizeof(ingame.Cheats));
where in the struct definition:
ubyte Cheats;
And then we load:
ushort cheats;
LbFileRead(fh, &cheats, sizeof(cheats));
Yeah, that would make all variables after the 'cheats' work incorrectly.
What about now? Fix saving UserFlags in settings
Yep, it now works. Excellent.
I'm still getting this in the latest build.
What I did was start a Mortal Game without logging in or loading another save first. The game creates a anon.ini
in QDATA\SAVEGAME
, though I already have a default.ini
. So the .ini files for users only store settings but not the login name itself?
But even if I login or load another game first to set a name, it still happens.
You can load the mortal game properly if you first log in (or load ordinary save) in which you used the same login.
This works.
So it looks like the proper fix would be to just always start loading saved game by loading settings for user name from within that saved game. I wonder why we're not doing that already.. need to check.
EDIT:
I see the problem - login_name
is stored at end of saved game, and encrypted.
We'd have to move it to front of the save file, and either leave unencrypted or apply separate, softer encryption.
This is a bug present in the DOS original. Mortal Game saves seem to work fine in the same game session, but once the game has been exited and the player starts it again and attempts to resume their save, they will get a "Corrupt save game file" error.
Reproduction: