Hello,

once I changed the science packs for 0.15, I had to do a playtest to have a feel of how the changes affect the game.

I finished it just before writing this post:




This was the first single player playthrough in a long time, so there was a lot of new findings.
I also enjoyed all the new features, like blueprint book, auto trash, train conditions etc. These were little things but they helped a lot.

The game took me 46 hours to finish. I didn't hurry too much, but it is still quite a long time, considering I played the game several times from start to finish already.

It is not always so obvious to me when we are doing little iterative additions one by one, but when playing from start to finish, there are a lot of things to do. I like the moments when I have dozens of improvements to do and I need to choose the most important one for the moment. The complete change of playstyle in different phases of the game (Burner → research → mass production → trains → multibelt setups → construction robots → even bigger mass production → automated delivery → modules → multi platform stations → rocket) felt right. The overall feeling was, that we shouldn't add much to the game content anymore or it will become too complex and big for the newcomers. This means, that when we add nuclear power, dirty mining, and a few little things, that will be it for the vanilla part of the game. We can still do the expansion pack with additional stages of the game and space exploration later, but that is a different story. The additional complexity will have to be optionally available via modding, this is why we have the native mod support.

There are still a lot of things to be done even if we don't want to drown the player in features, like optimisations to make bigger factories run smoother, as a big part of the fun comes from organizing logistics of huge quantities.

The higher tiers of the research were more expensive and slower (compared to the current 0.14) which I believe is a good thing. Choosing what to research felt more important and as things were unlocked slower. I had enough time to go through almost all the stages of the military options as the game progressed, which felt right.

The best way to improve the game as I see it, is to minimise the annoying parts of the gameplay.

This is the list of changes for 0.15 I decided to do based on this playthrough:

• Decrease the bounding box of burner mining drills,chemical plants and pumpjacks so walking in between them is possible.
• Increase stack sizes of belts,walls and pipes from 50 to 100, this is mainly for the later stage of the game with personal roboports, where making train stations and expansions meant having not enough of belts and walls way too often.
• Figure some way to have low level personal construction robots earlier in the game.
• Change the oil so the minimum yield is dependent on the starting yield so better fields are also better later on.
• There are more oil fields (compared to 0.13) which is a good change, but setting them up is quite a chore for big ones, so having fewer of them with higher yield would be better.
• MK2 personal roboport is a must, as the limit of 10 robots per roboport is not enough in later stages of the game when building bigger setups.
• Concrete shouldn't be blue science (green only)
• The electric furnace should be somewhat cheaper. (Especially when it is used in science packs now)
• Shift click (ghost placement) should go through trees and rocks as blueprints with shift do.
• Enhancement to the belt building mechanics, so building by dragging makes continuous belt.
• Limit turret creep as it is way too powerful now (especially with personal roboport) with a turret activation time. As it makes the expansion harder, the resource growth from the center should be higher.
• Merging items with different health. - We didn't do the item merging, as we didn't want the player lose his precious items as two 49% items would merge into one, which would prevent the player from repairing both for just a few repair. In reality, I feel that the annoyance of having 8 different stacks of laser turrets/walls in my inventory is not worth the rare possibility of losing an item or two.
• MK2 version of boiler and steam engine. It is going to be a must with the nuclear power, but it should be usable with conventional coal power generation as well.

There are many tricks and shortcuts in the game that make the gameplay so much easier. As we don't want to overwhelm the players with huge tutorials in the start, we need to teach them those as the game progresses. This would be done by the little interactive tutorials that would unlock only when it is relevant. Something like this:

• You build the first locomotive → Tutorial to setup a train schedule unlocked.
• You build a second locomotive → Tutorial of rail signals unlocked.
• You build 50 rail signals → Tutorial of chain signals unlocked.
• You build 10 requester chests → Tutorial that copy paste from assembler to requester chest does exactly what you need.
• etc. etc.
As the tricks would be given to the player in small doses as he plays through the game and mainly when the player is probably just about to use it, we might add lots of these without the fear of overwhelming the player.

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

Hello,

once I changed the science packs for 0.15, I had to do a playtest to have a feel of how the changes affect the game.

I finished it just before writing this post:




This was the first single player playthrough in a long time, so there was a lot of new findings.
I also enjoyed all the new features, like blueprint book, auto trash, train conditions etc. These were little things but they helped a lot.

The game took me 46 hours to finish. I didn't hurry too much, but it is still quite a long time, considering I played the game several times from start to finish already.

It is not always so obvious to me when we are doing little iterative additions one by one, but when playing from start to finish, there are a lot of things to do. I like the moments when I have dozens of improvements to do and I need to choose the most important one for the moment. The complete change of playstyle in different phases of the game (Burner → research → mass production → trains → multibelt setups → construction robots → even bigger mass production → automated delivery → modules → multi platform stations → rocket) felt right. The overall feeling was, that we shouldn't add much to the game content anymore or it will become too complex and big for the newcomers. This means, that when we add nuclear power, dirty mining, and a few little things, that will be it for the vanilla part of the game. We can still do the expansion pack with additional stages of the game and space exploration later, but that is a different story. The additional complexity will have to be optionally available via modding, this is why we have the native mod support.

There are still a lot of things to be done even if we don't want to drown the player in features, like optimisations to make bigger factories run smoother, as a big part of the fun comes from organizing logistics of huge quantities.

The higher tiers of the research were more expensive and slower (compared to the current 0.14) which I believe is a good thing. Choosing what to research felt more important and as things were unlocked slower. I had enough time to go through almost all the stages of the military options as the game progressed, which felt right.

The best way to improve the game as I see it, is to minimise the annoying parts of the gameplay.

This is the list of changes for 0.15 I decided to do based on this playthrough:

• Decrease the bounding box of burner mining drills,chemical plants and pumpjacks so walking in between them is possible.
• Increase stack sizes of belts,walls and pipes from 50 to 100, this is mainly for the later stage of the game with personal roboports, where making train stations and expansions meant having not enough of belts and walls way too often.
• Figure some way to have low level personal construction robots earlier in the game.
• Change the oil so the minimum yield is dependent on the starting yield so better fields are also better later on.
• There are more oil fields (compared to 0.13) which is a good change, but setting them up is quite a chore for big ones, so having fewer of them with higher yield would be better.
• MK2 personal roboport is a must, as the limit of 10 robots per roboport is not enough in later stages of the game when building bigger setups.
• Concrete shouldn't be blue science (green only)
• The electric furnace should be somewhat cheaper. (Especially when it is used in science packs now)
• Shift click (ghost placement) should go through trees and rocks as blueprints with shift do.
• Enhancement to the belt building mechanics, so building by dragging makes continuous belt.
• Limit turret creep as it is way too powerful now (especially with personal roboport) with a turret activation time. As it makes the expansion harder, the resource growth from the center should be higher.
• Merging items with different health. - We didn't do the item merging, as we didn't want the player lose his precious items as two 49% items would merge into one, which would prevent the player from repairing both for just a few repair. In reality, I feel that the annoyance of having 8 different stacks of laser turrets/walls in my inventory is not worth the rare possibility of losing an item or two.
• MK2 version of boiler and steam engine. It is going to be a must with the nuclear power, but it should be usable with conventional coal power generation as well.

There are many tricks and shortcuts in the game that make the gameplay so much easier. As we don't want to overwhelm the players with huge tutorials in the start, we need to teach them those as the game progresses. This would be done by the little interactive tutorials that would unlock only when it is relevant. Something like this:

• You build the first locomotive → Tutorial to setup a train schedule unlocked.
• You build a second locomotive → Tutorial of rail signals unlocked.
• You build 50 rail signals → Tutorial of chain signals unlocked.
• You build 10 requester chests → Tutorial that copy paste from assembler to requester chest does exactly what you need.
• etc. etc.
As the tricks would be given to the player in small doses as he plays through the game and mainly when the player is probably just about to use it, we might add lots of these without the fear of overwhelming the player.

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

Hello!

As the 0.15 work started, the first thing I wanted to do was to rebalance the science packs. We feel that the science pack 1 and 2 balance is just right, but the level 3 (blue) is quite a large jump in complexity, while the alien science pack is trivial. Then I checked that the last time we changed something about the science packs was 2.5 years ago, so it might be the time to try to be more creative.

After some discussions, we decided to make the science packs not so linear and more iterative, the current working version looks something like this:



The prices of the science packs are subject to change as we need to playtest it, but the first version is this:



To make the work of reassigning the science packs to technologies easier, I decided to finally implement the so long postponed feature of showing the needed science packs on the technology icon. We also sort the technologies by the highest science pack needed:



The icons might change, but a late game science setup might look something like this.



On top of that, I would like to implement the infinite research. It would give smaller and smaller gains, but people could spend the resources on something after finishing the regular research if they wanted to.

This paragraph is brought to you by Klonan.

The concept of a player versus player experience in factorio has been around since we introduced multiplayer in version 0.11. Initially there was a small mod which places players alternately on the player and enemy force, the players would then fight it out, with the addition of some craftable biter capsules.

With 0.12 we expanded the forces system, to allow creating and assigning forces to players, allowing the possibility of up to 254 different teams in a single game.

However PvP attempts quickly fell at the first hurdle: multiple players were needed. With the issues of the peer-to-peer multiplayer, the actual experience was not ideal. With the recent success of the team production challenge and the MMO server tests, we decided the conditions were right to create an official PvP mode.

This last week I have been working on the foundation for this new scenario, along with ideas about how specifically it will work, this is what we have so far:

• The first player to create the scenario will be the gamemaster. He will set some configuration options, such as how many teams, the starting tech level etc.
  
• The original starting area will be copied to the new teams spawn positions, each identical to the other.
  
• Each starting area will contain a rocket silo.
  
• If your rocket silo is destroyed, your team has lost.
  
• If you launch a rocket, your team wins.
  
• If all other teams silos have been destroyed, you win.
  
• When you destroy another team's silo, all their base are belong to you.

For other specifics we don't have a good idea, such as what to do with the players of defeated teams. The two main ideas were to allow them to spectate players, or allow them to join another team (which didn't defeat them).

Another issue is that copying the starting area directly would obviously look odd:



I had some discussion with Cube about possible solutions, but these would be some large changes to the internal map generator code, so will have to wait for 0.15.

Custom maps could be nice and simple solution, especially if someone from the community would come up with proposals.

In the end these small issues aside, we think it will be quite an enjoyable gameplay mode, and something for the more competitive players to sink their teeth into.

Look:



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

Hello!

As the 0.15 work started, the first thing I wanted to do was to rebalance the science packs. We feel that the science pack 1 and 2 balance is just right, but the level 3 (blue) is quite a large jump in complexity, while the alien science pack is trivial. Then I checked that the last time we changed something about the science packs was 2.5 years ago, so it might be the time to try to be more creative.

After some discussions, we decided to make the science packs not so linear and more iterative, the current working version looks something like this:



The prices of the science packs are subject to change as we need to playtest it, but the first version is this:



To make the work of reassigning the science packs to technologies easier, I decided to finally implement the so long postponed feature of showing the needed science packs on the technology icon. We also sort the technologies by the highest science pack needed:



The icons might change, but a late game science setup might look something like this.



On top of that, I would like to implement the infinite research. It would give smaller and smaller gains, but people could spend the resources on something after finishing the regular research if they wanted to.

This paragraph is brought to you by Klonan.

The concept of a player versus player experience in factorio has been around since we introduced multiplayer in version 0.11. Initially there was a small mod which places players alternately on the player and enemy force, the players would then fight it out, with the addition of some craftable biter capsules.

With 0.12 we expanded the forces system, to allow creating and assigning forces to players, allowing the possibility of up to 254 different teams in a single game.

However PvP attempts quickly fell at the first hurdle: multiple players were needed. With the issues of the peer-to-peer multiplayer, the actual experience was not ideal. With the recent success of the team production challenge and the MMO server tests, we decided the conditions were right to create an official PvP mode.

This last week I have been working on the foundation for this new scenario, along with ideas about how specifically it will work, this is what we have so far:

• The first player to create the scenario will be the gamemaster. He will set some configuration options, such as how many teams, the starting tech level etc.
  
• The original starting area will be copied to the new teams spawn positions, each identical to the other.
  
• Each starting area will contain a rocket silo.
  
• If your rocket silo is destroyed, your team has lost.
  
• If you launch a rocket, your team wins.
  
• If all other teams silos have been destroyed, you win.
  
• When you destroy another team's silo, all their base are belong to you.

For other specifics we don't have a good idea, such as what to do with the players of defeated teams. The two main ideas were to allow them to spectate players, or allow them to join another team (which didn't defeat them).

Another issue is that copying the starting area directly would obviously look odd:



I had some discussion with Cube about possible solutions, but these would be some large changes to the internal map generator code, so will have to wait for 0.15.

Custom maps could be nice and simple solution, especially if someone from the community would come up with proposals.

In the end these small issues aside, we think it will be quite an enjoyable gameplay mode, and something for the more competitive players to sink their teeth into.

Look:



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

• The /config command now operates through /config get and /config set.
  
• Added additional options to the /config comand: allow-commands, max-upload-speed, autosave-interval, afk-auto-kick, verify-user-identity, only-admins-can-pause, ignore-player-limit-for-returning-players.
  
• Added tab-complete parameters logic to the commands: config, color, and help.
  
• Updated Team production challenge with 2 new challenge modes and a new map set.
  
• Reconnecting to multiplayer game that the player already is in (being dropped probably) instantly closes the previous connection and connects the player.
  

• Improved performance when using a lot of vehicles with equipment grids in multiplayer. (https://forums.factorio.com/33688)
  
• Improved performance in the Trains GUI when trains have large schedules. (https://forums.factorio.com/33421)
  

• Fixed desync loop related to solar panels in more than one electric network.
  
• Fixed desyncs related to movement of damaged vehicle.
  
• Fixed module requests getting removed if concrete was built under them. (https://forums.factorio.com/33655)
  
• Possibly fixed hang in stopping sounds when exiting Factorio on Windows. (https://forums.factorio.com/33639)
  
• Fixed the small errors of movement in latency hiding.
  
• Fixed Gui related script error in team production challenge scenario.
  
• Fixed crash when attempting to set belt directions to diagonal directions. (https://forums.factorio.com/33641)
  
• Fixed duplicate grenade damage 5 research. (https://forums.factorio.com/33606)
  
• Fixed car/tank rotation speed was half what it should be. (https://forums.factorio.com/31815)
  
• Fixed map downloader getting stuck and flooding the network after a big timeout.
  
• Fixed rotating of placed flamethrower turret. (https://forums.factorio.com/33700)
  
• Fixed that /command would warn about disabling achievements even in situations where achievements weren't possible. (https://forums.factorio.com/33597)
  
• Fixed that custom gui input was processed even when the game was being saved in singleplayer. (https://forums.factorio.com/33682)
  
• Fixed that boiler wouldn't work after being replaced by bots. (https://forums.factorio.com/33723)
  
• Fixed possible desync when boiler would get destroyed and created a ghost.
  
• Fixed crash when destroying fire during the entity_died event. (https://forums.factorio.com/33763)
  
• Fixed that error messages of wrong zip files in the mod folder weren't giving error message that would be informative enough. (https://forums.factorio.com/33790)
  

• Added read property LuaEntity::has_direction.
  
• Added LuaTile::hidden_tile.
  
• Added the ability to use LuaSurface::get_tile(0, 0) or LuaSurface::get_tile({0, 0}) when getting tiles.
  
• Added LuaGameScript::connected_players read and LuaForce::connected_players read.
  

• Added check that the selection box contains the [0, 0] point.
  

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

• The /config command now operates through /config get and /config set.
  
• Added additional options to the /config comand: allow-commands, max-upload-speed, autosave-interval, afk-auto-kick, verify-user-identity, only-admins-can-pause, ignore-player-limit-for-returning-players.
  
• Added tab-complete parameters logic to the commands: config, color, and help.
  
• Updated Team production challenge with 2 new challenge modes and a new map set.
  
• Reconnecting to multiplayer game that the player already is in (being dropped probably) instantly closes the previous connection and connects the player.
  

• Improved performance when using a lot of vehicles with equipment grids in multiplayer. (https://forums.factorio.com/33688)
  
• Improved performance in the Trains GUI when trains have large schedules. (https://forums.factorio.com/33421)
  

• Fixed desync loop related to solar panels in more than one electric network.
  
• Fixed desyncs related to movement of damaged vehicle.
  
• Fixed module requests getting removed if concrete was built under them. (https://forums.factorio.com/33655)
  
• Possibly fixed hang in stopping sounds when exiting Factorio on Windows. (https://forums.factorio.com/33639)
  
• Fixed the small errors of movement in latency hiding.
  
• Fixed Gui related script error in team production challenge scenario.
  
• Fixed crash when attempting to set belt directions to diagonal directions. (https://forums.factorio.com/33641)
  
• Fixed duplicate grenade damage 5 research. (https://forums.factorio.com/33606)
  
• Fixed car/tank rotation speed was half what it should be. (https://forums.factorio.com/31815)
  
• Fixed map downloader getting stuck and flooding the network after a big timeout.
  
• Fixed rotating of placed flamethrower turret. (https://forums.factorio.com/33700)
  
• Fixed that /command would warn about disabling achievements even in situations where achievements weren't possible. (https://forums.factorio.com/33597)
  
• Fixed that custom gui input was processed even when the game was being saved in singleplayer. (https://forums.factorio.com/33682)
  
• Fixed that boiler wouldn't work after being replaced by bots. (https://forums.factorio.com/33723)
  
• Fixed possible desync when boiler would get destroyed and created a ghost.
  
• Fixed crash when destroying fire during the entity_died event. (https://forums.factorio.com/33763)
  
• Fixed that error messages of wrong zip files in the mod folder weren't giving error message that would be informative enough. (https://forums.factorio.com/33790)
  

• Added read property LuaEntity::has_direction.
  
• Added LuaTile::hidden_tile.
  
• Added the ability to use LuaSurface::get_tile(0, 0) or LuaSurface::get_tile({0, 0}) when getting tiles.
  
• Added LuaGameScript::connected_players read and LuaForce::connected_players read.
  

• Added check that the selection box contains the [0, 0] point.
  

Use the automatic updater if you can (check experimental updates in other settings) or download full installation at http://www.factorio.com/download/experimental.

• The following settings are now settable only in server-settings: allow_commands - default is "admins-only" autosave_interval - default is 10 autosave_slots - default is 5 afk_autokick_interval - default is 0 auto_pause - default is true
  
• Added /toggle-heavy-mode command. It can be used to generate files that help us to investigate server in a state where all new players get a desync loop.
  
• Desync reports are now much bigger, but have bigger chance of being useful.
  

• Fixed trains slowly moving forward when stopped on a signal more
  
• Hopefully fixed Lua desyncs caused by string formatting functions behaving differently on different platforms.
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

• The following settings are now settable only in server-settings: allow_commands - default is "admins-only" autosave_interval - default is 10 autosave_slots - default is 5 afk_autokick_interval - default is 0 auto_pause - default is true
  
• Added /toggle-heavy-mode command. It can be used to generate files that help us to investigate server in a state where all new players get a desync loop.
  
• Desync reports are now much bigger, but have bigger chance of being useful.
  

• Fixed trains slowly moving forward when stopped on a signal more
  
• Hopefully fixed Lua desyncs caused by string formatting functions behaving differently on different platforms.
  

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.

Hello,

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

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.

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.

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.

Hello,

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

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.

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.

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.