Saving cause segmentation fault about raceintospace

[rnyoakum]

This issue was introduced in commit eb75c92. I should be able to fix it quickly enough, but the save code is pretty messy as a result of the whole normal / modem / play by email situation. As a result, I'm not sure what information is supposed to be included in a normal save. Is a save supposed to include only events up to the beginning of the turn, or should it include information representing the game state at the moment of the save (future missions planned, research performed, etc.)?

[rnyoakum]

In commit eb75c92, an error was introduced that affected writing the event data (the newscast text) to a save file. This information is stored so it can be reviewed on later turns at the Viewing Stand. The error caused the game, rather than writing out the event data, to try reading from an uninitialized file pointer. This would likely generate a segmentation fault and the OS would shut down the game. This error should be fixed by commit 8c98fa5.

The second issue is that, since the introduction of the error, normal save files have not been written properly. Autosaves, using different code, managed to avoid this problem (but may have their own issues). However, autosaves generated after loading a non-autosave file will inherit the corruption of the other file. Save files consist of four sections:

I) A save file header
II) The game state
III) Mission replay data
IV) Event data (the newscasts)

Because the save file header and game state (i.e. the Data variable) are both written correctly, the game did not register that the save files are corrupt. It should have, and I intend to upgrade the error checking so the game will pick up on this type of problem in the future. The game, nonetheless, proceeds to try and load the event data, ignoring that it isn't reading anything.

I've also observed that a consequence was that normal saves, at least in my case, are all the same length. The save file header is a set size, which should not change, but the game state data is compressed before being written, so I suspect it should be varying in size. This, along with some testing I've done, suggests the mission replay data is also not being fully written. I could be wrong, but if not I hypothesize part of the replay data is buffered for writing when the segmentation fault occurs and kills game IO before the buffer can flush.

The lack of event data and suspected corruption of the Replay data appears to be responsible for the Viewing Stand generating segmentation faults. This was an issue of which Leon and I were aware, but had not reported because I could not reliably replicate it in new games. The Viewing stand still has problems with the event data, but that demands its own fix.

Overall, the save/load system needs a lot of attention, and I've been working on an overhaul that would handle some...legacy... issues. As a part of this, any saves (excluding autosaves) created in the past four years or so might be declared corrupted and fail to load. If this is a major issue for anyone, I can see about either adding an Allow Unsafe Saves config option or creating a utility to make corrupt saves "safe."

If anyone has a proposal on handling this long-term save corruption issue, please let me know.

[peyre]

I appreciate the attention you're giving to the save system, Ryan! As far as I'm concerned at least, losing games we've saved in the past several years isn't an issue; I'd say the priority is to fix the save system even if we lose whatever saves we've made previously. That'll solve the problem going forward.