Factorio Forums

Beforehand:

I know that similar requests on the same topic have been made (eg. 120844),
where only the mechanics were described but never any downsides or issues other than the unexpected behaviour.

I am opening this report here to examine the real-world consequences, that were sadly not noted till now.

I think that the current autosave principle is fully broken by design:

• one can not rely on automatically saving progress, so one needs (in cases like see below) to secure designs and progress manually, despite having autosaves on

• is a performance bottleneck

• causes unnecessary SSDs tear

The issue:

I heavily use the 64x time speedup in the editor to find bottlenecks,
and I found that doing so not my design but the game engine has currently a bottleneck on saving an autosave every 4.6 seconds, while having set the default of 5 minutes interval in the settings, also resulting in different undesirable side effects.

From my perspective, this is clearly a bug:

• makes autosaves worthless: if someone ruins on the design, and wants to load an autosave after the testing, has only up to 13 seconds to find out this need, because every 14 seconds all previous autosaves get overwritten. This makes autosaves unusable, since the reaction time is usually way longer.

• is a performance bottleneck: game hangs while saving extraorbitary amount of redundant autosaves, preventing one from actully experiencing the expected speedup. Might be most relevant on large maps/large file sizes.

• breaks the base principle of autosaves: autosaves exist for two reasons, I think. First, to recover after game crashes or game bugs, and second, that users do not need to secure each design step if that could be lost to in-game mechanics (see examples below).
  
  • breaking principle when fast forwarding: From the point of crash recovery, does not help preserving progress, since the user could load a save from long ago and use fast forward again. From the point of game bugs (when cheating on game time), the current behaviour is terrible - I remember more than enough bugs like 116574, where the game entered a state of no possible progress, and loading an autosave could might help (shifting the output of the random generator) - but all the autosaves will be already overwritten when noticing the issue. From the point of loosing newly developed structure designs, the current behaviour is inacceptable, since it intentionally overwrites the files which still contain the design in question, practically deleting all the design progress one has done since the last manually initiated file save (see example about loosing progress below).
  • when slowing the game down: slowing the game down is preferable when one wants to investigate the success of some strucures in detail. Since the autosaves happen much less often, in cases like game crashes one needs to remember in the far past to rebuild the lost details of the structures, if no autosave happened - but that is only a thing of luck.

• Losing progress because of too frequent autosaves can also be a real thing:
  
  Eg. consider this scenario about testing a new space platform design if the defenses are enough for high-speed travel.
  
  Since in sandbox-based editor mode the buildings lost to asteroids do not place ghosts and simply disappear without traces, so the only way to retain the structure is to load a savefile or place the blueprint again. But both of these require the user to manually secure the design. If not done so but relying on the built-in autosave mechanism (whereas the actual idea behind autosaves would be to obviate the need of securing manually), or simply forgetting once the securing step, all the results of long-hour designing can be lost:
  
  0. configure 64x speedup
  1. the user needs to notice that something goes wrong
  2. remember that in this case, against the usual habits, fast reaction is needed
  3. stop the game before the 13 seconds time window runs out.
  
  The 13 seconds window is only a theoretical maximum; the user might have only 9 seconds (= 3 autosaves) to stop the game before progress is lost.

• not at least, if testing the long-time stability of specific designs, this can introduce a significant tear to SSDs without any relevant gains (writing multiple gigabytes per minute is realistic if testing in the main game file). If running on HDDs, the tear is irrelevant but it would even way more slower. Manually disabling the autosave functionality before each run, and also remembering to reactivate it afterwards would be too much to expect from an usual user, I think.

81232, if you already know its not a bug make a feature request instead of a duplicate.