Hi everyone. About half a year ago whenever I was sitting deeply in Factorio and when I needed to spend time in my phone, I was reading FFF or Factorio forum. Later when I decided to move - I suddenly realized that Wube is the most logical target to apply my crazy mind. All thanks to those FFF and you guys. Now I am writing another FFF myself which, looking back at those times, gives me ripping apart feelings (which I believe is a good thing :)).

We mentioned this quite recently, but it was semi-buried beneath the great nuclear power information. We'd quickly just like to mention again (before you get lost in this meaty FFF) that we're currently searching for a Senior macOS developer to join our team here in Prague.

The role is similar to that of all the other developers on the team (working on new features, fixing bugs etc.), but with a focus on any issues relating to the Mac versions of the game. An ideal candidate would have a great passion for the game, and a strong understand and experience with C++. The full job listing can be found on our website here, and we invite anybody interested to contact us.

After initiation process and path of trials with multithreading (more), a solution was achieved which I described briefly on the forum a few days ago. The next challenge is optimizing the very heart of Factorio - the transport belts.

Many of us know that if you are going to build a huge factory, you better put as many underground belts as possible - it just gives more UPS when you start dropping below 60. That happens due to cache coherency and other issues, but it gave us idea of treating sequences of adjacent belts as one single piece, so performance-wise they behave like the underground belt's underground part. kovarex mentioned this here.



However, this is not everything that can be done to belts. For example look at this thing:



Currently we move every item on every belt that can move. So if you have 20,000 items on belts in your giga-factory - each of those items will consume CPU to advance its position forward. The thing to notice here is that topology of items on belts does not change all that often - i.e. when a transport belt is not blocked by something, items easily flow without changing relative position to each other, and when that belt gets blocked, that property is still true for items located before that blocked part.

So in addition to uniting belts into several consecutive pieces sharing the same array of items, we decided to rethink the way we store their coordinates. We no longer store absolute coordinates of items, instead we store the distance between items. Look at this visualization:



Here blue lines represent the distance between items, and yellow lines represent the initial and final gap to extremes of the cumulative transport line. Most of the time only those yellow things change which asks for an uber-optimization, where for every transport line of like 20-100 belt segments you only increment/decrement those terminal gap sizes, and do not touch items at all! Which technically this means incrementing/decrementing two integers instead of incrementing the position of all 200 items on those belts. The only place you waste performance is rethrowing an item from one sequence to another - that's why we want to keep transport line sequences as long as possible. There is another issue though - it's when belt gets blocked:



When this happens you don't decrement that yellow part anymore, it's already zero. Instead you decrement size of that last non-zero gap shown with red arrow. It may seem that each time the belt is blocked, you will have to scan that sequence of items to find that last gap (which may be very far away and kill all performance at smelting lines), but here goes the obvious/unobvious kung-fu... whenever a belt compresses - it will stay that way forever. It means that once two items are stuck close together - away from inserters they will stay stuck close forever. This property allows us to cache the index of the last positive gap location, and update it on the fly because that index can never increase, only decrease. So essentially this algorithm becomes amortized constant time with respect to the number of items produced by your factory, multiplied by number of transport lines that the item has to travel.

This method however has its implications. You can no longer tell the item position from its index in the transport-line array, you have to iterate all of them first to get there with the sum of all the inter-item distances. The good thing - we never actually used this property, neither did we do any binary searches. The only performance-critical thing affected by such a representation is inserters, but since they need this item-tracking information sequentially with every tick, inserters can easily track what happens inside a transport line (what was moved and what was not last tick), and update the absolute position of a tracked item still at O(1).

Also there are dynamic merging/unmerging routines which keep transport lines under inserters or side-loading at some limited range, maybe 9 tiles, while inserter-free lines can be 100 tiles long. These numbers are still to be calibrated. So far overall performance gains on items movement are at x50-100 with that O(1) optimization. Though it's not everything regarding belts, so actual gains are expected to be around x5-x10. Curved and straight belts are all merged together already, the next step will be embedding underground belts as part of a single very long line.

In the end only splitters should be the legitimate entities to break transport lines apart, in addition to some big 100-tile long limitation of how long transport line can be for the sake of a player picking/dropping items, rendering and other things to consider. So far factories performing at 25 ups start growing to 35-40 ups just because of that belts optimization, and belts are not everything these factories contain.

With 0.15 you will never ever have to build underground belts for the sake of performance :) Factorio's heart is beating nicely now and will not distract from blueprinting the truly important things.

If you remember from the previous FFF, our map downloader was having some extremely rare problems with some mysterious packets that would always get filtered over the Internet. We already had a fix for it, but I was curious what was going on. Thanks to the investigative power of the Factorio community, we found out that all those mysterious packets, before NAT, had a checksum of 0xFFFF. Admalledd from the forum sent some hand-crafted packets through his Internet connection and surprise, all packets would go through, except those with a checksum of 0xFFFF or 0x0000. At this point I would just assume this ISP(and some other few ISPs around the world) have some faulty hardware or software that do not handle these special cases of UDP checksums.


We released a 0.14 hotfix release that will include a fix for the map download. It will also fix the graphical issues caused by the new Nvidia drivers.

As usual, let us know what you think at the forums.

Hi everyone. About half a year ago whenever I was sitting deeply in Factorio and when I needed to spend time in my phone, I was reading FFF or Factorio forum. Later when I decided to move - I suddenly realized that Wube is the most logical target to apply my crazy mind. All thanks to those FFF and you guys. Now I am writing another FFF myself which, looking back at those times, gives me ripping apart feelings (which I believe is a good thing :)).

We mentioned this quite recently, but it was semi-buried beneath the great nuclear power information. We'd quickly just like to mention again (before you get lost in this meaty FFF) that we're currently searching for a Senior macOS developer to join our team here in Prague.

The role is similar to that of all the other developers on the team (working on new features, fixing bugs etc.), but with a focus on any issues relating to the Mac versions of the game. An ideal candidate would have a great passion for the game, and a strong understand and experience with C++. The full job listing can be found on our website here, and we invite anybody interested to contact us.

After initiation process and path of trials with multithreading (more), a solution was achieved which I described briefly on the forum a few days ago. The next challenge is optimizing the very heart of Factorio - the transport belts.

Many of us know that if you are going to build a huge factory, you better put as many underground belts as possible - it just gives more UPS when you start dropping below 60. That happens due to cache coherency and other issues, but it gave us idea of treating sequences of adjacent belts as one single piece, so performance-wise they behave like the underground belt's underground part. kovarex mentioned this here.



However, this is not everything that can be done to belts. For example look at this thing:



Currently we move every item on every belt that can move. So if you have 20,000 items on belts in your giga-factory - each of those items will consume CPU to advance its position forward. The thing to notice here is that topology of items on belts does not change all that often - i.e. when a transport belt is not blocked by something, items easily flow without changing relative position to each other, and when that belt gets blocked, that property is still true for items located before that blocked part.

So in addition to uniting belts into several consecutive pieces sharing the same array of items, we decided to rethink the way we store their coordinates. We no longer store absolute coordinates of items, instead we store the distance between items. Look at this visualization:



Here blue lines represent the distance between items, and yellow lines represent the initial and final gap to extremes of the cumulative transport line. Most of the time only those yellow things change which asks for an uber-optimization, where for every transport line of like 20-100 belt segments you only increment/decrement those terminal gap sizes, and do not touch items at all! Which technically this means incrementing/decrementing two integers instead of incrementing the position of all 200 items on those belts. The only place you waste performance is rethrowing an item from one sequence to another - that's why we want to keep transport line sequences as long as possible. There is another issue though - it's when belt gets blocked:



When this happens you don't decrement that yellow part anymore, it's already zero. Instead you decrement size of that last non-zero gap shown with red arrow. It may seem that each time the belt is blocked, you will have to scan that sequence of items to find that last gap (which may be very far away and kill all performance at smelting lines), but here goes the obvious/unobvious kung-fu... whenever a belt compresses - it will stay that way forever. It means that once two items are stuck close together - away from inserters they will stay stuck close forever. This property allows us to cache the index of the last positive gap location, and update it on the fly because that index can never increase, only decrease. So essentially this algorithm becomes amortized constant time with respect to the number of items produced by your factory, multiplied by number of transport lines that the item has to travel.

This method however has its implications. You can no longer tell the item position from its index in the transport-line array, you have to iterate all of them first to get there with the sum of all the inter-item distances. The good thing - we never actually used this property, neither did we do any binary searches. The only performance-critical thing affected by such a representation is inserters, but since they need this item-tracking information sequentially with every tick, inserters can easily track what happens inside a transport line (what was moved and what was not last tick), and update the absolute position of a tracked item still at O(1).

Also there are dynamic merging/unmerging routines which keep transport lines under inserters or side-loading at some limited range, maybe 9 tiles, while inserter-free lines can be 100 tiles long. These numbers are still to be calibrated. So far overall performance gains on items movement are at x50-100 with that O(1) optimization. Though it's not everything regarding belts, so actual gains are expected to be around x5-x10. Curved and straight belts are all merged together already, the next step will be embedding underground belts as part of a single very long line.

In the end only splitters should be the legitimate entities to break transport lines apart, in addition to some big 100-tile long limitation of how long transport line can be for the sake of a player picking/dropping items, rendering and other things to consider. So far factories performing at 25 ups start growing to 35-40 ups just because of that belts optimization, and belts are not everything these factories contain.

With 0.15 you will never ever have to build underground belts for the sake of performance :) Factorio's heart is beating nicely now and will not distract from blueprinting the truly important things.

If you remember from the previous FFF, our map downloader was having some extremely rare problems with some mysterious packets that would always get filtered over the Internet. We already had a fix for it, but I was curious what was going on. Thanks to the investigative power of the Factorio community, we found out that all those mysterious packets, before NAT, had a checksum of 0xFFFF. Admalledd from the forum sent some hand-crafted packets through his Internet connection and surprise, all packets would go through, except those with a checksum of 0xFFFF or 0x0000. At this point I would just assume this ISP(and some other few ISPs around the world) have some faulty hardware or software that do not handle these special cases of UDP checksums.


We released a 0.14 hotfix release that will include a fix for the map download. It will also fix the graphical issues caused by the new Nvidia drivers.

As usual, let us know what you think at the forums.

• Limit maximum texture size the game will try to use to 16384x16384 pixels.
  
• Fixed desync related to building of rail signals. more
  
• Fixed multiplayer map download getting stuck at 100% when using some broken routers.more
  

• Limit maximum texture size the game will try to use to 16384x16384 pixels.
  
• Fixed desync related to building of rail signals. more
  
• Fixed multiplayer map download getting stuck at 100% when using some broken routers.more
  

There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life.

So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things:

• Show configurable GUI alerts and play audio alerts based on circuit conditions.
• Play audio samples as controlled by the circuit network in a way that simple songs can be created.

The entity graphics are placeholder programmer graphics.



Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals.



And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network.

Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated.

https://youtu.be/Q1fszKmpwZM

Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low".
I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit.

There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF.

For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in ]
First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio.

But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic or on the question I posted on Stackexchange.

The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :)
This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen.Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue.

In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections.

As usual, let us know what you think at the forums.

There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life.

So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things:

• Show configurable GUI alerts and play audio alerts based on circuit conditions.
• Play audio samples as controlled by the circuit network in a way that simple songs can be created.

The entity graphics are placeholder programmer graphics.



Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals.



And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network.

Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated.

https://youtu.be/Q1fszKmpwZM

Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low".
I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit.

There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF.

For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in ]
First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio.

But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic or on the question I posted on Stackexchange.

The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :)
This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen.Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue.

In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections.

As usual, let us know what you think at the forums.

We have had some reports of users experiencing an issue with the game graphics after updating to the GeForce Driver 378.49 with a GeForce 10 series video card.

To workaround this issue, open the Factorio properties in steam, and set the launch options to:

We hope Nvidia will be able to address this issue shortly, if not we will release an update to limit the texture size by default.

Update: Nvidia released hotfix driver 378.57, but it doesn't fix the issue in Factorio. So we have limited maximum possible texture size in our code and released 0.14.22 to address this issue.

We have had some reports of users experiencing an issue with the game graphics after updating to the GeForce Driver 378.49 with a GeForce 10 series video card.

To workaround this issue, open the Factorio properties in steam, and set the launch options to:

We hope Nvidia will be able to address this issue shortly, if not we will release an update to limit the texture size by default.

Update: Nvidia released hotfix driver 378.57, but it doesn't fix the issue in Factorio. So we have limited maximum possible texture size in our code and released 0.14.22 to address this issue.

Hello, a wave of illness has afflicted the team these last few weeks, but things are starting to pick up again. With the collective health of the office back to normal, progress is advancing well on the features for 0.15.

We offer a lot of freedom to the modders of Factorio, this freedom has been of huge advantage to everyone involved, allowing interesting and fresh mechanics to be implemented with simple Lua script and our API.

With freedoms comes the fact that we can't control everything the modders want to do. In terms of visual design we have our own GUI elements under lock down, but mods can put things together in any way they like, and with no style guides or templates, we can end up with situations like this:



The player will understand that it isn't really our 'fault' that the buttons are not in a uniform style, but still it's an issue I wanted to try to address.

Typically a mod Gui will be created something like this:


This is very simple, and easy enough to understand, but will require each mod to define their own style, or use the LuaStyle script interface to set their style during the game. The issue of odd styling comes from perhaps there being no built in simple and effective styling mods can use. Another problem is that with multiple mods installed, there is no overall control about how and where the Gui elements interact and 'fight' with one another for space.

So to begin to help this, I've implemented an optional Lua script that modders can use, which should help unify things, as well as being simple to use for anybody new.


Which can look something like this:



While this is definitely optional, it really helps to tie together the style of the buttons.The separation of the button and frame flows will help to stop Gui fighting in the main 'left' gui. I'd also be interested in expanding the functionality of the mod-gui utility, so input and feedback from modders will be very helpful.

As Vaclav was finishing up the High-res train stop and signal fixes, he enlisted the help of Rseding to add the same color selection for stations as we have for the locomotives.



This minor addition really allows for much greater visual distinction between your different stations, and allow matching up your locomotives to their respective stations. There is also support to copy and paste the color from the train stop to the locomotive and vice-versa, so that you will always have a perfect match.
As always, if you have any comments or otherwise, please let us know on our forums.

Hello, a wave of illness has afflicted the team these last few weeks, but things are starting to pick up again. With the collective health of the office back to normal, progress is advancing well on the features for 0.15.

We offer a lot of freedom to the modders of Factorio, this freedom has been of huge advantage to everyone involved, allowing interesting and fresh mechanics to be implemented with simple Lua script and our API.

With freedoms comes the fact that we can't control everything the modders want to do. In terms of visual design we have our own GUI elements under lock down, but mods can put things together in any way they like, and with no style guides or templates, we can end up with situations like this:



The player will understand that it isn't really our 'fault' that the buttons are not in a uniform style, but still it's an issue I wanted to try to address.

Typically a mod Gui will be created something like this:


This is very simple, and easy enough to understand, but will require each mod to define their own style, or use the LuaStyle script interface to set their style during the game. The issue of odd styling comes from perhaps there being no built in simple and effective styling mods can use. Another problem is that with multiple mods installed, there is no overall control about how and where the Gui elements interact and 'fight' with one another for space.

So to begin to help this, I've implemented an optional Lua script that modders can use, which should help unify things, as well as being simple to use for anybody new.


Which can look something like this:



While this is definitely optional, it really helps to tie together the style of the buttons.The separation of the button and frame flows will help to stop Gui fighting in the main 'left' gui. I'd also be interested in expanding the functionality of the mod-gui utility, so input and feedback from modders will be very helpful.

As Vaclav was finishing up the High-res train stop and signal fixes, he enlisted the help of Rseding to add the same color selection for stations as we have for the locomotives.



This minor addition really allows for much greater visual distinction between your different stations, and allow matching up your locomotives to their respective stations. There is also support to copy and paste the color from the train stop to the locomotive and vice-versa, so that you will always have a perfect match.
As always, if you have any comments or otherwise, please let us know on our forums.