Name | Factorio | ||
Developer | Wube Software LTD. | ||
Publisher | Wube Software LTD. | ||
Tags | |||
Release | 2020-08-14 | ||
Steam | 25€ 21£ 30$ / 0 % | ||
News | |||
Controls | Keyboard Mouse | ||
Players online |  12058  | ||
Steam Rating | Overwhelmingly Positive | ||
Steam store | |||
How long to Beat | |||
Main Story |  41 Hours  | ||
Main Story + Extras |  89 Hours  | ||
Completionist |  147 Hours  | ||
SteamSpy | |||
Peak CCU Yesterday |
| ||
Owners |  1,000,000 .. 2,000,000 +/-   | ||
Players - Since release |   +/- | ||
Players - Last 2 weeks |   +/- | ||
Average playtime (forever) | 5951 | ||
Average playtime (last 2 weeks) | 837 | ||
Median playtime (forever) | 2583 | ||
Median playtime (last 2 weeks) | 850 | ||
Public Linux depots | Factorio Linux64 [306.86 M] Factorio Linux32 [300.1 M] |
Hello,
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. |