Hello Factorians,

Most of the week has been spent by tweaking and fixing stuff that keeps coming up for the Monday release. Even though things seem to work reasonably well for us a lot of the reported issues are to be expected. Especially regarding the Matching Server and the Mod Portal. It is quite tricky to test these things in our limited environment. So please keep calm and report the bugs=)

Some time ago we came up with an idea of involving more people from the team in writing Friday Facts than just kovarex or tomas. The motivation was to take off quite some responsibility from our shoulders but also to give other team members the opportunity to present their work - which we believe can be interesting to the readers. So slowly, posts written mostly by other developers (related to what they currently work on) started appearing. We would like to go in this one even further. So today, the post is written by Albert, our art director, who will give some introduction into the project from the point of view of the graphics creation and where he is going to steer the project art-wise in the future.


Factorio is made in a way that I consider very organic. What I mean is that we have a general plan, a goal. But in the way of approaching this goal we are able to sit and watch, and see how it goes and tweak it if necessary.

Always with the intention of being honest with the project and ourselves, in a realistic way, we see if the plan is working or not.
Normally it works but not fully 100%. Or it works just on paper but it won't work in the reality.
So at that point is where we need to accomplish the plan by having modifications and inserting unexpected additions.

These unexpected additions can be the difference in between bad, regular, good or fantastic.
So they are very important for all of us. One significant example of what I mean is the entire train system.
After having it working since long and playing with it and observing how you players use it, we come out with huge improvements and additions.
I'm not saying that the entire train system is now perfect, but it is much better. I hope you will feel it (see the comparison below).

After all that time of development, and experimenting, Factorio is in a stage where we can see less or more easily how to improve it, and this is the point I wanted to get in.

The plans for the future visuals can be separated in 4 main branches:


Let's face it, we can do it better, and we want to. GUI shouldn't be improvised anymore, now we have the big picture. I'm going to be focused in this task together with Jan, our new programmer who has shown the skills and sensitivity to take care of this delicate matter. Together and with the feedback of the entire team we will rethink and re-shape the whole GUI in order to go for the final version.


Kovarex said long time ago that we are preparing the engine for playing in high-res. Since then, every new entity we do is designed and rendered for having 2 versions: normal and HR.

Now, we have to move backwards in order to have the old entities like inserters, transport-belts, pipes, terrains, doodads, and a huge etc., in HR also.

This is not a matter of just render it in double resolution, many things won't work with double size because the original design was meant to be just normal resolution.

This can be bad, but I prefer to take it in the good way because now we have the chance to improve the design of many of the old entities and give them the modern and final direction we want for the game. So this subject is divided into re-render in HR and redesign old entities also.

There' another subcategory in this subject, the icons. The plan is to to have all the icons in HR.


The actual terrain we use now is fine to me, but we would like to expand it in order to get more variety in the final picture.
Jurek is our new 3d artist, he started this week in the studio and he's now playing and experimenting with terrain in order to get this variety of environment we want for the game. Good luck for Jurek : )


The studio is plenty of programmers, really, if you go to the toilette or the kitchen or anywhere, you will find some programmer there doing programmer stuff. That's great because the huge task of bug-fixing can be covered by a big part of them, and the game designer - kovarex - can be free to invent and prototype new entities.
This means a stream of tasks for the graphic department. This will be covered by Vaclav and me, So I will take the concept and work on it, and once it is ready, Vaclav can work on 3d for making it real and introduce it into the game.

Until here the big picture of the general plan for the art side of Factorio, we can cover them in more detail, and probably we will. Also there's some other secondary tasks but it looks that the GFX reports will happen more often, so let's take them for another day.

Also do not expect to have all this ready immediately, we would love to have them ASAP, but if something I learned from Factorio is that there's no easy stuff. What it looks easy, probably will take more than what you expect. So no promises, but very good intentions.


If you want to comment anything about the ideas above exposed, please use the regular channel in the forums as always.
Thanks for the interest and see you in future posts.

Hello Factorians,

Most of the week has been spent by tweaking and fixing stuff that keeps coming up for the Monday release. Even though things seem to work reasonably well for us a lot of the reported issues are to be expected. Especially regarding the Matching Server and the Mod Portal. It is quite tricky to test these things in our limited environment. So please keep calm and report the bugs=)

Some time ago we came up with an idea of involving more people from the team in writing Friday Facts than just kovarex or tomas. The motivation was to take off quite some responsibility from our shoulders but also to give other team members the opportunity to present their work - which we believe can be interesting to the readers. So slowly, posts written mostly by other developers (related to what they currently work on) started appearing. We would like to go in this one even further. So today, the post is written by Albert, our art director, who will give some introduction into the project from the point of view of the graphics creation and where he is going to steer the project art-wise in the future.


Factorio is made in a way that I consider very organic. What I mean is that we have a general plan, a goal. But in the way of approaching this goal we are able to sit and watch, and see how it goes and tweak it if necessary.

Always with the intention of being honest with the project and ourselves, in a realistic way, we see if the plan is working or not.
Normally it works but not fully 100%. Or it works just on paper but it won't work in the reality.
So at that point is where we need to accomplish the plan by having modifications and inserting unexpected additions.

These unexpected additions can be the difference in between bad, regular, good or fantastic.
So they are very important for all of us. One significant example of what I mean is the entire train system.
After having it working since long and playing with it and observing how you players use it, we come out with huge improvements and additions.
I'm not saying that the entire train system is now perfect, but it is much better. I hope you will feel it (see the comparison below).

After all that time of development, and experimenting, Factorio is in a stage where we can see less or more easily how to improve it, and this is the point I wanted to get in.

The plans for the future visuals can be separated in 4 main branches:


Let's face it, we can do it better, and we want to. GUI shouldn't be improvised anymore, now we have the big picture. I'm going to be focused in this task together with Jan, our new programmer who has shown the skills and sensitivity to take care of this delicate matter. Together and with the feedback of the entire team we will rethink and re-shape the whole GUI in order to go for the final version.


Kovarex said long time ago that we are preparing the engine for playing in high-res. Since then, every new entity we do is designed and rendered for having 2 versions: normal and HR.

Now, we have to move backwards in order to have the old entities like inserters, transport-belts, pipes, terrains, doodads, and a huge etc., in HR also.

This is not a matter of just render it in double resolution, many things won't work with double size because the original design was meant to be just normal resolution.

This can be bad, but I prefer to take it in the good way because now we have the chance to improve the design of many of the old entities and give them the modern and final direction we want for the game. So this subject is divided into re-render in HR and redesign old entities also.

There' another subcategory in this subject, the icons. The plan is to to have all the icons in HR.


The actual terrain we use now is fine to me, but we would like to expand it in order to get more variety in the final picture.
Jurek is our new 3d artist, he started this week in the studio and he's now playing and experimenting with terrain in order to get this variety of environment we want for the game. Good luck for Jurek : )


The studio is plenty of programmers, really, if you go to the toilette or the kitchen or anywhere, you will find some programmer there doing programmer stuff. That's great because the huge task of bug-fixing can be covered by a big part of them, and the game designer - kovarex - can be free to invent and prototype new entities.
This means a stream of tasks for the graphic department. This will be covered by Vaclav and me, So I will take the concept and work on it, and once it is ready, Vaclav can work on 3d for making it real and introduce it into the game.

Until here the big picture of the general plan for the art side of Factorio, we can cover them in more detail, and probably we will. Also there's some other secondary tasks but it looks that the GFX reports will happen more often, so let's take them for another day.

Also do not expect to have all this ready immediately, we would love to have them ASAP, but if something I learned from Factorio is that there's no easy stuff. What it looks easy, probably will take more than what you expect. So no promises, but very good intentions.


If you want to comment anything about the ideas above exposed, please use the regular channel in the forums as always.
Thanks for the interest and see you in future posts.

Hello all,

The hype for the upcoming 0.13.0 release has been growing. There are two news I can give you at the moment. As usual one is "bad" and the other is "good". So let's start with the bad one. The release has been postponed. Now the good one. The release has a fixed and specific date now (as opposed to "yeah soonish ..."). The date is 27th of June (a week from Monday). This is a hard deadline. Basically unless something very unexpected happens (i.e. the office being hit by the meteor and our release server not surviving the impact=)) that is when the release will be.

There are a few good reasons for us to postpone the release.

• The NAT punching (see the rest of the post) has been just finished and we need to do some testing of it.
• The mod portal requires some final tweaks to be at least basically functional.
• Issues are still being found during internal playtesting.
• kovarex is away for holidays and in his words "he prefers to relax without worrying about all the bug reports coming up after the release"

Just to share one of the many many issues / details that we came across during the playtesting. Below you can see a debugging visualisation for the smoke animation. Michal (posila) has been using it to figure out if the smoke animation is not getting stuck (which it was) and if the sprites are being drawn in the proper order (z axis wise).



In FFF 139 we talked abouta matching server that is going to be integrated in 0.13.0.The matching server will allow you to mark your multiplayer game as public andannounce it to other players, you know how it usually works.

Tomas implemented the server and it's counterpart in Factorio itself, but wedidn't get around to testing it as a whole for a long time.Eventually (while still not testing the feature), we figured that the server willnot work for us here at the office, because we are hopelessly behind NAT (and withUPnP disabled, before you even ask).This realisation made us move the "NAT punching" card from "Ideas for 0.14" to "Priority".

When a client wants to connect to a server, the server needs to somehow announceits IP address and port for the client to connect to.For a web server this is done using DNS (and pre-determined port numbers), forFactorio multiplayer the matching server has the same role.

With the server behind NAT there are two problems.

First there is no way for the server to determine its IP address and port withoutexternal help and the IP address and port might not be the same for everyone onthe internet.

To solve this we have yet another two servers (called pingpong1 and pingpong2!).When a server starts it asks both of them "What is my IP address?".If we get an answer from both and the answers are the same, it means that the addressreceived should work for all other clients on the internet.If we receive only one of the answers or if the answers differ, then something iswrong and you're out of luck :-)



The second problem is that most NATs in use will not allow an incoming packetunless there have already been some data sent to the address and port that originatedthe packet. After some time

We avoid this problem by keeping a connection open between the game server andpingpong with periodic keepalive packets.When a client wants to connect to the server through matching server, it firstsends a message to the server through pingpong which makes the game server senda first packet to the client and open the mapping in its NAT.



The behavior we use is actually a specialised version of STUNand ICEadapted to run over Factorio protocol.And it looks like it's working :).Unfortunately it will not work under all circumstances (we expect about 70%), butbetter than nothing, right? :-).

The comment thread at our forums is ready.

Next FFF edition will most probably be written by Albert about recent changes and progress in our graphics department.

Hello all,

The hype for the upcoming 0.13.0 release has been growing. There are two news I can give you at the moment. As usual one is "bad" and the other is "good". So let's start with the bad one. The release has been postponed. Now the good one. The release has a fixed and specific date now (as opposed to "yeah soonish ..."). The date is 27th of June (a week from Monday). This is a hard deadline. Basically unless something very unexpected happens (i.e. the office being hit by the meteor and our release server not surviving the impact=)) that is when the release will be.

There are a few good reasons for us to postpone the release.

• The NAT punching (see the rest of the post) has been just finished and we need to do some testing of it.
• The mod portal requires some final tweaks to be at least basically functional.
• Issues are still being found during internal playtesting.
• kovarex is away for holidays and in his words "he prefers to relax without worrying about all the bug reports coming up after the release"

Just to share one of the many many issues / details that we came across during the playtesting. Below you can see a debugging visualisation for the smoke animation. Michal (posila) has been using it to figure out if the smoke animation is not getting stuck (which it was) and if the sprites are being drawn in the proper order (z axis wise).



In FFF 139 we talked abouta matching server that is going to be integrated in 0.13.0.The matching server will allow you to mark your multiplayer game as public andannounce it to other players, you know how it usually works.

Tomas implemented the server and it's counterpart in Factorio itself, but wedidn't get around to testing it as a whole for a long time.Eventually (while still not testing the feature), we figured that the server willnot work for us here at the office, because we are hopelessly behind NAT (and withUPnP disabled, before you even ask).This realisation made us move the "NAT punching" card from "Ideas for 0.14" to "Priority".

When a client wants to connect to a server, the server needs to somehow announceits IP address and port for the client to connect to.For a web server this is done using DNS (and pre-determined port numbers), forFactorio multiplayer the matching server has the same role.

With the server behind NAT there are two problems.

First there is no way for the server to determine its IP address and port withoutexternal help and the IP address and port might not be the same for everyone onthe internet.

To solve this we have yet another two servers (called pingpong1 and pingpong2!).When a server starts it asks both of them "What is my IP address?".If we get an answer from both and the answers are the same, it means that the addressreceived should work for all other clients on the internet.If we receive only one of the answers or if the answers differ, then something iswrong and you're out of luck :-)



The second problem is that most NATs in use will not allow an incoming packetunless there have already been some data sent to the address and port that originatedthe packet. After some time

We avoid this problem by keeping a connection open between the game server andpingpong with periodic keepalive packets.When a client wants to connect to the server through matching server, it firstsends a message to the server through pingpong which makes the game server senda first packet to the client and open the mapping in its NAT.



The behavior we use is actually a specialised version of STUNand ICEadapted to run over Factorio protocol.And it looks like it's working :).Unfortunately it will not work under all circumstances (we expect about 70%), butbetter than nothing, right? :-).

The comment thread at our forums is ready.

Next FFF edition will most probably be written by Albert about recent changes and progress in our graphics department.

Hello!

Most of this week was spent by switching between playtesting and fixing bugs/issues found when doing so. We get little bit further in the technology tree every day as we play our multiplayer playtest game, it always uncovers few bugs or desyncs which we fix immediately so we can continue playing.
We also tweak some inconvenient things. For example, once we are able to build rails fast with the rail builder, it was annoying to mine these when you misaligned them, so we just halved the mining time of rails. The inventory space was running out in the later game, so we made the armor give the character an inventory size bonuses (up to 30).

We felt that the evolution factor growth doesn't slow down enough towards the higher value. In our specific game, it probably grew faster than usually as Scott was more than eager to test the new fire mechanics by setting every forest he found on fire. So we couldn't know what affected the evolution factor the most. We changed the formula of the evolution factor growth and added command /evolution. The game now tracks which factors contributed to the evolution, so you can get something like this:

Evolution factor 0.8702 (Time 9%)(Pollution 57%)(Spawner kills 32%)

It is great for balancing, but the players can use it as well, so they have a better clue of what is going on.

At this stage it is still faster to fix bugs internally rather than going through the bug section on the forums, that is why we didn't released so far, but it is starting to be quite playable these days, so there is a good chance for release next week :)

Once we decided that everything will be circuit connectable, Robert and Albert agreed that the wire can't just end in the middle of the entity, that it needs something more. So there is a small circuit box sprite attached when the entity is connected. I have to say, that it adds a nice touch to it.



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

Hello!

Most of this week was spent by switching between playtesting and fixing bugs/issues found when doing so. We get little bit further in the technology tree every day as we play our multiplayer playtest game, it always uncovers few bugs or desyncs which we fix immediately so we can continue playing.
We also tweak some inconvenient things. For example, once we are able to build rails fast with the rail builder, it was annoying to mine these when you misaligned them, so we just halved the mining time of rails. The inventory space was running out in the later game, so we made the armor give the character an inventory size bonuses (up to 30).

We felt that the evolution factor growth doesn't slow down enough towards the higher value. In our specific game, it probably grew faster than usually as Scott was more than eager to test the new fire mechanics by setting every forest he found on fire. So we couldn't know what affected the evolution factor the most. We changed the formula of the evolution factor growth and added command /evolution. The game now tracks which factors contributed to the evolution, so you can get something like this:

Evolution factor 0.8702 (Time 9%)(Pollution 57%)(Spawner kills 32%)

It is great for balancing, but the players can use it as well, so they have a better clue of what is going on.

At this stage it is still faster to fix bugs internally rather than going through the bug section on the forums, that is why we didn't released so far, but it is starting to be quite playable these days, so there is a good chance for release next week :)

Once we decided that everything will be circuit connectable, Robert and Albert agreed that the wire can't just end in the middle of the entity, that it needs something more. So there is a small circuit box sprite attached when the entity is connected. I have to say, that it adds a nice touch to it.



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

Hello!

I guess that not so many people really expected that the target day of the 1st of June might be the actual release day. The day was mainly a psychological trick for us to finish all the little fixes and not to start any new projects, so we might be only week or two late instead of months. We started the first multiplayer play-tests last week, but they didn't last long. After the first hour of connection issue fixes, the game desynced every 15 seconds.

The process of determinism fixing that we first experienced when stabilizing 0.11 is now well known to us. With the tools we prepared and partially explained in friday facts 63, we were able to identify and fix determinism issues much much faster than before. It took just a few days compared to several months back then. The last playtest day was 2 days ago, and we were able to play a game where Linux, Mac and Windows players were all present. It lasted a few hours and no major issues were found so we are getting there.

I also have to admit, that the discovery of http://slither.io stole approximately 2 days of our dev time, as the game is really really great :) So if you can't wait for Factorio release, I advice you to try the game in the meantime.

TL;DR
If the further playtesting goes well, the release could happen next week, but you never know.

The information about the mod portal is brought to you by Martin, the train guy and recently also the mod portal guy.

The mod portal is a long awaited feature and it is finally happening! With the release of 0.13, we will be launching the mod portal website, along with an in-game integration. The base of the project was created by the original creator of factoriomods.com. The mod portal can be viewed by anyone, but you will have to log in with your factorio account to download mods, same goes for the in-game version.


Mostly due to lack of time and the size of the project, it is not in a finished state (and will not be completely finished with the 0.13 release). It contains many bugs and it's missing a fair amount of features that will be coming with later updates. All the graphics of the website or the in-game GUI are subject to change.

Mods can be sorted and filtered, they are grouped into categories.



You will be able to rate mods, probably using a 5-star scale and filter/sort mods by rating.





Every mod has a discussion with multiple categories - announcements, bug reports, etc. This should help with the clutter we currently have on the forums.





We will be requiring every mod to specify a license - either one of the common licenses (like MIT, (L)GPL, Apache, public domain) or a custom one, where you can specify the exact things people are and are not allowed to do with your content.



The in-game browser allows you to do most of the important things like filtering/searching for mods, it also allows you to install a mod with just a single click, same goes for updating mods that are already installed.



There are a lot of features that we want to still add to all this and they will be slowly appearing with 0.13.x patches. This is more a list of ideas, than a list of confirmed features, some of them might not be implemented.

• Automatic installation of mods when loading a modded save
• Automatic installation of mods when connecting to a modded multiplayer game
• Grouping mods into modpacks
• Integrating with Github for release management
• Automatic compatibility testing
• Various download/usage statistics

One of the first 0.14 projects is the attempt to fix the determinism problems of mods. The issue with mods and determinism is, that lua script as it is doesn't allow us to save everything from its internal state into the save file. When the modder puts pointer to method to a variable or uses variable that is not in the scope of the global, it is not saved. If the mod uses these values to do any changes to the game, it will desynchronize. This not only makes potential problem for modders, but drains our developement time, as we can't just ignore all the desync reports, but reading scripts of modders and searching for mistakes there is not really in our capabilities.

The plan is to enhance the script serialization in a way, that modder basically can't make a faulty mod, as all values will be always saved. This requires some low level hacking, so the lua functions, closures and other internal stuff is saved as a byte code as part of the script. But if it could be done, it would increase the usefulness of mods a lot. The research of whether this is possible will be one of the first task of our new Programmer in the team. Say hello to Honza :)

The train project is almost done as well, let me show you the side view of our new locomotive:



Once we were already working on the train graphics, we had to solve the annoying problem of train wheels not matching the rails in curves. This was obviously not solvable as we rendered the train wagons as one sprite. So we fixed it by drawing the wheels separately, so they can have different orientation than the locomotive itself. The result gives much more organic feeling of the locomotive movement.



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

Hello!

I guess that not so many people really expected that the target day of the 1st of June might be the actual release day. The day was mainly a psychological trick for us to finish all the little fixes and not to start any new projects, so we might be only week or two late instead of months. We started the first multiplayer play-tests last week, but they didn't last long. After the first hour of connection issue fixes, the game desynced every 15 seconds.

The process of determinism fixing that we first experienced when stabilizing 0.11 is now well known to us. With the tools we prepared and partially explained in friday facts 63, we were able to identify and fix determinism issues much much faster than before. It took just a few days compared to several months back then. The last playtest day was 2 days ago, and we were able to play a game where Linux, Mac and Windows players were all present. It lasted a few hours and no major issues were found so we are getting there.

I also have to admit, that the discovery of http://slither.io stole approximately 2 days of our dev time, as the game is really really great :) So if you can't wait for Factorio release, I advice you to try the game in the meantime.

TL;DR
If the further playtesting goes well, the release could happen next week, but you never know.

The information about the mod portal is brought to you by Martin, the train guy and recently also the mod portal guy.

The mod portal is a long awaited feature and it is finally happening! With the release of 0.13, we will be launching the mod portal website, along with an in-game integration. The base of the project was created by the original creator of factoriomods.com. The mod portal can be viewed by anyone, but you will have to log in with your factorio account to download mods, same goes for the in-game version.


Mostly due to lack of time and the size of the project, it is not in a finished state (and will not be completely finished with the 0.13 release). It contains many bugs and it's missing a fair amount of features that will be coming with later updates. All the graphics of the website or the in-game GUI are subject to change.

Mods can be sorted and filtered, they are grouped into categories.



You will be able to rate mods, probably using a 5-star scale and filter/sort mods by rating.





Every mod has a discussion with multiple categories - announcements, bug reports, etc. This should help with the clutter we currently have on the forums.





We will be requiring every mod to specify a license - either one of the common licenses (like MIT, (L)GPL, Apache, public domain) or a custom one, where you can specify the exact things people are and are not allowed to do with your content.



The in-game browser allows you to do most of the important things like filtering/searching for mods, it also allows you to install a mod with just a single click, same goes for updating mods that are already installed.



There are a lot of features that we want to still add to all this and they will be slowly appearing with 0.13.x patches. This is more a list of ideas, than a list of confirmed features, some of them might not be implemented.

• Automatic installation of mods when loading a modded save
• Automatic installation of mods when connecting to a modded multiplayer game
• Grouping mods into modpacks
• Integrating with Github for release management
• Automatic compatibility testing
• Various download/usage statistics

One of the first 0.14 projects is the attempt to fix the determinism problems of mods. The issue with mods and determinism is, that lua script as it is doesn't allow us to save everything from its internal state into the save file. When the modder puts pointer to method to a variable or uses variable that is not in the scope of the global, it is not saved. If the mod uses these values to do any changes to the game, it will desynchronize. This not only makes potential problem for modders, but drains our developement time, as we can't just ignore all the desync reports, but reading scripts of modders and searching for mistakes there is not really in our capabilities.

The plan is to enhance the script serialization in a way, that modder basically can't make a faulty mod, as all values will be always saved. This requires some low level hacking, so the lua functions, closures and other internal stuff is saved as a byte code as part of the script. But if it could be done, it would increase the usefulness of mods a lot. The research of whether this is possible will be one of the first task of our new Programmer in the team. Say hello to Honza :)

The train project is almost done as well, let me show you the side view of our new locomotive:



Once we were already working on the train graphics, we had to solve the annoying problem of train wheels not matching the rails in curves. This was obviously not solvable as we rendered the train wagons as one sprite. So we fixed it by drawing the wheels separately, so they can have different orientation than the locomotive itself. The result gives much more organic feeling of the locomotive movement.



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

Hello,
the struggle to finish the latest features and fixes so 0.13 can be in time, or just reasonable delayed, goes on. There is always last missing icon or tweak that was hiding around the corner. It is still not certain whether we can really deliver next week, but we will certainly try to.

We state it on our steam page, but people are still asking about it so I want to state it officially. We don't plan any Factorio sale. I'm aware, that the sale can make a lot of money in a short period of time, but I believe that it is not worth it in the long run, and since we are not in financial pressure we can afford to think in the long run. We don't like sales for the same reason we don't like the 9.99 prices. We want to be honest with our customers. When it costs 20, we don't want to make it feel like 10 and something. The same is with the sale, as you are basically saying, that someone who doesn't want to waste his time by searching for sales or special offers has to pay more.

Michal almost finished the overall flame related work. Part of it is, that the flame thrower uses the same logic as the flame turret. The whole fire mechanics consist of many factors. The flamethrower arc, flame on the ground, running biters/trees on fire, the smoke, burnt patches on ground, burnt trees etc. But from what I could try, the overall feeling of destruction was worth the trouble.

This is just a small example:


The circuit network additions were explained in the previous fff, but I wanted to show at least few useful examples of the new features in real Factories. I would like to note that I found and fixed several bugs by building just these examples :)

The typical problem is the supply train. In the later game, you have several mining expansions connected by rails. You would like to resupply these by different kind of materials, as the expansion might get under attack from time to time, and different kind of things might get destroyed. This was possible to do in 0.12, but you would have to have 1 chest + smart inserter per item type in every expansion to make it work. With the circuit network extension, there is now much more practical way to implement it.

The expansion:


The supply train can come in regular intervals. Its cargo wagon has one filter slot per item, so it will come with all different kind of items. The constant combinator specifies which items should be kept in the expansion, and how much. From these numbers I subtract the items I already have by multiplying them by -1. Then I simply set the filter inserter to the set the filters mode. It filter items by circuit network values greater than 0. So once there are 100 walls in the chest, the filter inserter will not move more. This means I can use this simplistic setup with one chest to supply everything the expansion needs.



Another example is the safe rail crossing. Here the player can't go in when the train has the rails reserved. When the player is on the rails, the signals are reserved by the circuit network, and the train has to wait until the player leaves. Also when the player is inside the area, the train gates are closed so he can't get on the tracks outside the crossing.


I didn't show actual train in both of these examples, as the train graphics is in the middle of rework, I will show more in the next FFF or the 0.13 release, it depends what will be sooner. All I can say now is, that there is little bit more than a new graphics and you will like it :)


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

Hello,
the struggle to finish the latest features and fixes so 0.13 can be in time, or just reasonable delayed, goes on. There is always last missing icon or tweak that was hiding around the corner. It is still not certain whether we can really deliver next week, but we will certainly try to.

We state it on our steam page, but people are still asking about it so I want to state it officially. We don't plan any Factorio sale. I'm aware, that the sale can make a lot of money in a short period of time, but I believe that it is not worth it in the long run, and since we are not in financial pressure we can afford to think in the long run. We don't like sales for the same reason we don't like the 9.99 prices. We want to be honest with our customers. When it costs 20, we don't want to make it feel like 10 and something. The same is with the sale, as you are basically saying, that someone who doesn't want to waste his time by searching for sales or special offers has to pay more.

Michal almost finished the overall flame related work. Part of it is, that the flame thrower uses the same logic as the flame turret. The whole fire mechanics consist of many factors. The flamethrower arc, flame on the ground, running biters/trees on fire, the smoke, burnt patches on ground, burnt trees etc. But from what I could try, the overall feeling of destruction was worth the trouble.

This is just a small example:


The circuit network additions were explained in the previous fff, but I wanted to show at least few useful examples of the new features in real Factories. I would like to note that I found and fixed several bugs by building just these examples :)

The typical problem is the supply train. In the later game, you have several mining expansions connected by rails. You would like to resupply these by different kind of materials, as the expansion might get under attack from time to time, and different kind of things might get destroyed. This was possible to do in 0.12, but you would have to have 1 chest + smart inserter per item type in every expansion to make it work. With the circuit network extension, there is now much more practical way to implement it.

The expansion:


The supply train can come in regular intervals. Its cargo wagon has one filter slot per item, so it will come with all different kind of items. The constant combinator specifies which items should be kept in the expansion, and how much. From these numbers I subtract the items I already have by multiplying them by -1. Then I simply set the filter inserter to the set the filters mode. It filter items by circuit network values greater than 0. So once there are 100 walls in the chest, the filter inserter will not move more. This means I can use this simplistic setup with one chest to supply everything the expansion needs.



Another example is the safe rail crossing. Here the player can't go in when the train has the rails reserved. When the player is on the rails, the signals are reserved by the circuit network, and the train has to wait until the player leaves. Also when the player is inside the area, the train gates are closed so he can't get on the tracks outside the crossing.


I didn't show actual train in both of these examples, as the train graphics is in the middle of rework, I will show more in the next FFF or the 0.13 release, it depends what will be sooner. All I can say now is, that there is little bit more than a new graphics and you will like it :)


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