• Fixed that after a player reconnected after a desync, while blueprints were uploaded, the game would crash. more
  
• Fixed that in certain scenarios, the blueprint library wouldn't synchronise. more
  
• Fixed that the server would sometimes quit if a player tried to connect after another player tried to connect unsuccessfully. more
  
• Fixed a rare desync related to electric sub networks.
  
• Fixed archaic (from 0.12) migration that was supposed to fix rollingStockCounts on rails and it broke it instead.
  
• Fixed possible desync when rotating pipe to ground. more
  
• Fixed a rare possiblity of internal electric network crash when loading game. more
  
• Handle network errors (caused by LavasoftTcpService64.dll corrupting Winsock) gracefully. more
  

• Fixed changing force of underground belt entity would cause desync. more
  

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

• Fixed that after a player reconnected after a desync, while blueprints were uploaded, the game would crash. more
  
• Fixed that in certain scenarios, the blueprint library wouldn't synchronise. more
  
• Fixed that the server would sometimes quit if a player tried to connect after another player tried to connect unsuccessfully. more
  
• Fixed a rare desync related to electric sub networks.
  
• Fixed archaic (from 0.12) migration that was supposed to fix rollingStockCounts on rails and it broke it instead.
  
• Fixed possible desync when rotating pipe to ground. more
  
• Fixed a rare possiblity of internal electric network crash when loading game. more
  
• Handle network errors (caused by LavasoftTcpService64.dll corrupting Winsock) gracefully. more
  

• Fixed changing force of underground belt entity would cause desync. more
  

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

I need to make a confession.

I'm addicted.
Addicted to optimisation.
I earned some money by the game ... you know .. I could just .. I don't know .. play games and ... have some leisure time, but do you know what would be the problem? I would have to think about some Factorio optimisations I wanted to do anyway.

When I go to bed in the evening, I think about cache locality and data structures. I dream about ways to reorganize structures to minimize the amount of data needed to be read to perform Factorio logic. When I walk in the park, i visualize the tricks that could be done to decrease data and logic dependencies. This usually only stops when I see how many bugs need to be fixed after release when lot of changes are done.

The electric network optimisation for 0.16 was simple in principle. We currently have one continuous buffer of electric connector data stored in the electric network. It needs to be iterated twice (first for calculation, second for power distribution).



The change was to categorize energy connector data by the prototype:



It adds another layer of indirection when something needs to be added/removed from the network, but that happens quite rarely. The advantage is, that all the prototype specific values, like inputFlowLimit, outputFlowLimit etc. can be accessed once at the beginning of the processing of one category, which (together with other size squishing), results in a much smaller memory layout, which results in faster iteration of the algorithm.

The conclusion is that electric network transfers are more than twice as fast compared to 0.15.

Smoke already had the first iteration of optimisation 125 weeks ago. But Factorio is many times faster since than, so smoke started to appear in our profiling again.

The problem was that even creating the smoke object and registering it on the map was slowing the game down. The plan was to make something we internally call TrivialSmoke. The Trivial smoke data size is 32 bytes which is quite small compared to the previous "smoke as entity" size of 256 bytes. It contains only the most basic data squashed as much as possible, and it is stored in a continuous piece of memory on the chunk it was created.



As the updates happen in regular intervals (120 ticks), it is always guaranteed, that the smokes to be updated this tick are at the beginning of the buffer, I don't have to check the rest. The same buffer is used for update and for render, so these objects don't need any other references to it.

It is similar to the Chunk update planner mentioned in fff-161, just flattened.
The result is, as expected, that the smoke creation/update/removal times were significantly reduced.

The dilemma is, whether to use similar approach to the logistic bots as for the smoke. This would mean that logistic bots would be created/updated/removed very fast and their memory footprint would decrease a lot, but they wouldn't be regular entities any more. They couldn't be mined (which could be for the better actually), couldn't be attacked or damaged by anything (which again, would be welcomed by some players). I'm quite sure that it shouldn't apply for the construction robots, as they are more related to the fighting part of the game, but logistic robots aren't.

The dilemma is, whether changing the game rules like this just for optimisation isn't going too far.

I benchmarked a huge save of Vaclav (https://imgur.com/a/qDDs1), and it can already run 2.4 times faster in 0.16 compared to 0.15 so we met our "2 times faster release" quota,
but I'm afraid that this won't stop the addiction.

Almost all of the terrain has been updated for 0.16, which includes the high-res update of it. We will certainly cover the terrain/trees/decals improvements in future FFF. Here I would like to present the new version of the stone path terrain made by Ernestas. It is inspired (as many things in Factorio) by the eastern style of pavements, and I'm starting to be a fan of his work.



As always, let us know your thoughts, ideas and feedback on our forum.

I need to make a confession.

I'm addicted.
Addicted to optimisation.
I earned some money by the game ... you know .. I could just .. I don't know .. play games and ... have some leisure time, but do you know what would be the problem? I would have to think about some Factorio optimisations I wanted to do anyway.

When I go to bed in the evening, I think about cache locality and data structures. I dream about ways to reorganize structures to minimize the amount of data needed to be read to perform Factorio logic. When I walk in the park, i visualize the tricks that could be done to decrease data and logic dependencies. This usually only stops when I see how many bugs need to be fixed after release when lot of changes are done.

The electric network optimisation for 0.16 was simple in principle. We currently have one continuous buffer of electric connector data stored in the electric network. It needs to be iterated twice (first for calculation, second for power distribution).



The change was to categorize energy connector data by the prototype:



It adds another layer of indirection when something needs to be added/removed from the network, but that happens quite rarely. The advantage is, that all the prototype specific values, like inputFlowLimit, outputFlowLimit etc. can be accessed once at the beginning of the processing of one category, which (together with other size squishing), results in a much smaller memory layout, which results in faster iteration of the algorithm.

The conclusion is that electric network transfers are more than twice as fast compared to 0.15.

Smoke already had the first iteration of optimisation 125 weeks ago. But Factorio is many times faster since than, so smoke started to appear in our profiling again.

The problem was that even creating the smoke object and registering it on the map was slowing the game down. The plan was to make something we internally call TrivialSmoke. The Trivial smoke data size is 32 bytes which is quite small compared to the previous "smoke as entity" size of 256 bytes. It contains only the most basic data squashed as much as possible, and it is stored in a continuous piece of memory on the chunk it was created.



As the updates happen in regular intervals (120 ticks), it is always guaranteed, that the smokes to be updated this tick are at the beginning of the buffer, I don't have to check the rest. The same buffer is used for update and for render, so these objects don't need any other references to it.

It is similar to the Chunk update planner mentioned in fff-161, just flattened.
The result is, as expected, that the smoke creation/update/removal times were significantly reduced.

The dilemma is, whether to use similar approach to the logistic bots as for the smoke. This would mean that logistic bots would be created/updated/removed very fast and their memory footprint would decrease a lot, but they wouldn't be regular entities any more. They couldn't be mined (which could be for the better actually), couldn't be attacked or damaged by anything (which again, would be welcomed by some players). I'm quite sure that it shouldn't apply for the construction robots, as they are more related to the fighting part of the game, but logistic robots aren't.

The dilemma is, whether changing the game rules like this just for optimisation isn't going too far.

I benchmarked a huge save of Vaclav (https://imgur.com/a/qDDs1), and it can already run 2.4 times faster in 0.16 compared to 0.15 so we met our "2 times faster release" quota,
but I'm afraid that this won't stop the addiction.

Almost all of the terrain has been updated for 0.16, which includes the high-res update of it. We will certainly cover the terrain/trees/decals improvements in future FFF. Here I would like to present the new version of the stone path terrain made by Ernestas. It is inspired (as many things in Factorio) by the eastern style of pavements, and I'm starting to be a fan of his work.



As always, let us know your thoughts, ideas and feedback on our forum.

Hello, it's another Friday, so time for another Friday Facts.

As we were discussing the GUI/UX rewrite (which is going to be covered in detail in future FFF), we came across the crafting categories implementation. We have 4 in base game, but with few mods, it can go up to 20+ which is quite hard to manage in a GUI that is still practical and looks nice.

Making its own sub-category for transport belts and putting them there is (probably) fine, but if it is done this way (5dim code), it only moves the vanilla transports belts there. but if some other mod adds transport belts, they will still stay in the old category, making it all messy.


This is a typical situation, where the fact that our data definition is done in a scripting language can be taken advantage of. We can just replace the previous code by more generic variant.


The code goes through all the recipes and whenever its result is a transport belt, it is moved to the correct category. This way, all the possible other transport belts added by other mods will go there and my change of categories doesn't actually make more problems than it solves. This is a shoutout to the mod devs so they try to be reasonable with the crafting categories, so it doesn't happen that often that <something>-1, <something>-2, <something>-3 is on one place, but <something>-4 is somewhere else, just because it was introduced by a different mod. Either try to keep things in their official categories as long as possible, or recategorize properly.

The tips and tricks GUI is perhaps one of the greatest sources to teach players about some of the obscure convenience features we have added to the game over the years:

• Fast replacing furnaces, inserters, assembling machines etc.
• Copy-pasting entity information, recipes, schedules etc.
• How to turn on detailed view (alt-mode).
• The hotkeys for the quickbar.
• And the rest...

It is a shame then that this GUI is rarely read by the player, and this is our fault. It is easy to see the main reasons why:

• It is only shown at the start of a new game, when many of the tips are not relevant.
• Once it is closed, it cannot be reopened without starting a new game.
• Many of the tips are outdated, old, or just plain ugly.

So with this in mind, I set to correcting things as best I could. Since the tips and tricks have been in the game for a very long time, this involved moving some of the information around to make it work in multiplayer, but because they don't affect the gamestate, determinism was not a concern. After adding a hotkey to bring the tips back up, it feels very natural now to hit the hotkey on and off just to quickly check them. Another improvement I made was a button to go backwards through the tips, and to loop once you've reached the last one.

Then it comes to the visuals. The biggest flaw is that most of the images are out of date, and taken on differing terrains - many are not even the same size as the others. This not only affects the size of the GUI, but gives the unpolished feel to the whole system. The other issue is the layout of the widgets in the GUI. With an invaluable mock-up from Albert, defining the styles and arranging necessary elements wasn't too much of a struggle. So the main task now is to recapture and go over the images, and recreate them in a consistent visual style.



After freshening up the current tips, I will feel better about adding more, without the worry that "Nobody will ever read them". No doubt the GUI will still change, especially with the GUI rewrite in the works, so I wouldn't get too attached to the exact way it looks now.

Back in 2016 just before Steam launch, we didn't really have a good online guide for the game. We had the wiki but it was somewhat underdeveloped, and not geared towards a new player to the game. So the guide was the perfect resource for us, and it has served our newer players extremely well.

Unfortunately in the 18 months since Its introduction, a lot of the materials on the guide have become outdated. It would no doubt be a losing battle to try to keep it updated as we are continually adding and changing things in the game, so we have decided to take down the guide from public access. The wiki has received a lot of care from Gangsir and Bilka, and is a much better resource for players of all skill levels, so it is now our recommended destination.

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

Hello, it's another Friday, so time for another Friday Facts.

As we were discussing the GUI/UX rewrite (which is going to be covered in detail in future FFF), we came across the crafting categories implementation. We have 4 in base game, but with few mods, it can go up to 20+ which is quite hard to manage in a GUI that is still practical and looks nice.

Making its own sub-category for transport belts and putting them there is (probably) fine, but if it is done this way (5dim code), it only moves the vanilla transports belts there. but if some other mod adds transport belts, they will still stay in the old category, making it all messy.


This is a typical situation, where the fact that our data definition is done in a scripting language can be taken advantage of. We can just replace the previous code by more generic variant.


The code goes through all the recipes and whenever its result is a transport belt, it is moved to the correct category. This way, all the possible other transport belts added by other mods will go there and my change of categories doesn't actually make more problems than it solves. This is a shoutout to the mod devs so they try to be reasonable with the crafting categories, so it doesn't happen that often that <something>-1, <something>-2, <something>-3 is on one place, but <something>-4 is somewhere else, just because it was introduced by a different mod. Either try to keep things in their official categories as long as possible, or recategorize properly.

The tips and tricks GUI is perhaps one of the greatest sources to teach players about some of the obscure convenience features we have added to the game over the years:

• Fast replacing furnaces, inserters, assembling machines etc.
• Copy-pasting entity information, recipes, schedules etc.
• How to turn on detailed view (alt-mode).
• The hotkeys for the quickbar.
• And the rest...

It is a shame then that this GUI is rarely read by the player, and this is our fault. It is easy to see the main reasons why:

• It is only shown at the start of a new game, when many of the tips are not relevant.
• Once it is closed, it cannot be reopened without starting a new game.
• Many of the tips are outdated, old, or just plain ugly.

So with this in mind, I set to correcting things as best I could. Since the tips and tricks have been in the game for a very long time, this involved moving some of the information around to make it work in multiplayer, but because they don't affect the gamestate, determinism was not a concern. After adding a hotkey to bring the tips back up, it feels very natural now to hit the hotkey on and off just to quickly check them. Another improvement I made was a button to go backwards through the tips, and to loop once you've reached the last one.

Then it comes to the visuals. The biggest flaw is that most of the images are out of date, and taken on differing terrains - many are not even the same size as the others. This not only affects the size of the GUI, but gives the unpolished feel to the whole system. The other issue is the layout of the widgets in the GUI. With an invaluable mock-up from Albert, defining the styles and arranging necessary elements wasn't too much of a struggle. So the main task now is to recapture and go over the images, and recreate them in a consistent visual style.



After freshening up the current tips, I will feel better about adding more, without the worry that "Nobody will ever read them". No doubt the GUI will still change, especially with the GUI rewrite in the works, so I wouldn't get too attached to the exact way it looks now.

Back in 2016 just before Steam launch, we didn't really have a good online guide for the game. We had the wiki but it was somewhat underdeveloped, and not geared towards a new player to the game. So the guide was the perfect resource for us, and it has served our newer players extremely well.

Unfortunately in the 18 months since Its introduction, a lot of the materials on the guide have become outdated. It would no doubt be a losing battle to try to keep it updated as we are continually adding and changing things in the game, so we have decided to take down the guide from public access. The wiki has received a lot of care from Gangsir and Bilka, and is a much better resource for players of all skill levels, so it is now our recommended destination.

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

Hello, it seems the summer heat has finally subsided, and we have not had to run our AC units the whole week. We mentioned earlier we have had Dominik in for a testing week, and we are happy to say that he is quite qualified for a position here, so will be remaining with us. Tom has also joined us, moving here from the Republic of Ireland, and has been getting settled in working through a lot of the small unassigned tasks. It also seems most of us are back from our vacations, so the pace is picking up again.

Most of the work this week has been on the unentertaining sepctrum, with a lot of internal reworking and refactoring going on. A lot commits related to fixing our compilation after the move to C++17. Many of the GUI and input action functions were broken (such as rebinding keys, switch map editor tabs, setting combinator filters), so its been a team effort to fix these as they are found. Hopefully not many will slip through the cracks and into release.

As mentioned in an earlier FFF,one of the planned features for 0.16 is to allow composition of noise functionsfrom Lua code, so that we (and modders) can have more control over how the map is generated.Over the past several weeks I've been getting that workingand playing around with it trying to make a world that has a lot of variationas you explore far away, but is not too crazy near the starting area.

Sometimes it can be hard to visualise what effect changing the noise will have on the resulting map. To give a somewhat more intuitive feel to how the 'elevation' of the noise is affected, I added height shading to the preview. While only used in the game to place water, showing it in this way really helps to see the underlying structure of the noise.



One of the problems I've been tackling is how to allow large bodies of waterwhile ensuring that the player never starts on a tiny island.One way to do this is to add in a web-like structure near the starting area.This can be done by taking some medium-frequency noise with a positive bias(to ensure that there are land bridges to everywhere)but folded back down above a certain elevation to add lakes,subtracting distance from the starting area from that,and then taking the maximum of that and the general world elevation noise.

As a simple example, the Lua code to do create such a noise function looks like:
The result looks like this in the previewer:



Over the summer, we have had a French student Lucien working with us in the office. As a part of his internship, he was helping us develop the new version of the mod portal. It took a long time, as I (Martin) had many other things to work on, and couldn't fully dedicate myself to finishing this long-overdue project, but we are nearing the end. We're hoping to release the new version this month.

Apart from speed and performance improvements, there will probably not be many more changes on release, but we'll start working on new features right away. This new version gives us a much more solid foundation to work from. You can let us know on our Mod portal discussion sub-forum which features/improvements are the most important to you, and there will proobably make a poll later on to see which we should focus on.

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

Hello, it seems the summer heat has finally subsided, and we have not had to run our AC units the whole week. We mentioned earlier we have had Dominik in for a testing week, and we are happy to say that he is quite qualified for a position here, so will be remaining with us. Tom has also joined us, moving here from the Republic of Ireland, and has been getting settled in working through a lot of the small unassigned tasks. It also seems most of us are back from our vacations, so the pace is picking up again.

Most of the work this week has been on the unentertaining sepctrum, with a lot of internal reworking and refactoring going on. A lot commits related to fixing our compilation after the move to C++17. Many of the GUI and input action functions were broken (such as rebinding keys, switch map editor tabs, setting combinator filters), so its been a team effort to fix these as they are found. Hopefully not many will slip through the cracks and into release.

As mentioned in an earlier FFF,one of the planned features for 0.16 is to allow composition of noise functionsfrom Lua code, so that we (and modders) can have more control over how the map is generated.Over the past several weeks I've been getting that workingand playing around with it trying to make a world that has a lot of variationas you explore far away, but is not too crazy near the starting area.

Sometimes it can be hard to visualise what effect changing the noise will have on the resulting map. To give a somewhat more intuitive feel to how the 'elevation' of the noise is affected, I added height shading to the preview. While only used in the game to place water, showing it in this way really helps to see the underlying structure of the noise.



One of the problems I've been tackling is how to allow large bodies of waterwhile ensuring that the player never starts on a tiny island.One way to do this is to add in a web-like structure near the starting area.This can be done by taking some medium-frequency noise with a positive bias(to ensure that there are land bridges to everywhere)but folded back down above a certain elevation to add lakes,subtracting distance from the starting area from that,and then taking the maximum of that and the general world elevation noise.

As a simple example, the Lua code to do create such a noise function looks like:
The result looks like this in the previewer:



Over the summer, we have had a French student Lucien working with us in the office. As a part of his internship, he was helping us develop the new version of the mod portal. It took a long time, as I (Martin) had many other things to work on, and couldn't fully dedicate myself to finishing this long-overdue project, but we are nearing the end. We're hoping to release the new version this month.

Apart from speed and performance improvements, there will probably not be many more changes on release, but we'll start working on new features right away. This new version gives us a much more solid foundation to work from. You can let us know on our Mod portal discussion sub-forum which features/improvements are the most important to you, and there will proobably make a poll later on to see which we should focus on.

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

Hello Factorio players, lets start our developer to player interaction right now! :)

Dominik is our new programmer in for a testing period. He was given the task to add support for fast-replacing splitters and belts in a reasonable way, and he ended up extending the functionality a little.

Adding a belt junction:



Removing it:



Adding underground part:



Removing it:



It is something I wanted in the game for a long time!

Rseding91 explained in the FFF-201 how important it is for us to not only optimize the game for you the players, but also for us, so we can speed up our change->compile->run/test cycle.

Step 1 - Hardware

When I returned from my holiday this Friday, I noticed that the recompile time of Factorio on debug mode took almost 5 minutes, which is more than I was used to. We checked the CPU temperatures and memory speeds, and they are okay, but the compile time was still double of what others have on similar hardware. It turned out that it is most probably caused by slow SSD speed, which could be caused by writing a huge amount of data when working. From what I found on the internet, the typical SSD write capacity is something around 1TB (EDIT: I meant 1000TB) of data, which is not so hard to approach if one recompilation cycle of Factorio generates 5GB of data. It is quite possible, that the drive just gets slower as it approaches its limit. Actually, the lifespan my specific SSD is typically a year or less. Luckily, our new computers with sweet i9-7900X CPU were ready to be assembled at this time, and I'm planning to get enough memory to compile on ramdisk to prevent this problem in the future.

Step 2 - Hardware updated

So, after half a day of fiddling, I installed everything on a brand new computer so I could test the compilation speed. Discovering that it still took 2 minutes was not really satisfying.

Step 3 - Getting rid of boost

Boost is a special kind of demon. It lures you in by giving you all these cool and simple to use features, and then it beats your soul from you by increasing compilation times absurdly. There are two main problems. Problem one is that they don't care much about compile times and two, they want to have everything nice and generic ad absurdum, and they even defend it as the correct style. The result is, that changing boost::mpl::vector66 to std::variant can improve the compile time from 1:44 to 1:20 and getting rid of templates completely by using unions can decrease the compile time to 0:53. I'm talking about changing 2 headers of 2 classes in a project with 3390 files, 410k lines of code and 15Mb of source code. Everything that was compiled to Factorio, GUI, graphics library, networking, entity logic, scripting, modding, logistic system... all these things together took the same time to compile as two instances of boost::mpl::vector. Our current goal is to get rid of the boost library completely.

The conclusion is that moving from 5 minutes compilation times to sub 1 minute in one week feels good, and it is worth the trouble to improve it from time to time (Until a better language for our purpose is invented, which Jai could be someday).

Another thing that was done to improve the speed of our change->compile->run/test cycle was the improvement of the automated test run speed. Rseding91 made a great feature that runs the tests in parallel, which is especially useful with our new 20 thread systems.


As pipes and pumps are high resolution already, it only makes sense to upgrade the entities that tile with that, such as storage tanks and pumpjacks.



As always, let us know your thoughts, ideas and feedback on our forum.

Hello Factorio players, lets start our developer to player interaction right now! :)

Dominik is our new programmer in for a testing period. He was given the task to add support for fast-replacing splitters and belts in a reasonable way, and he ended up extending the functionality a little.

Adding a belt junction:



Removing it:



Adding underground part:



Removing it:



It is something I wanted in the game for a long time!

Rseding91 explained in the FFF-201 how important it is for us to not only optimize the game for you the players, but also for us, so we can speed up our change->compile->run/test cycle.

Step 1 - Hardware

When I returned from my holiday this Friday, I noticed that the recompile time of Factorio on debug mode took almost 5 minutes, which is more than I was used to. We checked the CPU temperatures and memory speeds, and they are okay, but the compile time was still double of what others have on similar hardware. It turned out that it is most probably caused by slow SSD speed, which could be caused by writing a huge amount of data when working. From what I found on the internet, the typical SSD write capacity is something around 1TB (EDIT: I meant 1000TB) of data, which is not so hard to approach if one recompilation cycle of Factorio generates 5GB of data. It is quite possible, that the drive just gets slower as it approaches its limit. Actually, the lifespan my specific SSD is typically a year or less. Luckily, our new computers with sweet i9-7900X CPU were ready to be assembled at this time, and I'm planning to get enough memory to compile on ramdisk to prevent this problem in the future.

Step 2 - Hardware updated

So, after half a day of fiddling, I installed everything on a brand new computer so I could test the compilation speed. Discovering that it still took 2 minutes was not really satisfying.

Step 3 - Getting rid of boost

Boost is a special kind of demon. It lures you in by giving you all these cool and simple to use features, and then it beats your soul from you by increasing compilation times absurdly. There are two main problems. Problem one is that they don't care much about compile times and two, they want to have everything nice and generic ad absurdum, and they even defend it as the correct style. The result is, that changing boost::mpl::vector66 to std::variant can improve the compile time from 1:44 to 1:20 and getting rid of templates completely by using unions can decrease the compile time to 0:53. I'm talking about changing 2 headers of 2 classes in a project with 3390 files, 410k lines of code and 15Mb of source code. Everything that was compiled to Factorio, GUI, graphics library, networking, entity logic, scripting, modding, logistic system... all these things together took the same time to compile as two instances of boost::mpl::vector. Our current goal is to get rid of the boost library completely.

The conclusion is that moving from 5 minutes compilation times to sub 1 minute in one week feels good, and it is worth the trouble to improve it from time to time (Until a better language for our purpose is invented, which Jai could be someday).

Another thing that was done to improve the speed of our change->compile->run/test cycle was the improvement of the automated test run speed. Rseding91 made a great feature that runs the tests in parallel, which is especially useful with our new 20 thread systems.


As pipes and pumps are high resolution already, it only makes sense to upgrade the entities that tile with that, such as storage tanks and pumpjacks.



As always, let us know your thoughts, ideas and feedback on our forum.