TUXDB - LINUX GAMING AGGREGATE
 NEWS TOP_PLAYED GAMES ITCH.IO CALENDAR CHAT WINE SteamDeck
 STREAMERS CREATORS CROWDFUNDING DEALS WEBSITES ABOUT
 PODCASTS REDDIT 

 

SUPPORT TUXDB ON KO-FI

MENU

ON SALE

New Twitch streamer aggregation implemented (#FuckTwitch) due to Twitch's API issues (more info on my Discord )


Name

 Factorio 

 

Developer

 Wube Software LTD. 

 

Publisher

 Wube Software LTD. 

 

Tags

 Indie 

 Strategy 

 

Simulation 

 

Singleplayer 

 

Multiplayer 

 

 Co-op 

Release

 2020-08-14 

 

Steam

 25€ 21£ 30$ / 0 % 

 

News

 506 

 

Controls

 Keyboard 

 

 Mouse 

 

Players online

 12058 

 

Steam Rating

 Overwhelmingly Positive 

Steam store

 https://store.steampowered.com/app/427520 

 

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] 




LINUX STREAMERS (58)
q9c9pposmunklinx123456fexeldigital
cool_bobruihoefni_xSpektrum01kolorafa
patomackcsdirtyflux_braastoscsonytii
hexdslpreludelinuxsirsamsaidrne119
tapocolrivzxcoredarknightstudioquix0r
quelluspfckrutoniumportwine_linuxjouersouslinux
greydmiyutehfreekphysixcatskeptical_penguin
drekideggamits147strackiicherenkov11
cidermcdreadengelchen_dej570ne4dpenguinpropaganda
greyferretgamingiheartproduceThe_Moepautopr3z
Kahoss_Jetto_frbaromyr_vtdenplay195
nickmatthewsaskmartynzerostatemachinesebastastiantv
da_boom232yingsenseinewdeep1rolly2go
aptmoovery_average_guyboldvikingdiddumite
anddeveldaarkblood_official




Friday facts #158 - The end of the 32 bit era

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.


[ 2016-09-30 17:47:54 CET ] [ Original post ]