Hello,

another friday and another Facts. It has been 3 years already without a single friday facts missing. I didn't expect that!

32 bit

Our automated integration test count just reached 800. We have several modes to run these. One of the modes is to generate crc hash values of all the steps, which can be compared with values when the tests are started on different platform, or release type.
When doing this, I noticed that there are several problems related to difference between 32 and 64 bits and after solving few of them, I realized that doing this kind of work might be actually not useful usage of our time.

So I made a list of reasons to not have 32 bit support anymore:

• Extra issues related to determinism between 32 bit and 64 bit systems that would have to be solved.
• Release times (compile, upload, updates, server storage space)
• Occasional bugs that we don't notice as no one uses 32 bit system here.
• Confusion of some people that download 32 bit by accident and run out of memory soon.

As steam allows me to check the hardware survey of users playing factorio, I did that and found out that less than 1% of people playing Factorio have 32 bit system. That is not that much considering, that a lot of them have different device capable to run the game as well. I believe, that saving our time so we can spend it on things the 99% of our players appreciate more is the right decision.

The conclusion is to disable multiplayer in 32 bit version right away (0.14.10), so we don't have to deal with desync reports related to 32 versus 64 bit systems and since 0.15 we won't release 32 bit version at all.

Desync report improvement

Desyncs are not that common, but it still happens from time to time, and if it is a desync loop (anyone new that joins the game desyncs until server is restarted) it is definitely annoying problem. It is probably caused by last few determinism oversights which are harder to find, but had to be solved anyway. There are 2 fundamental problems with our desync reports now:

1) When the desync happens in multiplayer game, the player needs to tell the server that it desynced. This takes time as the packet has to travel to the server. Then the client has to update the game until it is in the same tick as the server at the time of receiving the desync alarm. At this point, client and server have the map in the same tick, and this is the version saved in the desync report. The problem is, that it is quite long time since the first original difference between server and client happened, so huge amount of other differences accumulated as the butterfly effect was spreading the difference. It is mostly nearly impossible the find the original cause of the problem from such a desync report most of the time.

We will solve this problem by a change in the server logic. Whenever the server encounters the desync, it will try to check the save-load stability locally. We actually use this in the tests. This means that the server will save the current version of the map, it then loads and saves second instance of the map from it and compares if it stays the same. This report will not contain any accumulated changes from running different version of the save, so only the original cause of the problems will appear in the diff. This will help us to discover the cyclic desync loops, as they are almost always related to the fact that load-save changes some internal state.

2) We have a special tool that can add human readable tags to the binary files, so we can actually see what kind of data is different. This code is not part of the binary we release, so we have to add these tags to the desync report by loading the save and saving it with the tags. The problem is, that some of the desync issues (especially those related to desync loop) are related to the save-load stability, so the information gets lost in this process. So we will make a change, that in the future versions of Factorio we release will be able to save the desync report in the human readable format directly.

I hope that these changes should make it possible for us to solve the rest of the desync problems with much less effort.

Rails

The rail sprites we used had one big problem. To save some video memory we were flipping the pictures:

The problem is, that as the pictures need to be flippable, they need to be very flat, or it would look too weird. We decided to fix it for 0.15 while doing the high res version of the rails.

This is a work in progress of the new rail sprites. Please note that it is at a very raw stage that doesn't even have textures, but it can be used to demonstrate how important it is to have specific pictures for different rotations:

We will show the final version of rails in some of the future friday facts.

As always, if you have any comments or otherwise, please let us know on our forums.