Factorio Forums

We know how hard the team of Factorio works and what a great game they are delivering, although there are bugs that people get pissed off about, everyone understands that it's a non-official released game and it's still in the alpha-beta stage. So with this in mind I am getting annoyed with 1 thing that I believe that the team of Factorio is capable of doing.

This is going to be a semi technical post so not all of the readers will understand this but the concept is simple, No lag/game freeze when saving.

To the devs: I didn't investigate a lot of details about the map string generation etc, but I see it a possibility instead of saving a huge file with all the map info, you should save the map string and the item placement etc like you are doing at the moment. With this in mind, I hate the fact that every 2mins the game freezes for 3 seconds until the game is saved (I am on a big save file). And the more I play the long it will take to save the game

My suggestion is to create a new auto saving thread, this thread has 1 simple task. Capture all the objects and their status, process them and save them to the "save file". With this system you can show an animation icon of let's say a rotating disc and it kind of notifies the player that the game is saved.

continuing on this system I have another suggestion which is in another post, posted after this one.

Thanks,
Clayton

technically I can not contribute but ...

somewhere the devs already told that they are working on the save-system to make it smoother

That's good, I haven't seen it yet, I looked quite a bit on the forums, but failed to find any related stuff so far.

We do need improvement on freezes and de-syncs and with today's updates, we should not face any de-syncs

- Clayton

Technically the reason for transferring the whole map is, that you cannot know how many resources have been already mined, how many trees haven been cut.

The possible solution to that is to store deltas instead of the actual map. Instead of persisting the whole map object persist the map as :
map with seed xyz, options o1 o2 o3 o4 o5 etc, and coal deposit on tile [30, 135] mined by 200 units, coal deposit on tile [31,135] mines by 198, and a tree cut at tile [72, 143] units and so on. It should still be significantly smaller.

Not really, the only smaller bits would be the parts of the map not yet reveled

To their credit, the current compression system is almost as good as they can use and still be reasonably fast.
Of my tests, only a 7z file using BZip2 was able to get better compression without a significant gain in time.
I found several that offered better speeds, but lower compression, and all other methods were either much lower compression, or better, but much slower.

Only problem I see in the system is that the saving process takes priority over the main process, instead of being threaded at an equal or lower priority.

I would oppose a constant saving mechanism, because a) some of us prefer to rollback to an earlier time if something leads to death, and b) the amount of data that would be constantly written would probably be far more than is currently written, just spread out over time, which would reduce the burst of disk access (and thus the spiked slowdown) but would mean a higher level of constant disk access (and overall slowdown).