Friday Facts #270 - HR Substation & Save/Load overview

Posted by Klonan, Rseding, Albert on 2018-11-23

Steam Awards (Klonan)

Steam has opened up the nominations for this years Steam Awards. Last year Factorio was actually selected as a nominee for the 'Haunts My Dreams' award.

There is a category this year for 'Best Developer', and many in the community have wanted to nominate us for that category. Unfortunately to be eligible, we would need to have a developer page set up on Steam.

We had some discussions, and decided to wait until we have a final 'Wube Software' logo and theme finalized before setting up a developer page. This means you won't be able to vote for us as best developer this year...

This doesn't meant that you can't nominate Factorio for one of the categories, and there has already been some discussion on the subreddit about which games people are voting for.

HR Substation (Albert)

The Substation was another of the entities we couldn't just render in double resolution, so it has taken quite some time and iterations to get to something we are happy with.

Deterministic save/load in Factorio (Rseding)

One of the key parts of the save/load process in Factorio is that it must be deterministic. This means that for a given save file (when no external factors change) saving, exiting, and loading the save shouldn't change any observable behavior.

There are a few reasons and benefits for this strict requirement:

  • Without it: You couldn't join a running multiplayer game (and by proxy save, exit, and resume one).
  • Without it: the replay system wouldn't work if you ever saved, exited, and resumed playing.
  • With it: we can easily test that saving and loading produces no observable change letting us know we implemented save/load correctly.
  • With it: you won't see things change randomly as a result of 'reloading' like you do in so many other games.

The premise sounds simple enough: make 'running game -> save -> exit -> load -> running game' produce the same results every time (when nothing else changes). However in practice this ends up being quite complex.

Factorio uses serialization and de-serialization (more), the exact format of the serialized save file changes from map version to map version so we always have to keep that in mind when loading.

As a slight aside, we took some measurement of what parts of the map data take what amount of space in a typical uncompressed save game:

Saving the game is fairly straight forward:

Loading however becomes quite complicated due to the variety of things we need to account for:

  • Map version migrations
  • Mod additions/removals/changes
  • Potentially invalid/corrupted save files

Over the years of Factorio development we've had a handful of strange bug reports about saves not loading which have been tracked to the loading logic previously not handling all of these special cases. A few notable examples:

  • When items are changed due to base game/mod migrations, it can change what type an item is, resulting in what used to be a module now being something else but still occupying an entities module inventory.
  • During loading the bounding box of an entity can change if the prototype data for that entity was changed (mod changed, mod added/removed). When the bounding box changes it can change which chunks the entity will overlap with. During loading it's expected that the number of chunks doesn't change. When the bounding box of an entity changes it can overlap with a chunk which didn't exist during saving.
  • When prototype data changes it can mean that entity bounding boxes have changed and what electric networks an entity was in could have changed.
  • When something is removed during loading (mod removal) we have to destroy them in a specific order because entities/items/electric networks can have references to eachother, and expect to be destroyed from a specific state in a specific order.

Overall the entire process has grown quite complex to the point where it's difficult for us to remember all of the special rules. With that in mind I spent a day earlier this week documenting the entire process for easier reference as to what the order of things is and why we do what we do. For those interested in an even more technical overview of the save/load process a copy of that document it can be found here.

Also on the topic of loading, we have decided to drop support for loading maps from version 0.13 and 0.14 in the latest version, which mean when you get your hands on 0.17, you will only be able to migrate a save game from 0.15 or 0.16. However as it worked before, you can still download 0.16 to migrate from 0.13, then migrate from 0.16 to 0.17.

T-shirt for Christmas (Klonan)

It is approaching the festive season once again, and as such it has been nearly a whole year of selling our official Factorio T-shirts. Since moving to the new office, the merchandise operation has been given a whole double room to handle all the storage and shipping of the T-shirts.

Last year there were some cases where the orders didn't arrive in time for the Christmas tree, and a few people reported the packages taking over 1 month to arrive at their destination. We ship the orders from our office each Wednesday, so depending on when you order it can take almost a week for any shipping confirmation. Once it is shipped, a parcel will typically be delivered within a week anywhere in Europe, and take about another week or 2 to arrive in the USA and Worldwide.

Outside of shipping each week, we can't make any promises on when the orders will arrive, so the best way to prevent any heartache, is to order from our store as soon as possible.

As always, let us know what you think on our forum.