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????

There was already a similar bug report here, no?

@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...

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.

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.

we know the faulty camp, right? then:
if (!strcmp(faulty_field, "sensor_id")) {
    ThisRobot->sensor_id=SENSOR_FEATURELESS;
} else {
    /* Graphical warning */
}

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.

Quote:
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.

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?

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.

@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 
modified.

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.

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.

THINK ABOUT IT!

Unneeded repetitions of alerts and error messages fixed in commit 2d0e8865bb23