Title Incompatible save game traps user.
Priority important Status resolved
Assigned To Keywords
Linked issues Watchers

Submitted on 2014-05-25 23h55 by digifuzzy, last changed by fluzz.

File name Uploaded Type Edit Remove
SaveGameIncompatible.png digifuzzy, 2014-05-25.23:55:26 image/png
Author: digifuzzy Date: 2014-05-25   23h55
Attempting to use a previous (and incompatible save game) does not allow the
player to exit or escape the error dialog.

Only resolution is to close the game via a close box (if in windowed mode).
And what would happen if the game was full screen????
Author: jesusalva Date: 2014-05-29   21h04
There was already a similar bug report here, no?
Author: digifuzzy Date: 2014-06-01   22h30
@jesusalva - bug 720 - sounds similar - but no...

When clicking the screen to continue, debug output shows:
"FreedroidRPG 0.15-1163-g9a3ac7b_mod encountered a problem in function:
read_enemy Field "sensor_id" not found"

Suspect that read_enemy function was not updated with the sensors patch...
Author: digifuzzy Date: 2014-06-01   23h58
What appears to be happening is the game is loading the "incompatible file" but
the data is not reset. Lua will attempt to parse the file and produce error
messages "en masse". In this case, an error message of "sensor_id" not found for
EACH AND EVERY droid in the save game.

Tried to click through to confirm but lost count after a 125+ clicks.
Author: jesusalva Date: 2014-06-03   16h30
Well, you can improve it to, instead of making several warnings:
1- Printing (normally) on console the error messages
2- No graphical message on this case. Only console.
3- If possible, assign a "default" value for this inexistent field. And by 
"default" I mean a hardcoded default ie. 'SENSOR_FEATURELESS' or something like 
that. Need see defs.h.
Author: jesusalva Date: 2014-06-03   16h32
we know the faulty camp, right? then:
if (!strcmp(faulty_field, "sensor_id")) {
} else {
    /* Graphical warning */
Author: digifuzzy Date: 2014-06-07   13h21
Actually, I don't think that the suggestion above would help. What about the
next time someone changes the structure...we would have to put in a test
condition for that as well. Also, the psudeo code above would produce a
graphical warning for each and every bot in the map file.

3- If possible, assign a "default" value for this inexistent field. And by 
"default" I mean a hardcoded default ie. 'SENSOR_FEATURELESS' or something like 
that. Need see defs.h.

And should that not have been done when the sensors patch was developed? The
code loads a default value when the savegame file can't be used.

From looking at the code, the test for the game file looks for the major release
value ("0.15+git" in this case) but ignores the minor release value. If the
version test passes, processing of the savegame continues. What is bothersome is
that if processing of the file fails, the user is stuck in a loop. In this case,
processing fails for a droid feature leaving the user in a loop the length of
which is every droid in the map.dat file.
Author: jesusalva Date: 2014-06-17   14h57
Well... This problem is strictly on loading. The struct was changed, so it's now
incompatible with the struct stored on your save file. It only produces billions
of warnings because the struct changed was *enemy, and there are hundreds of
*enemy instances...

This is an old problem about struct. When we update the struct on C, the saved
struct becomes incompatible...

So, we need find a way to update the struct om the save file when it's wrong, am
I right?
Author: digifuzzy Date: 2014-06-23   23h13
Not quite...
Updating an old save file is not really the way to go. Personally, I would be a
little more forgiving of a missing value when reading in the save file.

something like...
read value (variable storage, default if missing)

I've seen similar algorithms used in code libraries handling registry/user
settings. The definition of the "default value when missing" should be done when
a change to the struct is made.

Let me see what I can do for that.
Author: jesusalva Date: 2014-06-26   20h27
@digifuzzy: Well, your above proposed solution will make the save file work 
again, but may impact the gameplay, depending on how much the engine was 

By example, on this case, all 999 wouldn't have their special sensor, as well 
the terminal guards. This is a minor effect that happened, but it could be worse 
depending on how much the C code was changed. A example would be if I renamed 
'max_energy' field to 'max_life' on *enemy struct. We couldn't have a default. 
So we would need, in fact, abort the loading.
Author: digifuzzy Date: 2014-07-04   19h15
Oh for pity sake...get over the sensor's patch!!!

This type of bug has happened before! And it will continue to happen every time
some change is made to the struct!

To prevent this "in future", the suggestion I made is reasonable. Any change to
the struct means the reading/parsing function has to be updated.

Author: fluzz Date: 2014-08-29   12h49
Unneeded repetitions of alerts and error messages fixed in commit 2d0e8865bb23
Date User Action Args
2014-08-29 12:49:12fluzzsetstatus: open -> resolved
messages: + msg2875
2014-07-04 19:15:15digifuzzysetmessages: + msg2837
2014-06-26 20:27:39jesusalvasetmessages: + msg2817
2014-06-23 23:13:23digifuzzysetmessages: + msg2808
2014-06-17 14:57:55jesusalvasetmessages: + msg2807
2014-06-07 13:21:21digifuzzysetmessages: + msg2802
2014-06-03 16:32:21jesusalvasetmessages: + msg2793
2014-06-03 16:30:05jesusalvasetmessages: + msg2792
2014-06-01 23:58:39digifuzzysetmessages: + msg2791
2014-06-01 22:30:07digifuzzysetmessages: + msg2790
2014-05-29 21:04:27jesusalvasetmessages: + msg2789
2014-05-25 23:55:26digifuzzycreate