DFHack 50.05-Alpha1 Quicksave not working reliably

[JezaGaia]

I've been testing quicksave by always using the command before saving by quiting to title menu and comparing the state of both saves. At first it seemed to work well, I had 3 perfect saves, then on the forth the quicksave didn't show at all when entering the "continue active game" screen. I could see the 2 previous seasonal autosaves and the save made on exit (region folder) but not the autosave made by quicksave. I checked in my DF Save directory and the folder was there, the timestamp of the last updated files inside were coherent with the normal save, almost identical just a bit earlier (seconds). I had other succesful quicksaves after but many failed ones too.

I have some mods from the workshop so I can't guarantee the issue doesn't come from those but I never had any issue even using the "save and keep playing" feature from premium DF and I did dozens if not more at least with the same mods.

[lethosor]

quicksave isn't supposed to make separate autosaves - it's supposed to save over your current save, just like a "save and exit".

[myk002]

it looks like it now creates an autosave in the autosave rotation. I'll update the docs. I haven't seen any unreliable behavior, though, so I'll keep this bug open for investigation

[brnhensley]

I'm also having a problem with quicksave, as far as I can tell it hasn't made any saves for me. I used it a lot today because I'm getting a crash. I saved about 3 times since the last seasonal auto-save, but the crash happened again and none of my saves are here since that beginning of the last season.

All of my quicksaves were after "early summer, 101". The Autosaves are for that season and the previous two seasons, and my last "Active save" is from the previous year. So quicksave did not overwrite either type of save. I did load all 4 them all to make sure the metadata wasn't just messed up, but no, none of my quicksaves exist.

[lethosor]

Hm, so maybe it doesn't work if you save often enough in a season?

We're really just setting a flag that DF uses itself to trigger the autosave logic, so a couple possibilities I can think of are:

• DF could have changed its autosave behavior
• There could be multiple flags now, and we could be setting the wrong one

Either one of these would require some more in-depth reverse-engineering to determine.

[ab9rf]

After doing some reverse-engineering research, I've determined that it's probably not enough to simply flip autosave_request to true in order to initiate a proper "seasonal" autosave. The following code is what appears in the game when a seasonal autosave is triggered:

    plotinfo.main.autosave_request = true;
    plotinfo.main.autosave_unk = 5;
    plotinfo.main.save_progress.substage = 0;
    plotinfo.main.save_progress.stage = 0;
    plotinfo.main.save_progress.unk_v50_6.nemesis_save_file_id.clear();
    plotinfo.main.save_progress.unk_v50_6.nemesis_member_idx.clear();
    plotinfo.main.save_progress.unk_v50_6.units.clear();
    plotinfo.main.save_progress.unk_v50_6.cur_unit_chunk = 0;
    plotinfo.main.save_progress.unk_v50_6.cur_unit_chunk_num = -1;
    plotinfo.main.save_progress.unk_v50_6.units_offloaded = -1;

At all three points in the code where the game triggers a seasonal autosave, these operations are all performed.

Note that we do not know what most of these variables are being used for, at least not with any reliable degree of confidence. It's my personal suspicion that everything involving save_progress is likely the result of this object being reconstructed.