Can we catch errors on save game loading?

[cianty]

Hi AGSers,

is it possible to prevent the error when loading an old save game which is no longer compatible with the current game version?

I am thinking of something like this:

Code: ags

try{
    RestoreGameSlot(1);
}
catch(){
    // Do something in error case
}

Alternatively it would help if we could perform a check whether the save game is still compatible (similar to Game.GetSaveSlotDescription(1)):

Code: ags

bool compatible = Game.IsSaveSlotStillCompatible(1);

So you might wonder why I need this: I recently implemented the functionality that the game automatically resumes with the last saved game so that the player does not have to explicitly load their previous game. Since I am still in development this frequently causes a crash. This alone is no big deal, of course. Where I think this would be useful in production is when you provide a new version of the game exe which invalidates previous save games. It would allow us to provide a much better usability by at least catching the errors this causes. I think especially commercial games would greatly benefit from this.

[Khris]

You can open a save file using String.Format("%s/%s", $SAVEGAMEDIR$, "agssave.001"), then read bytes until hex address 2025, where the description string is stored. It contains the save name and AGS version number.

[cianty]

Thanks, Khris. That is quite interesting but not really helping me solve the problem. I am not interested in the AGS version. It is the version of the game that may be incompatible (e.g. when new sprites or script files are added).

What I am doing for now is to save the (internally defined) game version string of the save game into a separate file. When the game tries to load the game it first checks whether this version is considered compatible by the game exe.
So I may have saved "1.0.0" into the file and the game itself checks for "1.1.0" and "1.0.1", thus knowing that the save game related to "1.0.0" should NOT be loaded. I only do this for my auto-loading save game when the game starts to later prevent crashes. I might extend it to manage this for all save games.

[Crimson Wizard]

No, there is no built-in way in AGS to do this. This is one of the biggest problems with AGS now, and only solution is to write and read your own saved games (using File functions).

[cianty]

Thanks for the reply, Wizard. Do you think it would be possible to implement such a check function? Or is that too much "looking into the future", i.e. the game has to actually process the entire save game and die to "know". Since there is already a onRestore event I thought there must be some sort of "container" aside from the save game itself which could do some sort of error handling and at the very least perform a RestartGame().

[Crimson Wizard]

Since there is already a onRestore event I thought there must be some sort of "container" aside from the save game itself which could do some sort of error handling and at the very least perform a RestartGame().

Sadly there is no such "container" in AGS structure right now, although normally there should be.

I could explain the problem in more detail, but I do not think this may be interesting. In short, in AGS program everything is so entangled, that it may take a while to separate "game" and "engine-container". This is why when save load is interrupted in the middle, it is difficult to predict what would happen if we try to load another save or restart the game.

This is one of the tasks for the future development (if there be any).

[cianty]

That really is a shame. I will then continue to extend my workaround a bit further.

[Khris]

Sorry!
I'm aware of the problem and understood what you're trying to do when I read the thread, then went ahead and posted the solution to a different problem without even realizing it.
Less coffee, more solid breakfast, I guess.

[cianty]

Ha, no problem! I still appreciate the input.

[cat]

I know this thread is old but I had the same situation and thought I could leave a hint for the next person coming here how I solved this:

If you have an autosave feature, that uses some specific save slot and you introduced a breaking change: Just use a different slot number! For example, the initial auto save slot is 100, then for the next version pick 101. When you now use Game.GetSaveSlotDescription(101), it will be null and you wont try to load a broken save slot.

This could also be done for slot ranges, i.e. in the first version the player can use slots 1-10, in the second version 11-20 etc.

[Khris]

I may have thought of a way to handle the original problem: AGS can pull the screenshot from a savegame without actually loading it, so in theory it should be possible to store the current game version in the screenshot by using the RGB values of a corner pixel. We basically use something like #define VERSION 1 and right before the game is saved, a pixel is drawn at 0,0 using a calculated color value.

When the player tries to load a savegame, we use DynamicSprite.CreateFromSaveGame() and read back the game version from the pixel's RGB values before actually restoring the savegame.

[Crimson Wizard]

I may have thought of a way to handle the original problem: AGS can pull the screenshot from a savegame without actually loading it, so in theory it should be possible to store the current game version in the screenshot by using the RGB values of a corner pixel. We basically use something like #define VERSION 1 and right before the game is saved, a pixel is drawn at 0,0 using a calculated color value.

When the player tries to load a savegame, we use DynamicSprite.CreateFromSaveGame() and read back the game version from the pixel's RGB values before actually restoring the savegame.

What about using textual description for the same purpose? The drawback is that you cannot use automatic savegame list filling.

PS. I am still hoping to find time and finish savegame resolving feature somewhere in the beginning of a new year: http://www.adventuregamestudio.co.uk/forums/index.php?topic=53753.0
It was generally working, but I must make it reset unmatching objects to their default states.