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.

Hello!

The prototyping of the nuclear power is 90% complete. Some parts of the planned stuff like cooling towers and closed water cycle were dropped. The main reason is that the jump the player needs to do when he wants to switch to the nuclear power is big enough already. The secondary goal is to not get too megalomaniac as there are lot of things our graphics department needs to handle for 0.15 already. We can always add these options later if we want to.

I would like to make clear, that all the nuclear related graphics on these pictures are just a placeholders (made by me), the proper graphics will be done later.

The first part of the process is mining of the uranium, which will be done exactly the same way as any other resource.



The uranium processing requires a new entity called centrifuge, it uses 10 ores to create Uranium 238 and Uranium 235. The ratio is set to be as in reality, which means, the Uranium 235 (The better one) has only 0.7% probability.

The uranium 238 itself is not enough to make the nuclear fuel, so it needs to be mixed with 235 again, but in bigger ratio than it had in the ore, specifically 5% of Uranium 235 needs to be in the mix.

There are different ways to handle the problem of leftovers of Uranium 238 in the real life, but to keep things from getting too complicated, the Factorio player invented the "Kovarex enrichment process", which is able to solve this problem.



Once the nuclear fuel is prepared, it can be inserted into the nuclear reactor, the most simple setup is one reactor with 4 boilers.



For every neighbour reactor, there is 100% energy production bonus with the same usage of fuel. This means that 2 connected reactors are more efficient and powerful, but its heat can't be fully used without the heat pipes (the red pipe placeholder), as each reactor needs 8 boilers to be connected to it in this configuration.



The more nuclear reactors connected, the more complex it becomes:



At this moment, there is no danger of the reactor meltdown, there is just maximum temperature of the reactor and the rest is wasted. We might add some risk into the reactors, but we might as well leave it as it is.

One of the new researches in 0.15 is the mining productivity research. It is infinite and every level adds 2% bonus to the mined resources, similar to the way the productivity modules work. Its price increases linearly so its rate of return increases as well.



It helps to greatly diminish the need to erase and build mines too often in bigger late game factories.

We are looking for an experienced reinforcement to our programming team, who would be working mostly on Factorio Mac OS X platform. If you have strong experience in this field and love challenges, you can find more information on our website.

https://www.factorio.com/job/senio-game-developer

As you might or might not know, Starcraft was always one of my favorite games. I spent way more time with it than I would like to admit.
Some time ago, long before I started working on Factorio, I started the bwapi project which provides C++ api to access the starcraft data (units, players, map etc.) and allows to control the units.



I didn't do anything with that for several years, and it lived its own life in the meantime, there are people writing ai as part of the university courses or just for fun and competition. There are tournaments of the AI bots every year since 2011, and the most amazing: Server that runs the bot battles 24/7 and streams it online at https://www.twitch.tv/certicky. They even use custom Module that automatically moves the screen around to show important parts of the map as the game runs, this is the true automation spirit!

Why am I writing this? Well I'm working on Factorio for almost 5 years now and I need a hobby side project, and writing the starcraft AI is perfect for it. It is fun, complex and it is automation! So if you want to compete with my future bot and the other 45 bot programmers, you are welcome.

And as always let us know what you think on our forums.

Hello!

The prototyping of the nuclear power is 90% complete. Some parts of the planned stuff like cooling towers and closed water cycle were dropped. The main reason is that the jump the player needs to do when he wants to switch to the nuclear power is big enough already. The secondary goal is to not get too megalomaniac as there are lot of things our graphics department needs to handle for 0.15 already. We can always add these options later if we want to.

I would like to make clear, that all the nuclear related graphics on these pictures are just a placeholders (made by me), the proper graphics will be done later.

The first part of the process is mining of the uranium, which will be done exactly the same way as any other resource.



The uranium processing requires a new entity called centrifuge, it uses 10 ores to create Uranium 238 and Uranium 235. The ratio is set to be as in reality, which means, the Uranium 235 (The better one) has only 0.7% probability.

The uranium 238 itself is not enough to make the nuclear fuel, so it needs to be mixed with 235 again, but in bigger ratio than it had in the ore, specifically 5% of Uranium 235 needs to be in the mix.

There are different ways to handle the problem of leftovers of Uranium 238 in the real life, but to keep things from getting too complicated, the Factorio player invented the "Kovarex enrichment process", which is able to solve this problem.



Once the nuclear fuel is prepared, it can be inserted into the nuclear reactor, the most simple setup is one reactor with 4 boilers.



For every neighbour reactor, there is 100% energy production bonus with the same usage of fuel. This means that 2 connected reactors are more efficient and powerful, but its heat can't be fully used without the heat pipes (the red pipe placeholder), as each reactor needs 8 boilers to be connected to it in this configuration.



The more nuclear reactors connected, the more complex it becomes:



At this moment, there is no danger of the reactor meltdown, there is just maximum temperature of the reactor and the rest is wasted. We might add some risk into the reactors, but we might as well leave it as it is.

One of the new researches in 0.15 is the mining productivity research. It is infinite and every level adds 2% bonus to the mined resources, similar to the way the productivity modules work. Its price increases linearly so its rate of return increases as well.



It helps to greatly diminish the need to erase and build mines too often in bigger late game factories.

We are looking for an experienced reinforcement to our programming team, who would be working mostly on Factorio Mac OS X platform. If you have strong experience in this field and love challenges, you can find more information on our website.

https://www.factorio.com/job/senio-game-developer

As you might or might not know, Starcraft was always one of my favorite games. I spent way more time with it than I would like to admit.
Some time ago, long before I started working on Factorio, I started the bwapi project which provides C++ api to access the starcraft data (units, players, map etc.) and allows to control the units.



I didn't do anything with that for several years, and it lived its own life in the meantime, there are people writing ai as part of the university courses or just for fun and competition. There are tournaments of the AI bots every year since 2011, and the most amazing: Server that runs the bot battles 24/7 and streams it online at https://www.twitch.tv/certicky. They even use custom Module that automatically moves the screen around to show important parts of the map as the game runs, this is the true automation spirit!

Why am I writing this? Well I'm working on Factorio for almost 5 years now and I need a hobby side project, and writing the starcraft AI is perfect for it. It is fun, complex and it is automation! So if you want to compete with my future bot and the other 45 bot programmers, you are welcome.

And as always let us know what you think on our forums.

From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha.

When the GPU it figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'):

You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque.

In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation:

Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha.

Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending:

This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering.

For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke.

Textures with pre-multiplied alpha also produce better results in texture filtering, which is probably the main reason why they are so widely used in the videogame industry.

Hello! Since I (V453000) last wrote the FFF about rails, I have spent a lot more time to actually work on them further. Just finishing the rails to the current state was a lot of work, and since the new angle of ties broke train signals pretty badly, it was a good time to make these in high resolution as well.

Per usual, as I started digging into it deeper and deeper, I discovered more and more problems like the inconsistent order of sprites, newly appearing issues with sprite drawing (the normal resolution sprites simply didn't show it, but in high resolution old issues become visible), or ridiculous problems like straight rail having different amount of ties in vertical and horizontal, so the chain signal metal plate wouldn't fit them.

Slowly but surely I went over all of the problems, the next mountain to climb was the train stop - since rail sizes changed, the train stop wouldn't fit the new rails anymore. Apart from that, the train stop is from a time when we made high resolution sprites differently, more and more reasons to do it as soon as possible.

There weren't as many unexpected problems as with the signals, just a legion of super specific layering cases, which were probably solved wrongly in the previous version.

There are probably going to be some small changes, but here you can see a little preview:

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

From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha.

When the GPU it figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'):

You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque.

In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation:

Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha.

Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending:

This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering.

For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke.

Textures with pre-multiplied alpha also produce better results in texture filtering, which is probably the main reason why they are so widely used in the videogame industry.

Hello! Since I (V453000) last wrote the FFF about rails, I have spent a lot more time to actually work on them further. Just finishing the rails to the current state was a lot of work, and since the new angle of ties broke train signals pretty badly, it was a good time to make these in high resolution as well.

Per usual, as I started digging into it deeper and deeper, I discovered more and more problems like the inconsistent order of sprites, newly appearing issues with sprite drawing (the normal resolution sprites simply didn't show it, but in high resolution old issues become visible), or ridiculous problems like straight rail having different amount of ties in vertical and horizontal, so the chain signal metal plate wouldn't fit them.

Slowly but surely I went over all of the problems, the next mountain to climb was the train stop - since rail sizes changed, the train stop wouldn't fit the new rails anymore. Apart from that, the train stop is from a time when we made high resolution sprites differently, more and more reasons to do it as soon as possible.

There weren't as many unexpected problems as with the signals, just a legion of super specific layering cases, which were probably solved wrongly in the previous version.

There are probably going to be some small changes, but here you can see a little preview:

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