Hello,the hopefully final 0.14 version was recently released, meanwhile most of the team have been assigned their major tasks for 0.15.

One of the tasks I picked up was to work on the long overdue combat balance. We identified some of the major problem areas. The most pressing issue is that many of the guns and ammo in the game are too underwhelming for their price, and others are completely useless. One example which clearly stands out if the rocket launcher ammo, rockets and explosive rockets. They cost quite a lot in terms of resources, and the time to set up their production. In combat, they are less effective then their cheaper counterparts, such as the flamethrower.

To illustrate the problem, Twinsen worked on his highly scientific graph of the current combat system, with the X and Y axis representing the Elapsed time, and Power respectively.



After some discussion for some different approaches, without much in the way of solid agreement, it was decided that we need to do some more testing. To ease this process I wrote a small internal mod that will allow us to quickly set up some consistent conditions, and see in a reliable and semi-deterministic way, what sort of effect even the smallest changes would have.



This will hopefully help us collect some solid comparisons for how the combat changes and evolves as the game goes onward. For now I only have a shortlist of what we are trying to accomplish:

• Nerf turret creeping
  
• Generally make the mid-game combat better
  
• Bring things more in line with one another in terms of damage and utility
  
• Make the biters less of an irritant, but still a threat

Community feedback will be really important for us on this topic, so please let us know your thoughts.

Steam has recently announced their Steam award nominations , and there are several categories you can nominate any game for. For example the "Just 5 more minutes" is for the games that keep you playing long long into the night. We think it is a really great idea, allowing the steam community to nominate titles in this way, so be sure to vote for your favorite games.

We had to include this week the absolutely spectacular combinator display by DaveMcW: https://youtu.be/mgfwwqwxdxY
If you like to read more about his creation, you can read his thread on the forum, or even read the recent PC gamer article about it. This player also proved to be a good chance to test the circuit network optimizations in 0.15, and in comparison to 0.14, it runs about 18x faster.

As always, let us know your thoughts and opinion on our forum

Hello,the hopefully final 0.14 version was recently released, meanwhile most of the team have been assigned their major tasks for 0.15.

One of the tasks I picked up was to work on the long overdue combat balance. We identified some of the major problem areas. The most pressing issue is that many of the guns and ammo in the game are too underwhelming for their price, and others are completely useless. One example which clearly stands out if the rocket launcher ammo, rockets and explosive rockets. They cost quite a lot in terms of resources, and the time to set up their production. In combat, they are less effective then their cheaper counterparts, such as the flamethrower.

To illustrate the problem, Twinsen worked on his highly scientific graph of the current combat system, with the X and Y axis representing the Elapsed time, and Power respectively.



After some discussion for some different approaches, without much in the way of solid agreement, it was decided that we need to do some more testing. To ease this process I wrote a small internal mod that will allow us to quickly set up some consistent conditions, and see in a reliable and semi-deterministic way, what sort of effect even the smallest changes would have.



This will hopefully help us collect some solid comparisons for how the combat changes and evolves as the game goes onward. For now I only have a shortlist of what we are trying to accomplish:

• Nerf turret creeping
  
• Generally make the mid-game combat better
  
• Bring things more in line with one another in terms of damage and utility
  
• Make the biters less of an irritant, but still a threat

Community feedback will be really important for us on this topic, so please let us know your thoughts.

Steam has recently announced their Steam award nominations , and there are several categories you can nominate any game for. For example the "Just 5 more minutes" is for the games that keep you playing long long into the night. We think it is a really great idea, allowing the steam community to nominate titles in this way, so be sure to vote for your favorite games.

We had to include this week the absolutely spectacular combinator display by DaveMcW: https://youtu.be/mgfwwqwxdxY
If you like to read more about his creation, you can read his thread on the forum, or even read the recent PC gamer article about it. This player also proved to be a good chance to test the circuit network optimizations in 0.15, and in comparison to 0.14, it runs about 18x faster.

As always, let us know your thoughts and opinion on our forum

Right now when you want to customize a particular mod you have to:

1. Know what folder the mods are stored on your computer
2. Unzip the mod
3. Figure out what line of which file has the thing you want to change
4. Save and optionally re-zip the mod
5. Hope what you changed is compatible with the way the rest of the mod works

The game also forces everyone playing on the same multiplayer session to have identical mod files so any changes you've made make it impossible for you to join others unless they also have made those changes. This also makes it difficult for mod developers to troubleshoot bug reports because they don't know what you might have changed.

This is obviously not so great and I want to address the main problem: there's no good way for mod developers to give users any portable way to configure their mods.

To fix this we're going to add the ability for mods to define settings that will be presented like our in-game options menu now under a new section "options -> mods". This will let mods give some basic information about what kind of setting they have and we can present it to the player in a (hopefully) nice GUI with verification and feedback about why what they've entered isn't valid (if it's not valid) as well as the ability to change them runtime should the particular setting allow it.

We can then sync these settings on joining multiplayer sessions (or not should you not want your settings to carry between games) and everything will just work.

My (Rseding91) favorite tasks are still optimizations. I can sit for hours (sometimes all day) working on improving some section of the code and not get bored. 0.12 saw a major improvement in performance and during 0.13 development there were a few edge case slowdowns that got fixed but nothing much was done during 0.14 development. For 0.15 I've started looking again at performance and not at the obvious slow areas. Mostly because there aren't any obvious huge slow areas (or we already know that 25,000 belts tend to be slow) but all of the surrounding code that gets run each tick. Honza (another Factorio developer) said it best to me the other day: "I think our performance issues are death by a thousand cuts." meaning there's no one thing that's particularly slow but everything is just a little bit slow.

I took a few larger save files and started looking at them and every time I would re-run the profiler some small piece of code would show up taking 1-2% of the time. I'd spend 20~ minutes re-writing it and then it takes < 0.1% of the time (not accurately measurable by the profiler). I did that for 3 days and when I finished with the saves I had the end result was almost a 2x speedup over 0.14. Our test suite was invaluable during all of this to make sure I didn't break anything in the name of performance.

The great part about these "micro optimizations" is that they are almost never specific to one thing but are shared pieces of code so improvements to them gives general gains across the entire game. The save files I was testing with that would run around 30 UPS in 0.14 are now running between 55 and 60 UPS in 0.15. There are still many more areas like this that can be addressed so I'm always interested in unique save files that stress different parts of the game.

Albert has spent some time this past week making a test render to see how the new train models will hold up in higher resolution settings, and has put together this UHD render of a simple train scene.



While the final render may look very pretty, it only has a minimal amount of post-processing applied, instead relying on the setup of the scene and the specifics of the render to really show off the latest models.

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

Right now when you want to customize a particular mod you have to:

1. Know what folder the mods are stored on your computer
2. Unzip the mod
3. Figure out what line of which file has the thing you want to change
4. Save and optionally re-zip the mod
5. Hope what you changed is compatible with the way the rest of the mod works

The game also forces everyone playing on the same multiplayer session to have identical mod files so any changes you've made make it impossible for you to join others unless they also have made those changes. This also makes it difficult for mod developers to troubleshoot bug reports because they don't know what you might have changed.

This is obviously not so great and I want to address the main problem: there's no good way for mod developers to give users any portable way to configure their mods.

To fix this we're going to add the ability for mods to define settings that will be presented like our in-game options menu now under a new section "options -> mods". This will let mods give some basic information about what kind of setting they have and we can present it to the player in a (hopefully) nice GUI with verification and feedback about why what they've entered isn't valid (if it's not valid) as well as the ability to change them runtime should the particular setting allow it.

We can then sync these settings on joining multiplayer sessions (or not should you not want your settings to carry between games) and everything will just work.

My (Rseding91) favorite tasks are still optimizations. I can sit for hours (sometimes all day) working on improving some section of the code and not get bored. 0.12 saw a major improvement in performance and during 0.13 development there were a few edge case slowdowns that got fixed but nothing much was done during 0.14 development. For 0.15 I've started looking again at performance and not at the obvious slow areas. Mostly because there aren't any obvious huge slow areas (or we already know that 25,000 belts tend to be slow) but all of the surrounding code that gets run each tick. Honza (another Factorio developer) said it best to me the other day: "I think our performance issues are death by a thousand cuts." meaning there's no one thing that's particularly slow but everything is just a little bit slow.

I took a few larger save files and started looking at them and every time I would re-run the profiler some small piece of code would show up taking 1-2% of the time. I'd spend 20~ minutes re-writing it and then it takes < 0.1% of the time (not accurately measurable by the profiler). I did that for 3 days and when I finished with the saves I had the end result was almost a 2x speedup over 0.14. Our test suite was invaluable during all of this to make sure I didn't break anything in the name of performance.

The great part about these "micro optimizations" is that they are almost never specific to one thing but are shared pieces of code so improvements to them gives general gains across the entire game. The save files I was testing with that would run around 30 UPS in 0.14 are now running between 55 and 60 UPS in 0.15. There are still many more areas like this that can be addressed so I'm always interested in unique save files that stress different parts of the game.

Albert has spent some time this past week making a test render to see how the new train models will hold up in higher resolution settings, and has put together this UHD render of a simple train scene.



While the final render may look very pretty, it only has a minimal amount of post-processing applied, instead relying on the setup of the scene and the specifics of the render to really show off the latest models.

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

Hello!

There are many things we want to have finished for 0.15, so the estimate isn't precise. The plan is to have approximately 3 months to implement all the planned changes, so it could be expected around february 2017.

The decoratives optimisations that were mentioned in the fff-157 are finished and working well. Not only the save file has been reduced (46Mb to 25 Mb on my map), but the memory footprint and overall performance is better. The reason of the performance improvement is, that once decorative isn't regular entity, it doesn't need to be iterated over when doing area based entity search (typically for collision checks) and also the memory fragmentation is not that bad.

Rseding is doing a lot of small optimisations for 0.15. Each of them is usually not that big, but the overall gain starts to be noticeable. We will cover them in more details in the next fff, but I expect that the 0.15 will provide a big performance boost.

We created the basic specification of the nuclear power this week, so we can start working on it.

The plan is to implement the nuclear power in a way, that it is almost always more efficient to make bigger and more complex setup compared to just copy pasting the "standard nuclear power blueprint" over and over. This is the list of changes and additions we are planning.

1. Water and steam
To make the other changes reasonable, we had to go back and change how the basic boiler->steam engine power generation works.

These are the changes of rules:

• Water above 100 degrees is considered steam.
  
• Steam engines only work on steam, not hot water
  
• Boilers only accept water, not steam.

This is how the boiler works now:



In 0.15, it will have extra output for steam at fixed temperature:


This way, the basic setups will not change that much, as instead of this:



The players could do something like this:



2. Steam turbine
Apart from being much more powerful version of the steam engine, the steam turbine will also work differently.
The current (basic) steam engine uses the fluid it gets to generate electricity and consumes it.
The steam turbine will just cool the steam down. Lets say from 500°C to 120°C. But the result will still be steam.
You can either send it to the regular steam engine to get rid of it, or if you want to be more efficient, you can send it back to the boilers.
But the boilers only accept water, not steam. This is where the next piece will be used.

3. Cooling tower
Cooling tower mainly looks good and adds the iconic feel of power plant, but it will also have the same purpose in factorio as in real life. It accepts steam, and cools it down enough to make water out of it again, so it can be used in boilers. The main advantage is, that heating 95°C water back to steam requires much less energy compared to heating the 25°C water you get from the lake.

4. The nuclear reactor
All the previous changes are usable also with the regular coal boilers and provide more efficient and powerful way to use the heating power. The nuclear reactor is just a more powerful way to generate heat.

The nuclear reactor will process the nuclear fuel (Its processing isn't specified yet) and generate heat.
The reactor will have several levels of production, the more active, the more energy it does and the more efficient it is. The problem is, that changing between the production levels won't be instant, so trying it shut down too late might not be enough to prevent overheating and explosion ... a big one. It will be certainly possible to make not so efficient but safe setups that will be simple to build, but the most efficient reactor will require circuit wiring that controls its production levels based on the energy storage capacities, heat and other things. We are just trying to force easy to learn hard to master again.

The additional feature of reactors is, that two reactors next to each other connect. (It should be obvious, but before you ask in the comments, no this is not going to be the final look of the reactor ^^)



Reactors support efficiency of the neighbours, so this way the production can be increased even more, but the more reactor units are connected together, the harder it is to transfer away the heat concentrated on a small place fast enough.

5. Heat pipes
The heat pipes will be used to transfer the heat from the reactors to the boilers. The heat pipes will have to branch a lot to connect to enough of boilers as the efficiency of heat transfer decreases with distance quite fast.

I was even considering adding option that is not realistic (at least with the current technology), but it could add a lot of interesting gameplay possibilities. Imagine that you could store the heat in some kind of item. Maybe some kind of special metal with huge heat capacity. That would mean, that you could use the logistics to transfer the heat from the central reactor place even faster using our logistics possibilities. I like the idea that the biggest possible reactor could be only done by having high capacity train stations all around transferring the heat away in a huge quantities.

We are starting the last sprint for finishing factorio 1.0 and this requires support of the graphics department so we are looking for an artist. The work is not simple, so if you are not into complicated 3d stuff, Blender, tilesets, complex pipeline with scripting, postprocessing with After Effects, you wouldn't like this position. Not the mention the understanding of aesthetics and geometrical tricks is also required. If you think your profile is fitting enough don't hesitate to send us your portfolio.

And as always, stop by at our forums and let us know what you think.

Hello!

There are many things we want to have finished for 0.15, so the estimate isn't precise. The plan is to have approximately 3 months to implement all the planned changes, so it could be expected around february 2017.

The decoratives optimisations that were mentioned in the fff-157 are finished and working well. Not only the save file has been reduced (46Mb to 25 Mb on my map), but the memory footprint and overall performance is better. The reason of the performance improvement is, that once decorative isn't regular entity, it doesn't need to be iterated over when doing area based entity search (typically for collision checks) and also the memory fragmentation is not that bad.

Rseding is doing a lot of small optimisations for 0.15. Each of them is usually not that big, but the overall gain starts to be noticeable. We will cover them in more details in the next fff, but I expect that the 0.15 will provide a big performance boost.

We created the basic specification of the nuclear power this week, so we can start working on it.

The plan is to implement the nuclear power in a way, that it is almost always more efficient to make bigger and more complex setup compared to just copy pasting the "standard nuclear power blueprint" over and over. This is the list of changes and additions we are planning.

1. Water and steam
To make the other changes reasonable, we had to go back and change how the basic boiler->steam engine power generation works.

These are the changes of rules:

• Water above 100 degrees is considered steam.
  
• Steam engines only work on steam, not hot water
  
• Boilers only accept water, not steam.

This is how the boiler works now:



In 0.15, it will have extra output for steam at fixed temperature:


This way, the basic setups will not change that much, as instead of this:



The players could do something like this:



2. Steam turbine
Apart from being much more powerful version of the steam engine, the steam turbine will also work differently.
The current (basic) steam engine uses the fluid it gets to generate electricity and consumes it.
The steam turbine will just cool the steam down. Lets say from 500°C to 120°C. But the result will still be steam.
You can either send it to the regular steam engine to get rid of it, or if you want to be more efficient, you can send it back to the boilers.
But the boilers only accept water, not steam. This is where the next piece will be used.

3. Cooling tower
Cooling tower mainly looks good and adds the iconic feel of power plant, but it will also have the same purpose in factorio as in real life. It accepts steam, and cools it down enough to make water out of it again, so it can be used in boilers. The main advantage is, that heating 95°C water back to steam requires much less energy compared to heating the 25°C water you get from the lake.

4. The nuclear reactor
All the previous changes are usable also with the regular coal boilers and provide more efficient and powerful way to use the heating power. The nuclear reactor is just a more powerful way to generate heat.

The nuclear reactor will process the nuclear fuel (Its processing isn't specified yet) and generate heat.
The reactor will have several levels of production, the more active, the more energy it does and the more efficient it is. The problem is, that changing between the production levels won't be instant, so trying it shut down too late might not be enough to prevent overheating and explosion ... a big one. It will be certainly possible to make not so efficient but safe setups that will be simple to build, but the most efficient reactor will require circuit wiring that controls its production levels based on the energy storage capacities, heat and other things. We are just trying to force easy to learn hard to master again.

The additional feature of reactors is, that two reactors next to each other connect. (It should be obvious, but before you ask in the comments, no this is not going to be the final look of the reactor ^^)



Reactors support efficiency of the neighbours, so this way the production can be increased even more, but the more reactor units are connected together, the harder it is to transfer away the heat concentrated on a small place fast enough.

5. Heat pipes
The heat pipes will be used to transfer the heat from the reactors to the boilers. The heat pipes will have to branch a lot to connect to enough of boilers as the efficiency of heat transfer decreases with distance quite fast.

I was even considering adding option that is not realistic (at least with the current technology), but it could add a lot of interesting gameplay possibilities. Imagine that you could store the heat in some kind of item. Maybe some kind of special metal with huge heat capacity. That would mean, that you could use the logistics to transfer the heat from the central reactor place even faster using our logistics possibilities. I like the idea that the biggest possible reactor could be only done by having high capacity train stations all around transferring the heat away in a huge quantities.

We are starting the last sprint for finishing factorio 1.0 and this requires support of the graphics department so we are looking for an artist. The work is not simple, so if you are not into complicated 3d stuff, Blender, tilesets, complex pipeline with scripting, postprocessing with After Effects, you wouldn't like this position. Not the mention the understanding of aesthetics and geometrical tricks is also required. If you think your profile is fitting enough don't hesitate to send us your portfolio.

And as always, stop by at our forums and let us know what you think.

• Fixed LuaSurface::can_place_entity didn't work for tile ghosts. more
  
• Fixed curved rails woudln't render correctly as enemy forces.
  
• Fixed searching in the technology GUI wouldn't work in some cases. more
  
• Fixed that the config option other.use_version_filter_in_browse_games_gui defaulted to false on linux. more
  
• Fixed "E" (close GUI) couldn't be used when numeric-input fields were focused. more
  
• Fixed that disabling recipe groups in the settings disabled subgroups as well.
  
• Fixed that the changelog GUI allowed editing the read-only text. more
  
• Fixed (again) that the natural signal direction wasn't picked primarily when 2 way signal and normal signal can be built on the same spot.
  
• Fixed that deactivated belts would sometimes still move items if connected to Underground Belts or Loaders. more
  
• Fixed that the multiplayer game could crash randomly due to the packet fragmentation implementation issue.
  

• Added LuaPlayer::disable_recipe_subgroups.
  

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

• Fixed LuaSurface::can_place_entity didn't work for tile ghosts. more
  
• Fixed curved rails woudln't render correctly as enemy forces.
  
• Fixed searching in the technology GUI wouldn't work in some cases. more
  
• Fixed that the config option other.use_version_filter_in_browse_games_gui defaulted to false on linux. more
  
• Fixed "E" (close GUI) couldn't be used when numeric-input fields were focused. more
  
• Fixed that disabling recipe groups in the settings disabled subgroups as well.
  
• Fixed that the changelog GUI allowed editing the read-only text. more
  
• Fixed (again) that the natural signal direction wasn't picked primarily when 2 way signal and normal signal can be built on the same spot.
  
• Fixed that deactivated belts would sometimes still move items if connected to Underground Belts or Loaders. more
  
• Fixed that the multiplayer game could crash randomly due to the packet fragmentation implementation issue.
  

• Added LuaPlayer::disable_recipe_subgroups.
  

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

Hello,
Rseding has just arrived for another 6 week visit here at the office, and his timing is pretty great as we start shifting the focus onto 0.15, of which our to-do list is extremely long.

We have just launched 0.14.18 as our stable build, this means it has been pushed to all users on steam, along with the website users being prompted to automatically update. Stable however doesn't mean we won't be releasing any further 0.14 builds, as inevitably with more people playing the release, there will be many more bugs found. In fact we are already in the process of releasing a quick fix for the stable, as people have reported that the demo does not work, a minor issue to most, but something that might not give the best first impression.

Once we have all the kinks sorted out, stable release means we will be taking a look at our marketing options in the upcoming weeks. We feel that 0.14 is a good distance from the early access release, and a whole lot more improved from the stable 0.12 we initially launched with, so it is a good time to make another push to spread the word. As always, we owe much of our success to all of the players who continue to make the effort of telling their friends about the game, and we would have never come so far without such a great community supporting us.

As kovarex mentioned in one of the recent FFF, the current rails are using a very simple system which aims to minimize the amount of used sprites, so it only uses five sprite types: horizontal rail, vertical rail, diagonal rail, horizontal curve and vertical curve.

Then these four sprite types were flipped and rotated to their positions. To ‎make this visually work, it was necessary to use top-down projection with minimal signs of perspective. Which is a gigantic limitation, especially since almost all of the entities are projected at 45 degrees. Each of the four sprite types had four layers each to prevent things from overlapping in junctions, I will describe that in more detail later down.



Old and new basic rail rings. On the left same colour shows identical sprites. On the right all sprites are unique.

Now, we are defining unique sprite for each rail piece, and for straight ones we add 2 extra variations. The main benefit of this is removing the top down limitation‎ and having the rails more consistent with the rest of the game. Another aim is getting them into high resolution - and since the old rails were made in 2D, any kind of conversion to both more resolution and a different perspective wasn't doable, so we took our chance to redesign them. The "more 3D" perspective brought new problems though. Most of them are fixable through adding more layers...



First issue appeared fast - the vertical sides of rails would overlap the top side in junctions. I have been battling this exact problem in OpenTTD with no success for a long time, so I immediately knew that the solution is to split them into 2 layers, something I couldn't do back then, but we can in factorio.



Proceeding further, the old rails had the ties (sleepers/ wood planks)‎ at 45degrees on diagonal tracks in order to be perpendicular to them. Which didn't look utterly wrong as the whole thing was top-down - it even made sense in that way. But now, when at 45 degrees, it suddenly looked very wrong, so it had to be redone. Another thing we don’t really know why is that the old rails had more ties in horizontal view than in vertical, which should be exactly the opposite way to make the illusion of perspective… so we fixed that, too.



Redoing the ties was not that easy though, as they need to tile properly to all other combinations where they could connect. As I soon realized, doing this by trial and error / by eye was extremely tedious and took a long time without any results, I would fix one combination and other 2 combinations would break.

Luckily, blender has a very convenient feature for this called Group instances, which lets me group objects, and the use their clones to preview all the combinations with a live preview. The slight issue was that there is 148 ties, and apart from grouping they also need to be cut by the grid to represent how the final sprite is going to look.

Doing this manually is tedious and if I needed to repeat the process, my brain would probably derail. So I spent a few days getting into blender's python, and with the help of our programmers, we managed to create a script which automatically detects if an object has an intersection in a sprite, and cuts it + groups it to that sprite if it does. This creates a live preview which makes it very easy to see what is tiling with what. Automation, anyone?



To make entities look nice, almost all of them have some kind of integration as we call it. This is usually a slight dark outline/glow where they touch the ground. As a result, it looks more connected to the ground, and makes sure that it works in all the various terrains we have (and Jurek is adding more at this very moment).Next step was to make the rails integrate with the terrain properly. The old rails had just a very binary noise without any semi-transparency, which is simple but hides yet another problem - when tracks overlap in junctions, the semi-transparency starts stacking on top of each other. In some cases there is unfortunately no systematic solution so it was solved visually to minimize the effect.

As I mentioned earlier, the old rails were using 4 layers. Worth mentioning that only 3 of them were absolutely necessary to reach the same functionality. Since the rail metal parts needed splitting into two layers with the new system, we are suddenly using all 4 of them, and we are even adding a 5th layer to have junctions draw more nicely.



Early in the process (after the first render), I quickly realized that the rails are using almost 200 images when counting both normal and high resolution. After every re-rendering, I would have to go and rename all of them because their format needs slight adjustment for our naming conventions, and I would have to crop each of them. So, for the first time I attempted to write a python script to do these things for me, and it’s magic! Automation is magic?

And then I went and iterated the rails over and over again to get a nice result.



Once again we discovered that making high resolution sprites isn’t just 'render it in double size', as you can probably tell from reading the above. Especially with something in totally different projection than the previous version. We believe the result is worth it in the end.

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