While all us minions and assembling humans are furiously working on 0.15, today I would like to present to you what I have been working on lately - new graphics for resources, of course including high res and the new uranium ore. In the second part of the article I will get to an old/new topic about concrete.

For 0.15, we needed uranium ore, and eventually needed all the other resources in high resolution, so we took the opportunity to rework all of them now (not oil).

Most importantly, we introduce a new way of tiling - instead of a square, a resource tile is a puzzle-shaped thing. This helps to remove the top-down square nature of the old sprites, and make the ore patches much more organic.





Since the aim is to create multiple tilesets which work similarly, I tried to save a lot of time by making one master scene (I started with copper ore), from which it would be easy to derive the rest of the ores.



Of course the most basic way to do this would be to just recolour them in photoshop and call it a day (which would be pretty lame if you ask me), but if we are already redoing it, we might as well create a robust system which can actually change the 3D objects in a semi-automatic way.

Once again, I embraced the power of python and made a script which randomizes the selected objects. More specifically, it tweaks some displacement values, changes the mesh itself, and randomly rotates+scales it in the Z axis. The material itself has some further randomization inside for even more variety.



Making the first one took a while, most of the time I spent finetuning the amount of volumes in the density levels, and making sure they tile nicely together. After that work on the remaining ores was very fast.

Still working on the uranium though, it’s very different (we want it to be very different) so it takes a lot of figuring out how it should actually look like.

Please note that realism isn’t the aim of this, the main focus is to have something that intuitively looks like what it should, for example copper ore looks closer to copper plate than to real copper ore.



With this we are also currently tweaking the map generation, so that the ore patches look nicer. They will have the same amount of resources on average so it won’t really affect gameplay.


Quite some time ago we presented a new concrete tileset, way back before 0.13 was released. Although it’s much nicer than what we had previously, it introduced a new problem with the hazard concrete (concrete with stripes). You can see the problem on the left of the following picture.



Recently Posila spent just a few hours implementing a new lua value - transition_merges_with_tile = "concrete" - which just uses a continuous border between the two tile types instead of causing the ugly behaviour. It’s still not a perfect solution because the edge doesn’t know whether it should be hazard or normal concrete, so it just searches for its neighbours in a north-east-south-west cycle - so sometimes you can get a different tile than you might expect. We believe it’s much nicer than what we had so far, and in most cases it pretty much works.

One day we will have to rework the concrete to high-res anyway, so hopefully we will be able to figure out a better system by then. For now, you can look forward to it in 0.15.

As always, we can’t wait to read your reactions and feedback on our forums.

While all us minions and assembling humans are furiously working on 0.15, today I would like to present to you what I have been working on lately - new graphics for resources, of course including high res and the new uranium ore. In the second part of the article I will get to an old/new topic about concrete.

For 0.15, we needed uranium ore, and eventually needed all the other resources in high resolution, so we took the opportunity to rework all of them now (not oil).

Most importantly, we introduce a new way of tiling - instead of a square, a resource tile is a puzzle-shaped thing. This helps to remove the top-down square nature of the old sprites, and make the ore patches much more organic.





Since the aim is to create multiple tilesets which work similarly, I tried to save a lot of time by making one master scene (I started with copper ore), from which it would be easy to derive the rest of the ores.



Of course the most basic way to do this would be to just recolour them in photoshop and call it a day (which would be pretty lame if you ask me), but if we are already redoing it, we might as well create a robust system which can actually change the 3D objects in a semi-automatic way.

Once again, I embraced the power of python and made a script which randomizes the selected objects. More specifically, it tweaks some displacement values, changes the mesh itself, and randomly rotates+scales it in the Z axis. The material itself has some further randomization inside for even more variety.



Making the first one took a while, most of the time I spent finetuning the amount of volumes in the density levels, and making sure they tile nicely together. After that work on the remaining ores was very fast.

Still working on the uranium though, it’s very different (we want it to be very different) so it takes a lot of figuring out how it should actually look like.

Please note that realism isn’t the aim of this, the main focus is to have something that intuitively looks like what it should, for example copper ore looks closer to copper plate than to real copper ore.



With this we are also currently tweaking the map generation, so that the ore patches look nicer. They will have the same amount of resources on average so it won’t really affect gameplay.


Quite some time ago we presented a new concrete tileset, way back before 0.13 was released. Although it’s much nicer than what we had previously, it introduced a new problem with the hazard concrete (concrete with stripes). You can see the problem on the left of the following picture.



Recently Posila spent just a few hours implementing a new lua value - transition_merges_with_tile = "concrete" - which just uses a continuous border between the two tile types instead of causing the ugly behaviour. It’s still not a perfect solution because the edge doesn’t know whether it should be hazard or normal concrete, so it just searches for its neighbours in a north-east-south-west cycle - so sometimes you can get a different tile than you might expect. We believe it’s much nicer than what we had so far, and in most cases it pretty much works.

One day we will have to rework the concrete to high-res anyway, so hopefully we will be able to figure out a better system by then. For now, you can look forward to it in 0.15.

As always, we can’t wait to read your reactions and feedback on our forums.

Hello, the office has had a very lively atmosphere this week. With some very productive team discussions taking place, we reach another Friday with an optimistic outlook of the weeks to come.

There has for some time been an irritating problem which can arise in the game, specifically in the way we handle mods. With the mod portal's introduction, it became easier and more intuitive to download and install mods directly in the game. This has been really useful for a lot of players, simplifying the old system of manually dropping the mod into the correct file location.

However while installation was simple, getting rid of a malfunctioning mod was not addressed in any way. I am sure anyone who has spent some time downloading some more obscure mods has had this error thrown to them before:



Obviously the error is on behalf of the mod, and the course of action is to remove or disable the mod. I've had a lot of feedback over the course of 0.13 and 0.14, and to many users, this appears as simply a game crash. To put it in another way, a new player installs a mod, and it breaks their game. This shines especially poorly on us, as developers proud of supporting our modding community and its content, this looks like our support might not be good as we claim.

So the solution is what we call 'Minimal mode', essentially just a lightweight pre-load of the game, so that if there is an error on loading, we have some way to help. With this system in place, when you load a faulty mod, you will be greeted by something like this:



As you can see it will directly give the player the option to disable the mod, and allow them to load the game properly so they can delete it in the mod window. We hope this will all around reduce any frustrations which can occur with some mods, as well as reducing the number of emails we receive asking for help on the topic.

We mentioned a while ago about a plan for what we call 'Mini-tutorials'. The basic idea is these will be short context aware scenarios that the player will be prompted to try, which will teach the player some topic in a short period of time. For instance, when a player crafts his first rail pieces, he will be prompted to try the rail planner tutorial.

We have a short list of priority tutorials planned for 0.15, which is as follows:

• Trains
• Rail building & manual locomotive control
• Automated trains, train stops & schedules
• Ghost rail planning
• Basic signals & simple stations
• Advanced signals, chain signals & intersections
• Oil
• Pumpjacks, pipe building & fluid tanker usage
• Basic oil processing & dealing with output products
• Advanced oil processing & cracking

These are what we consider the major 'hiccups' in the game flow, and we hope be giving a short non-intrusive tutorial on how these systems work, it can help smooth out the sometimes intimidating complexity of the game. Further subjects we are considering include the following:

• Construction robots & Blueprints
• Logistic robots
• Nuclear power
• Circuit network
• Advanced belt usage
• Interface & Interactions

We are interested to hear all community input on this, are there any topics or specific areas of the game you think would benefit from a short tutorial? Let us know.

Related to these new mini-tutorials, is the status of the demo/tutorial campaign. When it was written (many years ago), it was designed specifically to act as both a playable campaign, as well as teaching the player the basics of the game. It works to serve its purpose by all means, but fails to teach the more advanced topics clearly enough while remaining fun to play.

The current plan is to streamline the current demo campaign, into more specifically a tutorial campaign, and then work on a new campaign with a greater focus on gameplay. Within the gameplay campaign we will have the mini-tutorials to explain the more advanced concepts, without worrying about specifically teaching the player in the mission.

Reddit user NiftyManiac has taken Factorio's concept of automation and ran away with it by developing what he calls 'GreyGoo Mk I':

https://youtu.be/xF--1XdcOeM

GreyGoo Mk I is a self-expanding factory built out of square cells. Its singular goal is to occupy as much space as possible, and it does this by autonomously traveling the landscape and seeking out ore to fuel its endless thirst for expansion. On one level, it's a way to automatically build mining outposts with no human intervention; on another level, it's the first step to a fully self-replicating factory.

You can read more about how it works here, and as always, let us know what you think on our forum.

Hello, the office has had a very lively atmosphere this week. With some very productive team discussions taking place, we reach another Friday with an optimistic outlook of the weeks to come.

There has for some time been an irritating problem which can arise in the game, specifically in the way we handle mods. With the mod portal's introduction, it became easier and more intuitive to download and install mods directly in the game. This has been really useful for a lot of players, simplifying the old system of manually dropping the mod into the correct file location.

However while installation was simple, getting rid of a malfunctioning mod was not addressed in any way. I am sure anyone who has spent some time downloading some more obscure mods has had this error thrown to them before:



Obviously the error is on behalf of the mod, and the course of action is to remove or disable the mod. I've had a lot of feedback over the course of 0.13 and 0.14, and to many users, this appears as simply a game crash. To put it in another way, a new player installs a mod, and it breaks their game. This shines especially poorly on us, as developers proud of supporting our modding community and its content, this looks like our support might not be good as we claim.

So the solution is what we call 'Minimal mode', essentially just a lightweight pre-load of the game, so that if there is an error on loading, we have some way to help. With this system in place, when you load a faulty mod, you will be greeted by something like this:



As you can see it will directly give the player the option to disable the mod, and allow them to load the game properly so they can delete it in the mod window. We hope this will all around reduce any frustrations which can occur with some mods, as well as reducing the number of emails we receive asking for help on the topic.

We mentioned a while ago about a plan for what we call 'Mini-tutorials'. The basic idea is these will be short context aware scenarios that the player will be prompted to try, which will teach the player some topic in a short period of time. For instance, when a player crafts his first rail pieces, he will be prompted to try the rail planner tutorial.

We have a short list of priority tutorials planned for 0.15, which is as follows:

• Trains
• Rail building & manual locomotive control
• Automated trains, train stops & schedules
• Ghost rail planning
• Basic signals & simple stations
• Advanced signals, chain signals & intersections
• Oil
• Pumpjacks, pipe building & fluid tanker usage
• Basic oil processing & dealing with output products
• Advanced oil processing & cracking

These are what we consider the major 'hiccups' in the game flow, and we hope be giving a short non-intrusive tutorial on how these systems work, it can help smooth out the sometimes intimidating complexity of the game. Further subjects we are considering include the following:

• Construction robots & Blueprints
• Logistic robots
• Nuclear power
• Circuit network
• Advanced belt usage
• Interface & Interactions

We are interested to hear all community input on this, are there any topics or specific areas of the game you think would benefit from a short tutorial? Let us know.

Related to these new mini-tutorials, is the status of the demo/tutorial campaign. When it was written (many years ago), it was designed specifically to act as both a playable campaign, as well as teaching the player the basics of the game. It works to serve its purpose by all means, but fails to teach the more advanced topics clearly enough while remaining fun to play.

The current plan is to streamline the current demo campaign, into more specifically a tutorial campaign, and then work on a new campaign with a greater focus on gameplay. Within the gameplay campaign we will have the mini-tutorials to explain the more advanced concepts, without worrying about specifically teaching the player in the mission.

Reddit user NiftyManiac has taken Factorio's concept of automation and ran away with it by developing what he calls 'GreyGoo Mk I':

https://youtu.be/xF--1XdcOeM

GreyGoo Mk I is a self-expanding factory built out of square cells. Its singular goal is to occupy as much space as possible, and it does this by autonomously traveling the landscape and seeking out ore to fuel its endless thirst for expansion. On one level, it's a way to automatically build mining outposts with no human intervention; on another level, it's the first step to a fully self-replicating factory.

You can read more about how it works here, and as always, let us know what you think on our forum.

Work has been going swiftly on 0.15, but there are still many major topics we have left to close. We mentioned previously that our estimate for release would be near the end of February, and while this has been our internal goal, we won't quite be able to make it.

One of the main reasons for this delay is us underestimating how long it would take to stabilize 0.14 and the new multiplayer code. We thought that because it was a relatively small 'major' release, that it would not take much time to make it stable. However the great community members playing the experimental version kept finding bugs for us to fix, and even now there are still several 0.14 bugs being identified and fixed in 0.15.

The extending bug fixing of 0.14 was no doubt necessary, but it has led us to be somewhat behind schedule on several features of 0.15. Our current optimistic estimate is that we will be able to release an experimental version of 0.15 at the end of March, and we will keep you all up to date on its progress.

I recently finished the backing logic changes to add the new 'advanced' section of the generate-map GUI. At the moment it includes settings to adjust pollution, evolution, biter expansion, and recipe/technology complexity. Pollution, evolution, and biter expansion have always been adjustable either through mods or console commands but recipe and technology complexity is something completely new.



The options include: simple, normal, and complex. At the moment the base game only has definitions for 'normal' but we may expand it.

The different options allow for 3 distinct technology or recipe trees. For instance complex could have technologies that don’t exist in simple/normal, with differing prerequisites and resource amounts. Another example could be a 'simple' gun turret recipe could just require iron plate and iron gear wheels. What I’m trying to say is: it’s not a simple "item craft time is twice as long" type system. The new settings are completely optional for mods so it has a no impact when not used.

One of the main motivations for adjustable recipe complexity, is allowing shorter game lengths for those who can't sink 3+ hours in a single session. Especially for any competitive multiplayer, reducing the time investment for some scenarios will help bring in more players.

While reading the forums recently I came across someone offering modding help that commented something along the lines of "don’t save a lot of game references because it’s really slow to load them". I quickly loaded up the game with the profiler attached and sure enough it sat for a few minutes loading a map that would normally take half a second to load.

Some digging later and I found the cause: a simple Lua function 'set meta table' that we used when restoring the saved Lua 'global' table had O(N) operation time depending on the amount of other tables you created before calling it. When we load the game we end up iterating the entire 'global' table in the opposite order they’re created which ends up being the worst possible scenario for performance. Some re-working of how the Lua function works internally and now it always runs in O(1) time at the cost of a tiny amount more RAM used.

The end result being: loading modded games should be faster in general and much faster if you’re using mods that save a lot of game references.

So let us know if you have any thoughts and opinions you'd like to share over on our forum.

Work has been going swiftly on 0.15, but there are still many major topics we have left to close. We mentioned previously that our estimate for release would be near the end of February, and while this has been our internal goal, we won't quite be able to make it.

One of the main reasons for this delay is us underestimating how long it would take to stabilize 0.14 and the new multiplayer code. We thought that because it was a relatively small 'major' release, that it would not take much time to make it stable. However the great community members playing the experimental version kept finding bugs for us to fix, and even now there are still several 0.14 bugs being identified and fixed in 0.15.

The extending bug fixing of 0.14 was no doubt necessary, but it has led us to be somewhat behind schedule on several features of 0.15. Our current optimistic estimate is that we will be able to release an experimental version of 0.15 at the end of March, and we will keep you all up to date on its progress.

I recently finished the backing logic changes to add the new 'advanced' section of the generate-map GUI. At the moment it includes settings to adjust pollution, evolution, biter expansion, and recipe/technology complexity. Pollution, evolution, and biter expansion have always been adjustable either through mods or console commands but recipe and technology complexity is something completely new.



The options include: simple, normal, and complex. At the moment the base game only has definitions for 'normal' but we may expand it.

The different options allow for 3 distinct technology or recipe trees. For instance complex could have technologies that don’t exist in simple/normal, with differing prerequisites and resource amounts. Another example could be a 'simple' gun turret recipe could just require iron plate and iron gear wheels. What I’m trying to say is: it’s not a simple "item craft time is twice as long" type system. The new settings are completely optional for mods so it has a no impact when not used.

One of the main motivations for adjustable recipe complexity, is allowing shorter game lengths for those who can't sink 3+ hours in a single session. Especially for any competitive multiplayer, reducing the time investment for some scenarios will help bring in more players.

While reading the forums recently I came across someone offering modding help that commented something along the lines of "don’t save a lot of game references because it’s really slow to load them". I quickly loaded up the game with the profiler attached and sure enough it sat for a few minutes loading a map that would normally take half a second to load.

Some digging later and I found the cause: a simple Lua function 'set meta table' that we used when restoring the saved Lua 'global' table had O(N) operation time depending on the amount of other tables you created before calling it. When we load the game we end up iterating the entire 'global' table in the opposite order they’re created which ends up being the worst possible scenario for performance. Some re-working of how the Lua function works internally and now it always runs in O(1) time at the cost of a tiny amount more RAM used.

The end result being: loading modded games should be faster in general and much faster if you’re using mods that save a lot of game references.

So let us know if you have any thoughts and opinions you'd like to share over on our forum.

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

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

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

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

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



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



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

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



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



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

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

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

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

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

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


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

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

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

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

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

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

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



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



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

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



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



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

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

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

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

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

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


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

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

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

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