Make save game overwrites less dangerous

[Koub]

[Koub] Merged into similar suggestion aiming to address the same issue.

[ssilk]

There is also a very old topic:

viewtopic.php?f=80&t=327 World Names (Configurable additional filename chars and Versioning)

Inside there is also a big list of links to similar topics...

[malventano]

I think the reason this has not been fixed is that everyone wants to reinvent the wheel. The root cause of this thread was that the save dialog defaults to the most recent saved game, so when someone starts a new game, their first save attempt will by default attempt to overwrite their most recent game (even if it is from a prior different map). The easy fix here is that the first save after starting a new map should default to the same status as the first new game the player starts, which is literally a blank:



^ this is what the player should see on the first attempted save of *every* new game, not just their first one (even if a prior save is present in the save game folder). This one change would correct the majority of those many threads that have cropped up from folks who started a new map and then inadvertently overwrote their most recent save when they didn't mean to.

There was a prior comment (#2 in this thread) regarding keeping the save name that was just loaded, and that behavior does appear to have been corrected at some point. After loading any save, the next save attempt will default to the name that was just loaded, but the new game behavior still risks overwriting the most recent save (e.g. from another map).

[netmand]

Having that save game experience was ok for alpha/beta versions of the game. Now that we're rolling towards refinement and release this does need attention. Not only for overwriting saves but the way it saves games too. I swear the selection of the last save made was merely convenience of not having to figure out which game was last saved since you can give it any name (and if you died which autosave you're on).

There are several game saves I purposely don't open in the latest version, so I can reload an old version of the game and play it under the old code if needed to replicate and old experience. i.e. some of us want to avoid upgrading maps. The current interface barely passes as save game management. Periodically I spend time deleting maps I will never reload slowly and carefully because I don't want to inadvertently delete one I want to keep. There's no recycle bin, there's no timeline, there's no lock, there's no export, etc. However, I admit there's no need to reinvent the wheel but still would like to see some improvement.

[AileTheAlien]

+1 for new-game saves defaulting to an empty name. Also...deleting a save has a confirmation, but overwriting does not? They're both just as dangerous. :S

[coppercoil]

deleting a save has a confirmation, but overwriting does not? They're both just as dangerous. :S

If there will be confirmation on every action, it may not work because player will be accustomed to press “yes” without any thinking. Despite confirmation still would be a good thing, there could be a way to restore gamesave even if player pressed wrong button.
On the other hand, do we still need a conformation if we can restore gamesave easily?

[BlueTemplar]

Aren't "deleted" savegames moved to the OS trashcan first ?
If not, why not ?

[Koub]

Aren't "deleted" savegames moved to the OS trashcan first ?
If not, why not ?

There is absolutely no reason it would. The file is not deleted from your OS' file browser GUI, but from within the game.

[coppercoil]

The file is not deleted from your OS' file browser GUI, but from within the game.

There should be an OS API to delete file into recycle bin by any application.
But deleting into recycle bin can jam it quickly (I do lots of manual saves). Only few last gamesaves may be useful, so the game could have its own "rescue bin".

[BlueTemplar]

What size are your save games and your hard drive (and how often do you delete saves) that it would "jam the trashcan quickly" ?!?

[coppercoil]

What size are your save games and your hard drive (and how often do you delete saves) that it would "jam the trashcan quickly" ?!?

My game saves are 100M each. Ok, maybe it will jam not so quickly. But still, it's unusual to use Recycle bin for overwritten files. That's not consistent. Why couldn't we have some "Overwrite Bin" dedicated for Factorio?

[BlueTemplar]

Actually, I only meant to talk about deleted games, not overwritten ones - though putting overwritten files (as an OS feature) in the trashcan is an interesting idea !

[GlassDeviant]

This seems like a "please Mr. Dev save me from my own mistakes" kind of thread. Carelessness can be overcome. If you can manage to build a viable factory in this complicated game, you are smart enough to be careful with your save filenames.

[BlueTemplar]

Sure, that's why nobody ever colors electric wires, right ?

[netmand]

I think it's ok to ask for improvements to help avoid making the mistakes of inadvertently overwriting a save. Even smart and careful people make mistakes from time to time.

[malventano]

This seems like a "please Mr. Dev save me from my own mistakes" kind of thread. Carelessness can be overcome. If you can manage to build a viable factory in this complicated game, you are smart enough to be careful with your save filenames.

The thread started with the issue that a new game's first attempted save defaults to the last previous save (e.g. from another map), leading to accidental overwrites. That's not expected as it is not consistent with any other application that saves files. While I can't speak to the other random things that folks keep coming in and suggesting, the root issue is not 'saving from their own mistakes' as much as it is providing the expected behavior for new games.

If only a dev would pay attention to this two-year-old thread and make that one correction, we'd likely quench most of the other complaints stemming from that root issue.

[R3vo]

Summary

Playing different scenarios overwrites the auto save file.

What ?

Currently, the game automatically creates three save files called _autosave1, _autosave2 and _autosave3.

The problem is, that these get overwritten, if one plays different scenarios which can then potentially lead to lost progress.

Example:

• Player plays scenario A for two hours, all three auto save files contain the latest data of this scenario.

• Player now changes the scenario to do some testing, so he opens scenario B. He plays scenario B for a while and then quits the game.

• A few days later the player wants to keep on playing scenario A where he left of last time. Unfortunately, the progress was lost because the player didn't manual safe before moving to scenario B.

Suggestion

That's why I suggest to change the naming scheme of auto safe files.
scenarioName_autosaveX

Coming back to the example above, the player would then have 6 save files called
*scenarioA_autosave1
*scenarioA_autosave2
*scenarioA_autosave3

*scenarioB_autosave1
*scenarioB_autosave2
*scenarioB_autosave3

and would not have lost any progress.

Why ?

Have you ever lost several hours of progress, then you know why.


Regards
R3vo

[Koub]

[Koub] Merged into older topic with suggestions about the same issue.

[BlueTemplar]

BTW, you can increase the number of autosaves in /config/config.ini

[morsk]

I'm frustrated by the lack of communication from developers here. The current system has serious problems, but we don't know if a new system is coming that will obsolete everything, or if we should be suggesting UI changes that solve the current problems.

For example, I could analyze the autosave problem as a process:

1. The player loads _autosave2, perhaps automatically with FFF #330's "Load Last Save".
2. When saving, Factorio suggests _autosave2 as a name.
3. Factorio lets you use it.
4. Factorio later overwrites the save.

Breaking any step in 2-4 will fix the problem, and could be a simple UI change with no side-effects. (I would change #3.) But it may not fix problems with new worlds overwriting old worlds. And it may be a waste of time because something else is already planned.