Kerbal Space Program

Another similar thread from back in June 2014:
http://forum.kerbalspaceprogram.com/threads/81883-HorribleOversightInGameDesign-ALL-MY-STUFF-IS-GONE

nightingale wrote:

KSP does an auto-save to the persistent.sfs at a number of different points, including immediately upon loading up in flight view.

However, this behaviour is rather undesirable when doing a quickload of a previous quicksave. The typical scenario for a player who only has two saves (quicksave.sfs and persistent.sfs) is that when they mess up their current mission, they will fairly immediately do a quickload (and may not have a full notion of when the last time they did a quicksave was). If this goes fairly far back in their progression, they may regret the decision to quickload and try to load up the persistent.sfs instead.

persistent.sfs is not intended to be used as a regular savegame file, you are responsible yourself for managing your own saves.
It is part of the modular mechanic on how the different applications in the game transfer data to each other.
For example entering VAB from spacecenter overview will save the current gamestate to persistent.sfs, spacecenter overview application will close, VAB application will start, VAB application will load current gamestat from persistent.sfs.

Complaining about an autosave or presistent.sfs overwriting its own data is like complaining about an autopilot irreverebly changing its old settings every time it changes course.

The only available option would be to remove the optional ability of the player to manualy load a savegame, that he should not have been able to access in the first place.
An additional option would be to implement a seperate dedicated autosave system that has its own autosafe.sfs

You can check the mechanics about how persistent.sfs works by loading it into a text-editor.
When you change from spacecenter to VAB, or from tracking station back to spacecenter or something, just save the previously loaded persistent.sfs while the screen turns black.
You will notice that the current running game will completely revert to the point of time you loaded the file.
Why do you believe it was even named "persistent" if not to symbolize it is used from start to end of the whole game session?

You dont complain about an actual game design flaw, but about the game not autocorrecting your own mistake of loading an older gamestate without first saving your current one.

Personally, what I think the main issue is that makes this difficult for players is the fact that KSP writes out to the persistent file on two triggers - leaving a scene and entering a scene. Since loading a save is essentially entering a scene, it will cause a write out to the persistence file. I can't think of a good reason why it is necessary to write out on load of a scene (since during normal gameplay it would've just been saved when leaving the previous scene).

Showing date/timestamps within the load dialogs certainly wouldn't hurt though.

Should I add my own opinion, saving the game state is clearly one of features that evolved naturally and without clear plan and much of interest. The GUI for named saves/loads being the ugliest GUI part of the game is clear sign of it.

It is not even hard to infer the course of this evolution, even without reading the README change log. It's important to realize that even though some parts of the system were implemented for certain purpose, they don't serve that purpose anymore.

Together with several other such naturally evolved features in KSP, I believe the save/load system deserves an overhaul. And in this particular case, it doesn't really need much ... except proper GUI for named saves. That one is needed A LOT and I really hope we'll get something acceptable already with 1.1.

First we need to realize that autosave is not really saving the game in safe state anymore. It never was, although there used to be some effort towards that. If it can save the game with a ship on trajectory that intersects terrain or atmosphere, it's not safe state.

As such, autosave is more of a quicksave feature that the game uses to store the state of progress in regular intervals. It should have its specific file, different from persistent.sfs. It should be possible to load it like a quicksave, i.e. including switch to the ship under control. It should be possible to turn it off altogether. And persistent state should be updated if and only if the player decides to return to KSC.

With that, there's no need for notification on how old the quicksave is on quickload. It may overwrite the autosave, but the persistence file will remain unaffected. And it is possible to revert to it as well as it is possible to revert to any named save through proper GUI for named saves (which can and should contain creation timestamps for each save and allow sorting by them).

So what is to be suggested?
1. Make player unable to access persistent.sfs and let him do his savegame management alone.
2. Implement a seperate dedicated autosave function.
3. I described the reasons how and why persistent.sfs works. Removing it completely or changing it will have a massive impact, basicaly creating the need to reprogramm most or a large part of the modular gamesystem from scratch.

4. Seen it in too many games under development(worked for a game company myself for a short while). Give players more possibilities and they complain. Give them the ability to zoom in more and they complain about the graphics being pixelated. Restrict their ability to zoom in real close and they remain all happy.
This issue is the same. The file persistent.sfs should never had been accessible for the player to load or save to.
Deny access to the file and implement a seperate autosave function. You will circumvent a lot of trouble and unforseen new bugs that way.
Just trying to give advice.