Add save game compatibility with Q2RTX 1.5.0

[res2k]

Luckily, the general structure is not that different, so it's possible to load old (1.5.0) savegames by doing some things slightly different when the old version is encountered.

• Use a special field type for 'frametimes', covert to framenum on load
• Store the old pointer table as well

Addresses #178.

[Paril]

I do like the idea of a better savegame system in general but I don't know if it's something that would be wanted at a project scope level.. I worry that this will get pretty unmanageable if we have changes in the future, then we'll have potentially 3 versions to store data for (although I don't really expect to have any game DLL changes between then and now, it might be something we inherit from q2pro depending on what ends up being fixed down the road). And if we did implement a new saving system (like JSON or something), we'd still have to have everybody lose progress just to add that support for forwards-compatibility, heh.

Honestly, it might just not be worth it. Q2 includes several config files in pak0.pak for starting the game at a certain unit, and there's no "progress" stored between units anyways... if mission pack support was in the cards I'd potentially be on board but this is just baseq2, so, I dunno.

Up to the project peoples, anyways, just my two cents!

[res2k]

we'd still have to have everybody lose progress just to add that support for forwards-compatibility, heh.

FWIW, my first idea to provide savegame compatibility with 1.5.0 was to "let's copy the savegame logic wholesale", until I realized the existing code could be tweaked with the checks/conditions. But that approach would of course work if any other savegame changes were to be made.

I'm not sure some "custom" savegame system would be worth it. Perhaps if it was inherited from Q2PRO... can't say what they're thinking, but the past suggests a bit that savegame compatibility may not be a priority for them.

[res2k]

Honestly, it might just not be worth it. Q2 includes several config files in pak0.pak for starting the game at a certain unit, and there's no "progress" stored between units anyways... if mission pack support was in the cards I'd potentially be on board but this is just baseq2, so, I dunno.

Well, some progress is stored between units - e.g. items, weapon, ammo. See WriteGame() in baseq2 for details.
Since most of the save game logic lives in the game DLL the mission packs would be unaffected by the recent savegame changes (as they didn't touch the parts in the server).

FWIW, at least from a "user experience" perspective savegame compatibility is welcome and worth it. Even if you can, in theory, cheat your way to the state you had before, it's still a feeling of having "lost" investment into the game. (Also, not everybody may know how to actually cheat yourself to a certain place, or may not want to.)

[Paril]

Of course, but it's trivial to restore - and like I said the unit configs will get you at the start of a unit with the weapons you can get from the prior. I know it's not the same, just thinking ahead to this happening again down the road.

And yes, I know the mission packs are unaffected since they are different mods, but my point was that if we were updating all three game DLL versions at the same time maybe there was more of a justification for it.

EDIT: The other option is to revert only the time-specific variables and go back to floats, which would make the old save games compatible again, but it would make the new ones incompatible without a reverse of the PR hack