• Underground pipes will no longer connect if there is candidate ghost underground pipe between them.
  
• Command line option --window-size can be also used to start the game in maximized mode when used as --window-size=maximized
  
• The library no longer shows unavailable blueprints of off-line players, since there is nothing that can be done with them.
  

• Fixed that the edit field of a blueprint book in the shared pane would get reset every time crafting finished. more
  
• Fixed that setting visibility to false on modded GUI elements while a text field had focus would keep blocking normal input. more
  
• Fixed a performance problem when having the blueprint library GUI open while robots add/remove large amounts of items from the character. more
  
• Fixed that walls and pipes built from blueprints could mark trees/rocks for deconstruction by mistake in some instances. more
  
• Fixed entities with force color (turrets, gates, ...) would be drawn black in blueprint preview.
  
• Fixed false positive in game state corruption detection logic. more
  
• Fixed pipette tool would pick diagonal rail with wrong direction. more
  
• Fixed migrating save from level 4 of New Hope campaign would disable Plane recipe. more
  
• Fixed that the blueprint library wouldn't close when Q is pressed and bound to the Close Window action. more
  
• Fixed that blueprints would stop transferring if the game was saved whilst some transfers were in progress and then reloaded from this save. more
  
• Fixed error with modal focus related to having blueprint error message and removed content message at the same time.
  
• Fixed server wouldn't close and delete a temporary save file made for a client that disconnected before the server finished saving. more
  
• Fixed that standing on belts facing each other between two chunks would cause the player actions to run at double speed.
  
• Fixed that in an artificial test-case, two blueprints couldn't in the library at the same time. more
  
• The Pipette tool will now copy the rotations of vehicles and trains. more
  
• Fixed that making blueprints of ghost tiles on top of real tiles would have seemingly "random" results in the blueprint. more
  
• Possible fix of the double "Communication with server failed" error. more
  
• Fixed entities to be built wouldn't get rendered in some places when hovering over transparent GUI elements in the map editor. more
  

• Added optional "render_not_in_network_icon" for logistic container prototypes defaulting to true.
  
• Fixed empty sprite path would cause game to crash instead of entering minimal mode. more

• Added LuaItemStack::swap_stack().
  
• Added on_player_removed event.
  

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

• Underground pipes will no longer connect if there is candidate ghost underground pipe between them.
  
• Command line option --window-size can be also used to start the game in maximized mode when used as --window-size=maximized
  
• The library no longer shows unavailable blueprints of off-line players, since there is nothing that can be done with them.
  

• Fixed that the edit field of a blueprint book in the shared pane would get reset every time crafting finished. more
  
• Fixed that setting visibility to false on modded GUI elements while a text field had focus would keep blocking normal input. more
  
• Fixed a performance problem when having the blueprint library GUI open while robots add/remove large amounts of items from the character. more
  
• Fixed that walls and pipes built from blueprints could mark trees/rocks for deconstruction by mistake in some instances. more
  
• Fixed entities with force color (turrets, gates, ...) would be drawn black in blueprint preview.
  
• Fixed false positive in game state corruption detection logic. more
  
• Fixed pipette tool would pick diagonal rail with wrong direction. more
  
• Fixed migrating save from level 4 of New Hope campaign would disable Plane recipe. more
  
• Fixed that the blueprint library wouldn't close when Q is pressed and bound to the Close Window action. more
  
• Fixed that blueprints would stop transferring if the game was saved whilst some transfers were in progress and then reloaded from this save. more
  
• Fixed error with modal focus related to having blueprint error message and removed content message at the same time.
  
• Fixed server wouldn't close and delete a temporary save file made for a client that disconnected before the server finished saving. more
  
• Fixed that standing on belts facing each other between two chunks would cause the player actions to run at double speed.
  
• Fixed that in an artificial test-case, two blueprints couldn't in the library at the same time. more
  
• The Pipette tool will now copy the rotations of vehicles and trains. more
  
• Fixed that making blueprints of ghost tiles on top of real tiles would have seemingly "random" results in the blueprint. more
  
• Possible fix of the double "Communication with server failed" error. more
  
• Fixed entities to be built wouldn't get rendered in some places when hovering over transparent GUI elements in the map editor. more
  

• Added optional "render_not_in_network_icon" for logistic container prototypes defaulting to true.
  
• Fixed empty sprite path would cause game to crash instead of entering minimal mode. more

• Added LuaItemStack::swap_stack().
  
• Added on_player_removed event.
  

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

Hello,

after weeks and weeks of going through bug reports and fixing stuff (after all 0.15 was one of our biggest releases), it seems that we are approaching the end of 0.15 stabilisation. The (wishful) plan is to have a stable candidate for 0.15 next week. Sadly, this will change our attention to just different category of bugs: Those that we plan to fix for the 0.16 as they are not so critical and the changes required to fix them are too big to be done in 0.15 at this point.

We had trouble with the blueprint library, mainly the blueprint duplication problems. Let me explain how it works internally. For performance reasons, the blueprint library generates and stores CRC of each blueprint. This can be used to quickly detect a duplicate blueprint when merging player blueprint libraries and blueprints stored in a save. For some reason, this wasn't working perfectly, as a lot of players were reporting that blueprints are somewhat being duplicated in the library. We assumed, that the error is in the CRC generation from the blueprint entities. That some property of an entity in the blueprint isn't initialized properly, so the CRC would be different for 2 blueprints that are the same. After some digging, we discovered what is wrong:


The way it works is, that the blueprint is saved as it would be normally saved, but instead the data goes into a CRC engine. The problem is, that our MapSerialiser writes current output map version automatically in a constructor. This means, that whenever we changed version of factorio, which is every release at least, the CRC values of the blueprints changed, and they were suddenly considered to be different. It was quite hard to reproduce because of this. Anyway, forcing the serialiser to not write the map version to the output in this case fixed this issue.

We were also wondering how big is the chance, that 2 blueprints in one blueprint library will have the same CRC. The CRC is 32 bit, so there are 2^32 combinations. If we take into account 1 million players, and assume that each of them is having 20 blueprints in their library and all of the blueprints are random, the chance that it happens at least once is 9%. (You can try to calculate it yourself if you like math). Lets wait if it happens or not :)

One of our plans for 0.16 is the optimisation of the internal ItemStack representation. The current data representation of an item stack is like this.



The Item needs to be a pointer as different kind of items have different properties and can hold different kind of data:



This representation is nice and simple, but performance wise, it is bad, as whenever the ItemStack is accessed, it needs to access different part of memory to know the ID or any other information about the item as it is in the dynamically allocated part. When the item is transferred from one place to another, the dynamically allocated pointer can be transferred as well, but in cases when the stack needs to be split (which is happening almost always with stack inserter for example), a new copy of the dynamically allocated class Item needs to be created, which is generally slow as well.

To solve this, we can take into account the fact that vast majority of items in the factory are simple items (ore, plates etc.). We will simply just store the basic item data directly in the ItemStack, so it looks like this:


Now, in the vast majority of cases, the ItemStack is simple and flat, so any operation with it will be much faster. It is possible that this change might improve the performance, but until we actually implement it and test it, we will never know.

While testing our tutorial sample, which focuses mainly on rails and signals, people discovered that we have a debug visualisation called "show-rail-blocks", which looks like this when active:



The people were commenting, that once they used that, they were able to understand the way signals work almost instantly. The problem is, that debug options are generally not intended to be used in normal game, as the way these are generated is slowing the render a lot and the looks of it is far from production quality.

But it gave us an idea, that we should probably provide this visualisation in game properly. We are experimenting with the way it should look, but it might be something conceptually similar to this:



The first problem is, that using colors is very practical way to indicate which rails are connected into one segment, but it also makes the game look too much like a circus. We shall see what can we do if we use different than the RGB colors for it.

Another problem is the question, when exactly should it be shown, our first guess is to show it whenever building rails or rail signals, but the problem is, that the amount of indications you see when building rail signals is starting to be quite too high:

• The new rail segment
  
• Possible signal positions
  
• Positions of train vehicles
  
• Direction of the train that will approach the signal
  
• Count of signals in the cursor
  
• The cursor to be built

Which results in a bit of a messy composition:



So the final result is subject to our experiments, I just wanted to show you the process.

As always, let us know if you have any thoughts or feedback on our Forum.

Hello,

after weeks and weeks of going through bug reports and fixing stuff (after all 0.15 was one of our biggest releases), it seems that we are approaching the end of 0.15 stabilisation. The (wishful) plan is to have a stable candidate for 0.15 next week. Sadly, this will change our attention to just different category of bugs: Those that we plan to fix for the 0.16 as they are not so critical and the changes required to fix them are too big to be done in 0.15 at this point.

We had trouble with the blueprint library, mainly the blueprint duplication problems. Let me explain how it works internally. For performance reasons, the blueprint library generates and stores CRC of each blueprint. This can be used to quickly detect a duplicate blueprint when merging player blueprint libraries and blueprints stored in a save. For some reason, this wasn't working perfectly, as a lot of players were reporting that blueprints are somewhat being duplicated in the library. We assumed, that the error is in the CRC generation from the blueprint entities. That some property of an entity in the blueprint isn't initialized properly, so the CRC would be different for 2 blueprints that are the same. After some digging, we discovered what is wrong:


The way it works is, that the blueprint is saved as it would be normally saved, but instead the data goes into a CRC engine. The problem is, that our MapSerialiser writes current output map version automatically in a constructor. This means, that whenever we changed version of factorio, which is every release at least, the CRC values of the blueprints changed, and they were suddenly considered to be different. It was quite hard to reproduce because of this. Anyway, forcing the serialiser to not write the map version to the output in this case fixed this issue.

We were also wondering how big is the chance, that 2 blueprints in one blueprint library will have the same CRC. The CRC is 32 bit, so there are 2^32 combinations. If we take into account 1 million players, and assume that each of them is having 20 blueprints in their library and all of the blueprints are random, the chance that it happens at least once is 9%. (You can try to calculate it yourself if you like math). Lets wait if it happens or not :)

One of our plans for 0.16 is the optimisation of the internal ItemStack representation. The current data representation of an item stack is like this.



The Item needs to be a pointer as different kind of items have different properties and can hold different kind of data:



This representation is nice and simple, but performance wise, it is bad, as whenever the ItemStack is accessed, it needs to access different part of memory to know the ID or any other information about the item as it is in the dynamically allocated part. When the item is transferred from one place to another, the dynamically allocated pointer can be transferred as well, but in cases when the stack needs to be split (which is happening almost always with stack inserter for example), a new copy of the dynamically allocated class Item needs to be created, which is generally slow as well.

To solve this, we can take into account the fact that vast majority of items in the factory are simple items (ore, plates etc.). We will simply just store the basic item data directly in the ItemStack, so it looks like this:


Now, in the vast majority of cases, the ItemStack is simple and flat, so any operation with it will be much faster. It is possible that this change might improve the performance, but until we actually implement it and test it, we will never know.

While testing our tutorial sample, which focuses mainly on rails and signals, people discovered that we have a debug visualisation called "show-rail-blocks", which looks like this when active:



The people were commenting, that once they used that, they were able to understand the way signals work almost instantly. The problem is, that debug options are generally not intended to be used in normal game, as the way these are generated is slowing the render a lot and the looks of it is far from production quality.

But it gave us an idea, that we should probably provide this visualisation in game properly. We are experimenting with the way it should look, but it might be something conceptually similar to this:



The first problem is, that using colors is very practical way to indicate which rails are connected into one segment, but it also makes the game look too much like a circus. We shall see what can we do if we use different than the RGB colors for it.

Another problem is the question, when exactly should it be shown, our first guess is to show it whenever building rails or rail signals, but the problem is, that the amount of indications you see when building rail signals is starting to be quite too high:

• The new rail segment
  
• Possible signal positions
  
• Positions of train vehicles
  
• Direction of the train that will approach the signal
  
• Count of signals in the cursor
  
• The cursor to be built

Which results in a bit of a messy composition:



So the final result is subject to our experiments, I just wanted to show you the process.

As always, let us know if you have any thoughts or feedback on our Forum.

• Reduced time needed for an unit of Automation 2 research from 15 to 5 seconds to compensate for previous change of science packs requirements.
  

• Added --window-size launch option. For example --window-size=1680x1050 more
  
• Damaging a tree with impact or physical damage generates some leaves.
  
• Warning icon for logistic chests that are not in a reach of roboport.
  
• Train stop names are rendered at 45 degrees to better show names.
  

• Fixed that ghosts would stay over entities after deconstruction was canceled. more
  
• Fixed that the controls menu wouldn't use a fixed common width between controls sections.
  
• Inserter researches now require equal ratios of science pack types.
  
• Fixed that transferring blueprints from the library could make the headless server crash. more
  
• Fixed that blueprints could be duplicated when moving to a new version. more
  
• Fixed progress bar not showing in the entity info panel if the text was too long. more
  
• Fixed (at least one of the cases) of crashes related to not being able to connect to auth server while joining game. more
  
• Fixed, possible crash related to changed bounding box of entity by a mod. When the mod is removed (added) the corner of the entity can occupy chunk that doesn't exist yet which would cause a loading error. more
  
• Fixed that mining sounds and the leaves effect weren't present when mining tree from a car. more
  
• Fixed possible crash when removing modded rails during save migration. more
  

• Mod hotkeys are arranged per-mod.
  
• Disallowed defining different rail categories for this moment as having more than one will never work properly until we spent some non-trivial time with that, which is not a priority now.
  

• Fixed that item-with-inventory filters wouldn't be preserved when cloned through the Lua API. more
  

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

• Reduced time needed for an unit of Automation 2 research from 15 to 5 seconds to compensate for previous change of science packs requirements.
  

• Added --window-size launch option. For example --window-size=1680x1050 more
  
• Damaging a tree with impact or physical damage generates some leaves.
  
• Warning icon for logistic chests that are not in a reach of roboport.
  
• Train stop names are rendered at 45 degrees to better show names.
  

• Fixed that ghosts would stay over entities after deconstruction was canceled. more
  
• Fixed that the controls menu wouldn't use a fixed common width between controls sections.
  
• Inserter researches now require equal ratios of science pack types.
  
• Fixed that transferring blueprints from the library could make the headless server crash. more
  
• Fixed that blueprints could be duplicated when moving to a new version. more
  
• Fixed progress bar not showing in the entity info panel if the text was too long. more
  
• Fixed (at least one of the cases) of crashes related to not being able to connect to auth server while joining game. more
  
• Fixed, possible crash related to changed bounding box of entity by a mod. When the mod is removed (added) the corner of the entity can occupy chunk that doesn't exist yet which would cause a loading error. more
  
• Fixed that mining sounds and the leaves effect weren't present when mining tree from a car. more
  
• Fixed possible crash when removing modded rails during save migration. more
  

• Mod hotkeys are arranged per-mod.
  
• Disallowed defining different rail categories for this moment as having more than one will never work properly until we spent some non-trivial time with that, which is not a priority now.
  

• Fixed that item-with-inventory filters wouldn't be preserved when cloned through the Lua API. more
  

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

• Speed and efficiency module 3 technology now requires high tech science packs instead of production science packs, so that working towards power armor mk2 does not require production science packs. This makes the branching between high tech and production science packs more meaningful.
  
• All researches now require equal ratios of science pack types. This reduces the cost of some researches.
  

• Fixed manually inserting items into the blueprint book would disconnect you in multiplayer. more
  
• Fixed a crash when clicking an alert the same tick the game is loaded. more
  
• Fixed a crash when saving screenshot failed. more
  
• Fixed that trains could stop in the middle of chain signal blocks in some specific setups causing deadlocks. more
  
• Fixed that large drop-down widgets would render off the bottom of the screen in some cases. more
  

• Added "render_layer" property to car prototype definition.
  

• Fixed that calling LuaForce::chart(...) would try to chart chunks outside the map limits. more
  
• Fixed that LuaPlayer::unlock_achievement() would keep showing the notification after the achievement was unlocked. more
  
• Fixed that LuaItemStack::create_blueprint didn't behave the same way as normal blueprint creation in regards to ghost tiles. more
  
• Fixed that LuaEntity::selected_gun_index write was 0-based. more
  
• Fixed that mods could do remote calls outside of events when the game isn't in a valid state. more
  
• Fixed that a time_before_removed of 0 on a corpse entity could crash the game in some instances. more
  

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

• Speed and efficiency module 3 technology now requires high tech science packs instead of production science packs, so that working towards power armor mk2 does not require production science packs. This makes the branching between high tech and production science packs more meaningful.
  
• All researches now require equal ratios of science pack types. This reduces the cost of some researches.
  

• Fixed manually inserting items into the blueprint book would disconnect you in multiplayer. more
  
• Fixed a crash when clicking an alert the same tick the game is loaded. more
  
• Fixed a crash when saving screenshot failed. more
  
• Fixed that trains could stop in the middle of chain signal blocks in some specific setups causing deadlocks. more
  
• Fixed that large drop-down widgets would render off the bottom of the screen in some cases. more
  

• Added "render_layer" property to car prototype definition.
  

• Fixed that calling LuaForce::chart(...) would try to chart chunks outside the map limits. more
  
• Fixed that LuaPlayer::unlock_achievement() would keep showing the notification after the achievement was unlocked. more
  
• Fixed that LuaItemStack::create_blueprint didn't behave the same way as normal blueprint creation in regards to ghost tiles. more
  
• Fixed that LuaEntity::selected_gun_index write was 0-based. more
  
• Fixed that mods could do remote calls outside of events when the game isn't in a valid state. more
  
• Fixed that a time_before_removed of 0 on a corpse entity could crash the game in some instances. more
  

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

Hello, not much at all has happened this week. It has been rather quiet with the Art department out of office the last few days. However there has been some additional success on our recruitment drive, so there will be an additional 3-4 bodies (live) in the office within the next month.

I was surprised this week when I saw on our forum that we are down to only a single page on our bug forum. Of course this is only half the story, as we still have whole other page in 'Assigned', as well as many which may be moved from pending - but at last it is feeling under control. We hoped that the release on Thursday would be our stable candidate, but due to some introduced bugs, we have had to do some additional releases.

When development on Factorio started, a lot of thought went into the design and implementation of the entities, prototypes, and other key elements of the game. Always the GUI code was written with "Its just GUI, it is not so hard..." as the mindset. The following picture has been generated by doxygen, which shows all the class inheritance of the GUI code.



As you see, over the time it has grown to be quite a large and complex area of the project. For our next development, we would definitely like to take more time in the beginning to think about our GUI system. Recently there has been more discussion in the office about the GUI, and the problems inherent with it. For 0.16 Twinsen has assigned himself a lot of these 'Fix the GUI' tasks, so no doubt there will be some interesting FFF material from him coming soon.

A while ago there was quite some craze about 'Micro-factories' by players, to fit some production setup in as small an area as possible. The bar has been set very high by this recent creation by Dave McW. By using the Recursive blueprints mod, he has managed to program a complete science production facility in only a 9x14 area.

https://youtu.be/U-qs_Kscrfw

So if you have any comments or feedback for us, please let us know over on our forum.

Hello, not much at all has happened this week. It has been rather quiet with the Art department out of office the last few days. However there has been some additional success on our recruitment drive, so there will be an additional 3-4 bodies (live) in the office within the next month.

I was surprised this week when I saw on our forum that we are down to only a single page on our bug forum. Of course this is only half the story, as we still have whole other page in 'Assigned', as well as many which may be moved from pending - but at last it is feeling under control. We hoped that the release on Thursday would be our stable candidate, but due to some introduced bugs, we have had to do some additional releases.

When development on Factorio started, a lot of thought went into the design and implementation of the entities, prototypes, and other key elements of the game. Always the GUI code was written with "Its just GUI, it is not so hard..." as the mindset. The following picture has been generated by doxygen, which shows all the class inheritance of the GUI code.



As you see, over the time it has grown to be quite a large and complex area of the project. For our next development, we would definitely like to take more time in the beginning to think about our GUI system. Recently there has been more discussion in the office about the GUI, and the problems inherent with it. For 0.16 Twinsen has assigned himself a lot of these 'Fix the GUI' tasks, so no doubt there will be some interesting FFF material from him coming soon.

A while ago there was quite some craze about 'Micro-factories' by players, to fit some production setup in as small an area as possible. The bar has been set very high by this recent creation by Dave McW. By using the Recursive blueprints mod, he has managed to program a complete science production facility in only a 9x14 area.

https://youtu.be/U-qs_Kscrfw

So if you have any comments or feedback for us, please let us know over on our forum.