Special saves! (Resolves #162)

All this refactoring, just to resolve #162 (closed). Specifically, it engages savegame events not at level load (except for savefile start) but on level completion, just after you've gotten all the intermission bonuses but before the intermission actually starts.

Also fixes a never-before-discovered pair of bugs that only show up if you have a titlemap and have some settings the vanilla game doesn't have. This game is a mess of hacks, I swear...

• If the titlemap has LF_SAVEGAME, your save file will be overwritten upon returning to the title screen.
• If your first level doesn't have LF_SAVEGAME, it won't correctly force a save there for the creation of the savefile anyways.

One unintended side effect: It may actually be faster in some speedrun circumstances in mods with cutscenes to complete the map, exit back to the title screen, and reload the file. It's a common feature of optimal runs in games with cutscenes, though, and Marathon Run has a toggle for cutscenes, so I'm not particularly bothered.

srb2win_specialsave.exe (updated 25/06/2020)

changed the description

[...] If your first level doesn't have LF_SAVEGAME, it won't correctly force a save there for the creation of the savefile anyways. [...]

That makes sense to me. It might not have been intentional, but I can see a use case for it for mods, being a custom character (or other option) selection as the first "level", where quitting during that won't save the save file because one didn't truly "start" the game.

And if an add-on maker wants to have the first level save the game when entered, they could just add the save game flag to its map header.

The code had a special case for that situation, and the special case was failing only in the circumstance of having a titlemap (because that was being considered the first loaded map of the save, rather than spstage_start/spmarathon_start). Inconsistent behaviour dependent on usage of other features, and ignoring the code comments? That's absolutely a bug, even if you like what it does sometimes.

[...] Inconsistent behaviour dependent on usage of other features, and ignoring the code comments? That's absolutely a bug, even if you like what it does sometimes.

If code comments suggested that it was meant to save in that situation, then this merge request is good to me.

Not just the code comments, the code itself. It directly forces a save when starting a save file. Specifically, the "last map loaded" variable is checked, and if it's zero it forces a save - but it's only zeroed on going to the title screen, which would subsequently re-set it to that of the title map's level if there was a titlemap, which meant it wouldn't be detected when starting an SP file since it wouldn't have been set back to 0 again until later. See the diff for p_setup.c in this MR for what I changed to prevent that.

added 38 commits

• 45026040...7317bbb6 - 37 commits from branch next
• f258131e - Merge branch 'next' of https://git.magicalgirl.moe/STJr/SRB2.git into special_save

Compare with previous version

changed the description

Updated to current state of next; executable contained in merge request. If 2.2.5 is at all close it would be strongly appreciated to include these fixes unless some major conflict is found.

changed title from Special saves! to Special saves! (Resolves #162)

merged

mentioned in commit 696f9707