The previous FFF seems to have caused quite a reaction. We had many discussions in the office regarding this topic, so this week some of us prepared some detailed responses.

I started the article from last week saying this was mostly of a rant, so just the opinions of a player who prefers belts over bots. There was no real conclusion other than "What changes, if any, could we do to make everything more fun?".

Then I decided to make the writing more dramatic by making it look as if we plan to remove bots from the game. My intention was to create an emotional roller-coaster in order to make the FFF a more interesting read. Combined with the context of the recent nerfs, some people got very angry very fast. "Remove bots from the game" was nothing more than a thought experiment, not a proposition. Unfortunately that didn't work out as intended.

This has taught me some valuable lessons in writing, including that I should not play with people's emotions, at least not the way I did.

The reactions were very strong, from long analytical posts, to heated but deep discussions, to personal attacks towards me. Not to mention the 46 forum pages that make that FFF the one with the most forum replies by far. It's clear that there's a strong emotional attachment to bots that plays an important role.

But I would like to add that it's our jobs as game developers to make sure that the most optimal way of play is also the most fun way of play (ref1, ref2). What is most fun is of course an subjective and extremely complex topic that dives deep into game design, human psychology and player motivation.

The reasoning behind the why we wanted to do some minor nerfs to bots, was actually to promote player choice. Many players argued that choice matters and we should leave bots alone. If choice matters, then the player should be able to chose between belts and bots. Is this much of a choice if you just look at the numbers and want to play optimally? Bots are easier to use, offer more throughput, they are inherently balanced, are way more flexible, easy to expand, and use less UPS. So by looking at the facts, bots are superior in every way, and they are the only choice if you want to play optimally.

The reason people will ever chose belts is because they want to go for the fun option (in their opinion) not the optimal option. The idea was to level this a bit so players who want to play optimally can choose to play using belts without feeling like they made the wrong choice. Buffing belts is not something easy to do any more since we have always done it over the years (fixing belt corners decompressing the belt, making the distance between items smaller, etc), so we were looking at bot nerfs.

There will probably be no nerfs coming to bots since it's hard to nerf something players are so attached to. Seeing your factory produce much less won't be seen well no matter how good the reasoning behind the change is. It could also be argued that the reason why bots are fun is because they are overpowered and they offer a massive progression to your factory, maybe what some people see as game-breaking is simply game-changing.

Kovarex will go into more detail with his thoughts on this...

I agree with everything Twinsen said.
I would like to liken bots to the Death Spell in Baldur's gate (one of my favorite games of all time).



In Baldur's gate, you start at level 1 and you are very weak. Almost every monster is a challenge and a threat to kill you. But as you gain experience and level up, you get stronger and if you are a wizard, you also get stronger spells. At level 12, you get one of my favourite spells called Death spell. It instantly sucks the life out of all low/middle level monsters within a certain radius. When acquired, it gives you feeling of being very powerful, as instead of having to fiddle with the enemies one by one, you just end the battle instantly. It is one of the things you look forward when you start the game and gives you great feeling of improvement.

This is very similar to how bots work. Once you get them, they give you the same 2 similar things. First is the power, as they just provide stronger logistics. The second is that they free you from having to fiddle with every little logistic detail and let you think more in the bigger scale. The big difference between Bots and the Death spell is, that in Baldur's gate, Death spell only works on the low/middle level monsters, so as you progress through the game, there will be less and less enemies who are affected by it. It is still useful to clean out the weaker part of the enemy group, so you don't waste time with the small things, and you can concentrate on the stronger ones. The game would certainly be very bad, if the Death spell would be ultimate way to kill anyone anytime, as at the point of getting it, all the other spells and things would be borderline useless.

You probably understand where am I getting to. Yes, we kind of managed, to make long distance transport to be more suited for trains, but other than that, bots are the one solution for everything. With bots, there is no reason to think about other types of transport (Cable cars or automated vehicles for example), because why would anyone use it when you have bots? It is kind of fun getting to the bots setup, and moving to the bot-only factory, but once it is achieved, the continued play feels very dull for me, because I know that this is it: There are very few improvements I can do to the system, and extending the factory is just about plopping more assembler/requester/provider cells without any thought. Also, with bots in the game, making extensions to Factorio feels useless. For example, the extension where you would expand to other planets, start there over, and once you achieve the rocket there, you would combine the production of the two planets somehow. But if starting on another planet just means playing with robots from the start, which means plopping a few cells of what you need and making a few mines, I don't see the point.

The question is, how to approach this problem? As Twinsen said, making belts stronger would not only be a compromise in some way and it would also reduce the amount of moving things, which is the proper metric in my eyes. When you see a huge factory, it is cool, because there are 16 blue iron belts being filled, not because the output is X per minute.

To be able to compare numbers, I made test setup. I created 4 fully compressed express belts and put them against a fully satisfied lane of roboports (also 4 tiles wide). To be able to measure the throughput easily, I just modded the furnaces to be very fast and smelted the result, iron for belts and copper for robots. This is the setup where belts are as strong as they can possibly be are in the bots versus belts balance. In majority cases, bots are going to be relatively much stronger compared to belts.



The result is, that bots did 16.4k per minute while belts only 9.6.



With worker robot speed research, it approaches the maximum around 19.5k per minute.

With this in mind, we can safely say, that robots are at least 2 times stronger then express belts, but in real factories, it is much more as belts need lot of other parts and are rarely used as ideally as robots would be, so my private guess would be that robots are currently around 5+ times stronger compared to belts.

In the last half year or more I have been putting together a lot of ideas around the concept of increasing the throughput of belts, and the last FFF and the resulting discussions made me focus on this topic heavily this last week. There are various options we looked into, some of them we even tried to prototype and played with them for a bit. I'll briefly try to describe some of them:
Packed items like pallets/containers

• Just adds another thing to do for every single recipe, mostly just adding tediousness. Basically mandatory barrels if you wanted to increase throughput.
• More tediousness means robots are an even better option; even if robots couldn't carry these heavy items, you could still use them for the unpacked item distribution. What would probably end up happening is that you would feed the stacked items from trains directly to unpacking assembling machines which would output to provider chests for robots.

Adding a new tier of super-fast belt or belt speed research

• Inserters would either need a speed increase as well, or would stop being able to take from the belt until the belt backs up. Increasing speed of inserters also increases the speed between containers, which would have an even bigger impact on robots.
• It would get ridiculously fast if you wanted to make a substantial increase (say, 3 times more speed).
• We already have 3 levels of belts and adding a speed research is just another number increasing research without unlocking a new entity.

New 1x1 Belt Stacker entity as the way how to make the stacks

• Gives the ability to make high throughput belt at the price of extra complexity.
• If the 1x1 entity is a chest-like loader which outputs on one side, it actually gets so hard that it reduces the amount of designs you can do with a fully beaconed setup to something like one or two obscure layouts which can't even output both compressed lanes of a fully stacked belt, making it even less interesting.
• If the 1x1 entity is a belt piece which lets items pass through and from the top new stacks can be added, it's just a belt piece which you have to build everywhere and you still can't use it to unload inserters directly into splitters/underground belts. At that point you might as well have inserters get this ability instead.
• You would have to adapt/rebuild all of your layouts, which in the late game is just not that appealing, if you can rip up your whole base to use robots.

New Belt Buffer entity like Klonan's mod

• Simplifies too many things and makes pretty much all designs obsolete except the simplest one.
• Doesn't actually increase belt throughput, just helps belt loading/unloading.

Research to have each N-th item be able to stack on the belt.

• Pretty much the same as belt speed research.
• Stack belt implementation would not be easy, especially visually.
• Having only every N-th item stack up and not all of them, would look really strange.

New tier of belt which would be able to stack items.

• You just have to produce and replace a new tier of belts.
• If only the stack belt is allowed to have stacks, then whenever items move to a single tile of a normal belt, all of the items would un-stack, which woulbe be quite annoying.
• If the stacks could only be created on the stack belt, but stay stacked on the normal belts, you would just build your insertion points, splitters and UG belts with the stack belt tier.
• Both of the previous points might not be the worst thing but it would be quite weird and would motivate you to just get rid of all normal belts ASAP.
• If only inserters would be able to create the stacks, it would get really annoying to attempt making a fully compressed, fully stacked belt even if inserters auto-compressed the belt.

Technology which would turn all belts into stack belts.

• You would research this and automagically all inserters, splitters and side-loading (also mining drills) would be able to make stacks on any type of the 3 belt tiers we have now.
• You don't get any new entity, but you get the choice between upgrading all of your belts with this technology and not having to do any extra work, or tearing up your base and replacing with robots.
• When you get the research, all of your belts would start buffering extra items, which some people might find annoying.
• If we could code this and find a visual solution which wouldn't take too much work, I would prefer this option.

All in all, the general issue of all of the belt throughput increases is the question if it wouldn't reduce the amount of belts that a newer player uses in their play through, reducing the complexity and interesting part of the game. I believe if this kind of research would happen after the rocket launch this would not be that much of a problem, especially since with robots you can reduce the amount of belts and complexity related to them to zero even earlier in the game.

The visual solution for the stack belt we intended would be items stacked on top of each other, which would be really hard to do as many of the item icons would have to be rethought. Keeping in mind that we have hundreds of item icons, this could be really dangerous, hard and time consuming to do. It's worth mentioning that with a stacked belt it would likely be less visually clear if your belt is fully stacked and compressed.

The coding solution of the stack belt including all of the item stacking in splitters, miners and side-loading might not be that easy either.

I think there is a bunch of issues that belt throughput increase would address, like:

• The "production numbers" reward for time spent when setting up robots is clearly bigger than for time spent building belts.
• Belts can't really keep up with heavily boosted setups by beacons.
• The last belt technology is relatively early in the game, so when you just look at the tech tree, you immediately know that robots are supposed to be the next step.
• The highest producing base possible to build at 60UPS is strictly robot based.

I had a look at various megabases, and I was actually quite surprised how far you can get with belts if you really try to be efficient. Of course not all of the UPS is tied to just belts, in fact the usual entity update consumes a greater portion now, but increasing the belt throughput 3 times seems like it would at least make belts competitive. However this is pure guesswork from seeing some big bases and reading their update times, and having some feel from using belts myself. If you are interested, you can send me your belt megabases that push the game to the limit, possibly with modded 3 times faster belts and inserters.

In general being able to see belt megabases to me is something really substantial. If a new player looks at a random Twitch stream, Youtube video, or Imgur album of a megabase, everything he sees now is a train network connecting a bunch of segregated robot production cells, which is visually repetitive, and compared to belt bases, visually less interesting. Being able to see belt bases in this top tier would be something that a new player could aspire to do one day and be inspired by. That would be the result of what Twinsen says about having the most interesting way to play being the most effective way to play.[/list]
As you can see each of the solutions has at least one serious problem, and it addresses a specific issue that you only really face after hundreds of hours in the game. It is probably better to leave this issue as it is so that we don't break the existing game. It might be better to focus on making belts more convenient to use instead of brute forcing the problem with throughput increases - especially as it's quite easy to address the speed changes in a mod which will just work together with the convenience improvements.

We decided that we won't make stronger version of belts for now, but we could still improve the usability of belts. I tried to make some interesting setups with belts and sushi setups, but I feel, that the belt filtering with filter inserters is very clunky when it is supposed to be reliable and have large throughput.

This is why we decided to add a few options to splitter configuration. These might be perceived overpowered by some, but we believe, that these mainly solve problems in the later part of the game when belts compete with bots, and when the player needs more control over the belt logistics.



Let me sum it one by one:

• Input priority - Specifies whether the left or right input should be always used first. The typical example where it might be useful is the case of "this mine should be depleted first, so lets prioritize ore coming from it".
• Output priority - This was often simulated using the circuit network, but it was not always 100% reliable, and when it was, the configuration was kind of clunky. Having priority is something simple that people can use very often, so we believe that it should be simple to achieve.
• Output filter - The strongest feature provided. It allows one item to be filtered to go to either left or right, while everything else goes to the other side. It might be argued, that this is what filter inserters are for. The problem with filter inserters is that you need several of them to make it work reliably, and the setup breaks when you run out of power for a small while as inserters would stop but not the belts. The setup can be made in a way that it doesn't break even in this case, but it makes it even more awkward. With the splitter filter, we have an easy way to reliably specify that an item that goes to the side and never gets to the other.

Here are few examples of what the splitter configuration can do:


The splitter additions will come with the next 0.16 release.

The conclusion is, that I strongly believe that bots should have a debuff. They should still be a big and powerful advancement when they are researched, but they should work more like the death spell. It should solve the little stuff that isn't that powerful (in Factorio, it is equal to smaller production). I even believe that robot-only Factory should be possible and not useless, I just don't believe, that they should be 5+ times stronger than anything else.

Players would still be able to build robot only factory, belt only factory or combination of those, but the strongest strategy would be to combine all types of transport, each for the part where they are the strongest. My suggestion would be to either completely remove the Worker robot cargo size research, or more likely, to multiply the charging time several times. For factory transport, both would have the same effect, but the latter wouldn't hurt personal transportation that much, as robots would transport all the missing items to player before they would need to be recharged, and then they would recharge when the player is already supplied and doing something else.

As always, leave us your thoughts and comments on our forum.

The previous FFF seems to have caused quite a reaction. We had many discussions in the office regarding this topic, so this week some of us prepared some detailed responses.

I started the article from last week saying this was mostly of a rant, so just the opinions of a player who prefers belts over bots. There was no real conclusion other than "What changes, if any, could we do to make everything more fun?".

Then I decided to make the writing more dramatic by making it look as if we plan to remove bots from the game. My intention was to create an emotional roller-coaster in order to make the FFF a more interesting read. Combined with the context of the recent nerfs, some people got very angry very fast. "Remove bots from the game" was nothing more than a thought experiment, not a proposition. Unfortunately that didn't work out as intended.

This has taught me some valuable lessons in writing, including that I should not play with people's emotions, at least not the way I did.

The reactions were very strong, from long analytical posts, to heated but deep discussions, to personal attacks towards me. Not to mention the 46 forum pages that make that FFF the one with the most forum replies by far. It's clear that there's a strong emotional attachment to bots that plays an important role.

But I would like to add that it's our jobs as game developers to make sure that the most optimal way of play is also the most fun way of play (ref1, ref2). What is most fun is of course an subjective and extremely complex topic that dives deep into game design, human psychology and player motivation.

The reasoning behind the why we wanted to do some minor nerfs to bots, was actually to promote player choice. Many players argued that choice matters and we should leave bots alone. If choice matters, then the player should be able to chose between belts and bots. Is this much of a choice if you just look at the numbers and want to play optimally? Bots are easier to use, offer more throughput, they are inherently balanced, are way more flexible, easy to expand, and use less UPS. So by looking at the facts, bots are superior in every way, and they are the only choice if you want to play optimally.

The reason people will ever chose belts is because they want to go for the fun option (in their opinion) not the optimal option. The idea was to level this a bit so players who want to play optimally can choose to play using belts without feeling like they made the wrong choice. Buffing belts is not something easy to do any more since we have always done it over the years (fixing belt corners decompressing the belt, making the distance between items smaller, etc), so we were looking at bot nerfs.

There will probably be no nerfs coming to bots since it's hard to nerf something players are so attached to. Seeing your factory produce much less won't be seen well no matter how good the reasoning behind the change is. It could also be argued that the reason why bots are fun is because they are overpowered and they offer a massive progression to your factory, maybe what some people see as game-breaking is simply game-changing.

Kovarex will go into more detail with his thoughts on this...

I agree with everything Twinsen said.
I would like to liken bots to the Death Spell in Baldur's gate (one of my favorite games of all time).



In Baldur's gate, you start at level 1 and you are very weak. Almost every monster is a challenge and a threat to kill you. But as you gain experience and level up, you get stronger and if you are a wizard, you also get stronger spells. At level 12, you get one of my favourite spells called Death spell. It instantly sucks the life out of all low/middle level monsters within a certain radius. When acquired, it gives you feeling of being very powerful, as instead of having to fiddle with the enemies one by one, you just end the battle instantly. It is one of the things you look forward when you start the game and gives you great feeling of improvement.

This is very similar to how bots work. Once you get them, they give you the same 2 similar things. First is the power, as they just provide stronger logistics. The second is that they free you from having to fiddle with every little logistic detail and let you think more in the bigger scale. The big difference between Bots and the Death spell is, that in Baldur's gate, Death spell only works on the low/middle level monsters, so as you progress through the game, there will be less and less enemies who are affected by it. It is still useful to clean out the weaker part of the enemy group, so you don't waste time with the small things, and you can concentrate on the stronger ones. The game would certainly be very bad, if the Death spell would be ultimate way to kill anyone anytime, as at the point of getting it, all the other spells and things would be borderline useless.

You probably understand where am I getting to. Yes, we kind of managed, to make long distance transport to be more suited for trains, but other than that, bots are the one solution for everything. With bots, there is no reason to think about other types of transport (Cable cars or automated vehicles for example), because why would anyone use it when you have bots? It is kind of fun getting to the bots setup, and moving to the bot-only factory, but once it is achieved, the continued play feels very dull for me, because I know that this is it: There are very few improvements I can do to the system, and extending the factory is just about plopping more assembler/requester/provider cells without any thought. Also, with bots in the game, making extensions to Factorio feels useless. For example, the extension where you would expand to other planets, start there over, and once you achieve the rocket there, you would combine the production of the two planets somehow. But if starting on another planet just means playing with robots from the start, which means plopping a few cells of what you need and making a few mines, I don't see the point.

The question is, how to approach this problem? As Twinsen said, making belts stronger would not only be a compromise in some way and it would also reduce the amount of moving things, which is the proper metric in my eyes. When you see a huge factory, it is cool, because there are 16 blue iron belts being filled, not because the output is X per minute.

To be able to compare numbers, I made test setup. I created 4 fully compressed express belts and put them against a fully satisfied lane of roboports (also 4 tiles wide). To be able to measure the throughput easily, I just modded the furnaces to be very fast and smelted the result, iron for belts and copper for robots. This is the setup where belts are as strong as they can possibly be are in the bots versus belts balance. In majority cases, bots are going to be relatively much stronger compared to belts.



The result is, that bots did 16.4k per minute while belts only 9.6.



With worker robot speed research, it approaches the maximum around 19.5k per minute.

With this in mind, we can safely say, that robots are at least 2 times stronger then express belts, but in real factories, it is much more as belts need lot of other parts and are rarely used as ideally as robots would be, so my private guess would be that robots are currently around 5+ times stronger compared to belts.

In the last half year or more I have been putting together a lot of ideas around the concept of increasing the throughput of belts, and the last FFF and the resulting discussions made me focus on this topic heavily this last week. There are various options we looked into, some of them we even tried to prototype and played with them for a bit. I'll briefly try to describe some of them:
Packed items like pallets/containers

• Just adds another thing to do for every single recipe, mostly just adding tediousness. Basically mandatory barrels if you wanted to increase throughput.
• More tediousness means robots are an even better option; even if robots couldn't carry these heavy items, you could still use them for the unpacked item distribution. What would probably end up happening is that you would feed the stacked items from trains directly to unpacking assembling machines which would output to provider chests for robots.

Adding a new tier of super-fast belt or belt speed research

• Inserters would either need a speed increase as well, or would stop being able to take from the belt until the belt backs up. Increasing speed of inserters also increases the speed between containers, which would have an even bigger impact on robots.
• It would get ridiculously fast if you wanted to make a substantial increase (say, 3 times more speed).
• We already have 3 levels of belts and adding a speed research is just another number increasing research without unlocking a new entity.

New 1x1 Belt Stacker entity as the way how to make the stacks

• Gives the ability to make high throughput belt at the price of extra complexity.
• If the 1x1 entity is a chest-like loader which outputs on one side, it actually gets so hard that it reduces the amount of designs you can do with a fully beaconed setup to something like one or two obscure layouts which can't even output both compressed lanes of a fully stacked belt, making it even less interesting.
• If the 1x1 entity is a belt piece which lets items pass through and from the top new stacks can be added, it's just a belt piece which you have to build everywhere and you still can't use it to unload inserters directly into splitters/underground belts. At that point you might as well have inserters get this ability instead.
• You would have to adapt/rebuild all of your layouts, which in the late game is just not that appealing, if you can rip up your whole base to use robots.

New Belt Buffer entity like Klonan's mod

• Simplifies too many things and makes pretty much all designs obsolete except the simplest one.
• Doesn't actually increase belt throughput, just helps belt loading/unloading.

Research to have each N-th item be able to stack on the belt.

• Pretty much the same as belt speed research.
• Stack belt implementation would not be easy, especially visually.
• Having only every N-th item stack up and not all of them, would look really strange.

New tier of belt which would be able to stack items.

• You just have to produce and replace a new tier of belts.
• If only the stack belt is allowed to have stacks, then whenever items move to a single tile of a normal belt, all of the items would un-stack, which woulbe be quite annoying.
• If the stacks could only be created on the stack belt, but stay stacked on the normal belts, you would just build your insertion points, splitters and UG belts with the stack belt tier.
• Both of the previous points might not be the worst thing but it would be quite weird and would motivate you to just get rid of all normal belts ASAP.
• If only inserters would be able to create the stacks, it would get really annoying to attempt making a fully compressed, fully stacked belt even if inserters auto-compressed the belt.

Technology which would turn all belts into stack belts.

• You would research this and automagically all inserters, splitters and side-loading (also mining drills) would be able to make stacks on any type of the 3 belt tiers we have now.
• You don't get any new entity, but you get the choice between upgrading all of your belts with this technology and not having to do any extra work, or tearing up your base and replacing with robots.
• When you get the research, all of your belts would start buffering extra items, which some people might find annoying.
• If we could code this and find a visual solution which wouldn't take too much work, I would prefer this option.

All in all, the general issue of all of the belt throughput increases is the question if it wouldn't reduce the amount of belts that a newer player uses in their play through, reducing the complexity and interesting part of the game. I believe if this kind of research would happen after the rocket launch this would not be that much of a problem, especially since with robots you can reduce the amount of belts and complexity related to them to zero even earlier in the game.

The visual solution for the stack belt we intended would be items stacked on top of each other, which would be really hard to do as many of the item icons would have to be rethought. Keeping in mind that we have hundreds of item icons, this could be really dangerous, hard and time consuming to do. It's worth mentioning that with a stacked belt it would likely be less visually clear if your belt is fully stacked and compressed.

The coding solution of the stack belt including all of the item stacking in splitters, miners and side-loading might not be that easy either.

I think there is a bunch of issues that belt throughput increase would address, like:

• The "production numbers" reward for time spent when setting up robots is clearly bigger than for time spent building belts.
• Belts can't really keep up with heavily boosted setups by beacons.
• The last belt technology is relatively early in the game, so when you just look at the tech tree, you immediately know that robots are supposed to be the next step.
• The highest producing base possible to build at 60UPS is strictly robot based.

I had a look at various megabases, and I was actually quite surprised how far you can get with belts if you really try to be efficient. Of course not all of the UPS is tied to just belts, in fact the usual entity update consumes a greater portion now, but increasing the belt throughput 3 times seems like it would at least make belts competitive. However this is pure guesswork from seeing some big bases and reading their update times, and having some feel from using belts myself. If you are interested, you can send me your belt megabases that push the game to the limit, possibly with modded 3 times faster belts and inserters.

In general being able to see belt megabases to me is something really substantial. If a new player looks at a random Twitch stream, Youtube video, or Imgur album of a megabase, everything he sees now is a train network connecting a bunch of segregated robot production cells, which is visually repetitive, and compared to belt bases, visually less interesting. Being able to see belt bases in this top tier would be something that a new player could aspire to do one day and be inspired by. That would be the result of what Twinsen says about having the most interesting way to play being the most effective way to play.[/list]
As you can see each of the solutions has at least one serious problem, and it addresses a specific issue that you only really face after hundreds of hours in the game. It is probably better to leave this issue as it is so that we don't break the existing game. It might be better to focus on making belts more convenient to use instead of brute forcing the problem with throughput increases - especially as it's quite easy to address the speed changes in a mod which will just work together with the convenience improvements.

We decided that we won't make stronger version of belts for now, but we could still improve the usability of belts. I tried to make some interesting setups with belts and sushi setups, but I feel, that the belt filtering with filter inserters is very clunky when it is supposed to be reliable and have large throughput.

This is why we decided to add a few options to splitter configuration. These might be perceived overpowered by some, but we believe, that these mainly solve problems in the later part of the game when belts compete with bots, and when the player needs more control over the belt logistics.



Let me sum it one by one:

• Input priority - Specifies whether the left or right input should be always used first. The typical example where it might be useful is the case of "this mine should be depleted first, so lets prioritize ore coming from it".
• Output priority - This was often simulated using the circuit network, but it was not always 100% reliable, and when it was, the configuration was kind of clunky. Having priority is something simple that people can use very often, so we believe that it should be simple to achieve.
• Output filter - The strongest feature provided. It allows one item to be filtered to go to either left or right, while everything else goes to the other side. It might be argued, that this is what filter inserters are for. The problem with filter inserters is that you need several of them to make it work reliably, and the setup breaks when you run out of power for a small while as inserters would stop but not the belts. The setup can be made in a way that it doesn't break even in this case, but it makes it even more awkward. With the splitter filter, we have an easy way to reliably specify that an item that goes to the side and never gets to the other.

Here are few examples of what the splitter configuration can do:


The splitter additions will come with the next 0.16 release.

The conclusion is, that I strongly believe that bots should have a debuff. They should still be a big and powerful advancement when they are researched, but they should work more like the death spell. It should solve the little stuff that isn't that powerful (in Factorio, it is equal to smaller production). I even believe that robot-only Factory should be possible and not useless, I just don't believe, that they should be 5+ times stronger than anything else.

Players would still be able to build robot only factory, belt only factory or combination of those, but the strongest strategy would be to combine all types of transport, each for the part where they are the strongest. My suggestion would be to either completely remove the Worker robot cargo size research, or more likely, to multiply the charging time several times. For factory transport, both would have the same effect, but the latter wouldn't hurt personal transportation that much, as robots would transport all the missing items to player before they would need to be recharged, and then they would recharge when the player is already supplied and doing something else.

As always, leave us your thoughts and comments on our forum.

• Items on the ground can be mined manually for precise control of what you pick up.
  
• Added 'duplicate starting entities' option to PvP.
  

• Changed splitters so they work more intuitively. The left and right lane splitting is now completely independent. The decision whether item goes to left or right output is now independent of the item type.
  
• Hide cliff explosives in bonus GUI as they don't really receive any bonuses. more
  
• Tweaked the balancing of the PvP production score.
  
• Changed size of offshore pump from 3x1 to 3x2 in order to prevent pump placement in overlapping positions. more
  

• Optimized drawing of artillery range visualization when many artilleries were in range of viewed area. more
  

• Fixed that consequtive splitters could uncompress compressed belt. more
  
• Fixed that loading from the game-over screen would result in a crash if loading failed. more
  
• Fixed several settings copying issues when placing blueprints over existing entities related to multiplayer. more
  
• Fixed machines disabled by circuit network sometimes staying disabled when they shouldn't. more
  
• Fixed Linux users sometime crashing when relaunching the game. more
  
• Fixed that blueprint library GUI would lose your filter when you view a blueprint. more
  
• Fixed that biters would sometimes be deactivated when they shouldn't. more
  
• Fixed that artillery would target forces marked with cease fire. more
  
• Fixed a crash when using LuaTransportLine::remove_item(). more
  
• Fixed that the beacon would show energy consumption twice. more
  
• Fixed PvP production score calculation for hand crafting and launching satellites.
  
• Fixed jittering when walking into a straight water/land border. more
  
• Attempt at fixing missing symbol on macOS 10.9 more
  
• Fixed that turret range map and hover overlays didn't quite match. more
  
• Fixed that RCON would only respond to the first command in a packet. more
  
• Fixed PvP no rush restriction could be bypassed using a vehicle.
  
• Ensure that there is always at least a minimal lake in the starting area.
  
• Fixed script error if a removed modded item was sent in a rocket. more
  
• Fixed that loading logistic heavy saves after changing mods would take 20+ minutes. more
  
• Fixed a crash when mods would try to set item health values to negative amounts. more
  
• Fixed requester chests could get stuck in some cases. more
  
• Fixed that manually putting damaged items in the output slot of an assembling machine could lead to lost items. more
  
• Fixed chunk edge cliff discontinuities due to ore patches. more
  

• Added LuaEntity::cliff_orientation read.
  

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

• Items on the ground can be mined manually for precise control of what you pick up.
  
• Added 'duplicate starting entities' option to PvP.
  

• Changed splitters so they work more intuitively. The left and right lane splitting is now completely independent. The decision whether item goes to left or right output is now independent of the item type.
  
• Hide cliff explosives in bonus GUI as they don't really receive any bonuses. more
  
• Tweaked the balancing of the PvP production score.
  
• Changed size of offshore pump from 3x1 to 3x2 in order to prevent pump placement in overlapping positions. more
  

• Optimized drawing of artillery range visualization when many artilleries were in range of viewed area. more
  

• Fixed that consequtive splitters could uncompress compressed belt. more
  
• Fixed that loading from the game-over screen would result in a crash if loading failed. more
  
• Fixed several settings copying issues when placing blueprints over existing entities related to multiplayer. more
  
• Fixed machines disabled by circuit network sometimes staying disabled when they shouldn't. more
  
• Fixed Linux users sometime crashing when relaunching the game. more
  
• Fixed that blueprint library GUI would lose your filter when you view a blueprint. more
  
• Fixed that biters would sometimes be deactivated when they shouldn't. more
  
• Fixed that artillery would target forces marked with cease fire. more
  
• Fixed a crash when using LuaTransportLine::remove_item(). more
  
• Fixed that the beacon would show energy consumption twice. more
  
• Fixed PvP production score calculation for hand crafting and launching satellites.
  
• Fixed jittering when walking into a straight water/land border. more
  
• Attempt at fixing missing symbol on macOS 10.9 more
  
• Fixed that turret range map and hover overlays didn't quite match. more
  
• Fixed that RCON would only respond to the first command in a packet. more
  
• Fixed PvP no rush restriction could be bypassed using a vehicle.
  
• Ensure that there is always at least a minimal lake in the starting area.
  
• Fixed script error if a removed modded item was sent in a rocket. more
  
• Fixed that loading logistic heavy saves after changing mods would take 20+ minutes. more
  
• Fixed a crash when mods would try to set item health values to negative amounts. more
  
• Fixed requester chests could get stuck in some cases. more
  
• Fixed that manually putting damaged items in the output slot of an assembling machine could lead to lost items. more
  
• Fixed chunk edge cliff discontinuities due to ore patches. more
  

• Added LuaEntity::cliff_orientation read.
  

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

• Fixed that underground belts built by a blueprint would not respect the type of an existing belt. more
  
• Fixed pump ghosts would always highlight attached rail, not just when selected.
  
• Fixed that logistic network requests would get into invalid state when migrated from save where player had more requests due mods. more
  
• Improved number formating in electricity overview to make it less jumpy. more
  
• Fixed logistic robots migration related to changing force of logistic robots while stationing. more
  
• Fixed when sliding around entity, the character could be pushed to a position colliding with water and get stuck in the terrain. more
  
• Reduced RAM usage by removing unnecessary memory buffers for textures when using OpenGL. more
  

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

• Fixed that underground belts built by a blueprint would not respect the type of an existing belt. more
  
• Fixed pump ghosts would always highlight attached rail, not just when selected.
  
• Fixed that logistic network requests would get into invalid state when migrated from save where player had more requests due mods. more
  
• Improved number formating in electricity overview to make it less jumpy. more
  
• Fixed logistic robots migration related to changing force of logistic robots while stationing. more
  
• Fixed when sliding around entity, the character could be pushed to a position colliding with water and get stuck in the terrain. more
  
• Reduced RAM usage by removing unnecessary memory buffers for textures when using OpenGL. more
  

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

We had quite a lot of critical bugs after the 0.16.8 release that introduced the logistic chest finalisations mentioned in the last FFF. I'm sorry for the trouble, but it is called experimental version for a reason.

It seems that 7 releases in the past week has been enough to stabilize it. We are finally in a state, where we are fixing more bugs than are reported, and we are reaching the first boundary of less than 100 active bug reports.

It seems that the most urgent things are to be be finished soon, and we could find the needed time to dive into the belt logic to be able to consolidate it. This is my plan for the next week.

During more boring FFF, I like to do these gameplay rants where I share my ideas about game design. Here is one of them.

Ever since I started playing Factorio, I have thought of logistic bots as too powerful. Actually, I refused to use them thinking "surely there is some catch to this and they can't replace belts". Since then I was always a "bot hater". I believed it trivialized base building and managing belts. I also believe that building belts is way more fun due to it's inherent complexities, challenges, and emergent situations (the most common example being belt balancing).

Bots vs. belts is a controversial subject, even in our team, but most of us believe bots are too powerful. So we did small nerfs from time to time in an effort to compensate for this, but we still keep coming to the same conclusion.

My argument is that bots are simply fundamentally better. Bots basically cheat by "teleporting" items, plus they are extremely easy to build and expand. This means that almost any nerf we throw at them is always solved by building more bots and/or more roboports and/or more solar panels. All of this can be done with a simple copy paste using blueprints. Plus they are even UPS friendly, so it seems like bots are the win-win-win solution.

So I had this rather crazy idea of removing logistic bots from the game. Basically my idea was that construction bots would still be a thing and player logistics would still work. This would be done by:

• Merging logistic and construction bots into just Flying Robots.
• Removing Active provider, Buffer and Requester chests and having just Passive provider and Storage chests.
• Flying Robots will do everything construction bots do now and also supply the player.
• Simplifying recipe complexity a bit so the belt spaghetti does not get ridiculous.

Now, hopefully you aren't smashing your desk and writing us an angry email. Don't worry, logistics bots won't be removed from the game, mostly because it's a feature that has been developed and polished quite a lot. Also many players love the feature, and we've all become used to it over the years. But think of it a different way, imagine there were two parallel universes:

• The universe we are in, where Factorio has had logistic bots since very early.
• A universe where Factorio never had this feature. Construction bots were eventually added, and using bots to move items freely is nothing more than an idea that pops up from time to time but it's quickly discarded due to it breaking the game.

Which Factorio would be the best and most fun one for the players in that universe?
To be honest it's very hard to decide. I would go with the more pure Factorio from universe 2 that focuses on it's core and most fun mechanic: belts and belt logistics. I'm curious what you guys think.
I mentioned this, because I think this way often in an attempt to "make the best game ever" without being influenced by my biases of being used to some feature or style of play.

But let's return to reality and the game we have now. Quite recently I actually realized that bots are not as bad as I thought. The logistics system is placed very late in the tech tree, so most of a typical playthrough will be done using belts. The fact that you get this almost game breaking feature is not so bad because it's late in the game. After this you can continue to challenge yourself and build even bigger using bots, or belts or both.

We are still looking to incentivize belt building a bit more, since it is the more fun way to play Factorio, but the question is how.
We have ideas like increasing the power consumption, decreasing the maximum stack size bots can carry to 2 items or buffing belts by adding a "stacked" belt tier.

Like I mentioned before, I try to balance things by looking at numbers and objective facts. I'm trying to determine how much better bots are than belts, so I can know if for example nerfing the stack size to 2 will have the desired effect, or just make players angry. I thought of metrics like throughput over time to set up, or throughput over base size.

But how do these metrics influence the big picture and will any of these make the game more fun in the long run?

We don't know the answer to these questions yet. What is your take on this bots versus belts thing? What changes, if any, could we do to make everything more fun?

Pro-bot arguments:

• The fact that they are so powerful, gives a very big sense of progression. They are behind a late game research, and gives you things that are very powerful and game changing.
• It adds large diversity to the game.

Anti-bot arguments:

• Bot bases are usually less complex and less interesting to look at, manage and expand.
• Because of their ease of use (and apparent ease of use), players tend to go to bots. We believe that belts are more fun, but we are guiding the player towards a less fun style of play.
• When you learn that bots exist and how they work, building bases with belts just seems tedious.

Related to this I'd like to give a shout-out to forum member ultramn, for his interesting Self-contained 1,000 SPM base. We analysed his save while we were having some bot vs. belt discussions this week.
His save proves that bots can get ridiculously powerful, but at the same time it shows that there is a lot of fun to be had with bots if you challenge yourself to make something.



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

We had quite a lot of critical bugs after the 0.16.8 release that introduced the logistic chest finalisations mentioned in the last FFF. I'm sorry for the trouble, but it is called experimental version for a reason.

It seems that 7 releases in the past week has been enough to stabilize it. We are finally in a state, where we are fixing more bugs than are reported, and we are reaching the first boundary of less than 100 active bug reports.

It seems that the most urgent things are to be be finished soon, and we could find the needed time to dive into the belt logic to be able to consolidate it. This is my plan for the next week.

During more boring FFF, I like to do these gameplay rants where I share my ideas about game design. Here is one of them.

Ever since I started playing Factorio, I have thought of logistic bots as too powerful. Actually, I refused to use them thinking "surely there is some catch to this and they can't replace belts". Since then I was always a "bot hater". I believed it trivialized base building and managing belts. I also believe that building belts is way more fun due to it's inherent complexities, challenges, and emergent situations (the most common example being belt balancing).

Bots vs. belts is a controversial subject, even in our team, but most of us believe bots are too powerful. So we did small nerfs from time to time in an effort to compensate for this, but we still keep coming to the same conclusion.

My argument is that bots are simply fundamentally better. Bots basically cheat by "teleporting" items, plus they are extremely easy to build and expand. This means that almost any nerf we throw at them is always solved by building more bots and/or more roboports and/or more solar panels. All of this can be done with a simple copy paste using blueprints. Plus they are even UPS friendly, so it seems like bots are the win-win-win solution.

So I had this rather crazy idea of removing logistic bots from the game. Basically my idea was that construction bots would still be a thing and player logistics would still work. This would be done by:

• Merging logistic and construction bots into just Flying Robots.
• Removing Active provider, Buffer and Requester chests and having just Passive provider and Storage chests.
• Flying Robots will do everything construction bots do now and also supply the player.
• Simplifying recipe complexity a bit so the belt spaghetti does not get ridiculous.

Now, hopefully you aren't smashing your desk and writing us an angry email. Don't worry, logistics bots won't be removed from the game, mostly because it's a feature that has been developed and polished quite a lot. Also many players love the feature, and we've all become used to it over the years. But think of it a different way, imagine there were two parallel universes:

• The universe we are in, where Factorio has had logistic bots since very early.
• A universe where Factorio never had this feature. Construction bots were eventually added, and using bots to move items freely is nothing more than an idea that pops up from time to time but it's quickly discarded due to it breaking the game.

Which Factorio would be the best and most fun one for the players in that universe?
To be honest it's very hard to decide. I would go with the more pure Factorio from universe 2 that focuses on it's core and most fun mechanic: belts and belt logistics. I'm curious what you guys think.
I mentioned this, because I think this way often in an attempt to "make the best game ever" without being influenced by my biases of being used to some feature or style of play.

But let's return to reality and the game we have now. Quite recently I actually realized that bots are not as bad as I thought. The logistics system is placed very late in the tech tree, so most of a typical playthrough will be done using belts. The fact that you get this almost game breaking feature is not so bad because it's late in the game. After this you can continue to challenge yourself and build even bigger using bots, or belts or both.

We are still looking to incentivize belt building a bit more, since it is the more fun way to play Factorio, but the question is how.
We have ideas like increasing the power consumption, decreasing the maximum stack size bots can carry to 2 items or buffing belts by adding a "stacked" belt tier.

Like I mentioned before, I try to balance things by looking at numbers and objective facts. I'm trying to determine how much better bots are than belts, so I can know if for example nerfing the stack size to 2 will have the desired effect, or just make players angry. I thought of metrics like throughput over time to set up, or throughput over base size.

But how do these metrics influence the big picture and will any of these make the game more fun in the long run?

We don't know the answer to these questions yet. What is your take on this bots versus belts thing? What changes, if any, could we do to make everything more fun?

Pro-bot arguments:

• The fact that they are so powerful, gives a very big sense of progression. They are behind a late game research, and gives you things that are very powerful and game changing.
• It adds large diversity to the game.

Anti-bot arguments:

• Bot bases are usually less complex and less interesting to look at, manage and expand.
• Because of their ease of use (and apparent ease of use), players tend to go to bots. We believe that belts are more fun, but we are guiding the player towards a less fun style of play.
• When you learn that bots exist and how they work, building bases with belts just seems tedious.

Related to this I'd like to give a shout-out to forum member ultramn, for his interesting Self-contained 1,000 SPM base. We analysed his save while we were having some bot vs. belt discussions this week.
His save proves that bots can get ridiculously powerful, but at the same time it shows that there is a lot of fun to be had with bots if you challenge yourself to make something.



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

• Added 'allow spectators' option to PvP.
  

• Changed rail world settings to have normal biters frequency.
  

• Fixed loading specific saves wouldn't migrate the character requests correctly to request from buffer chests. more
  
• Fixed that migrating saves would make research impossible in the level 4 of New hope campaign. more
  
• Fixed that inserters would try to put items into furnaces that could never fit. more
  
• Fixed requester chests wouldn't keep up with the request amount demand in logistic heavy saves. more
  
• Fixed that request chests weren't equally distributed when there were not enough robots.
  
• Fixed that migration to 0.16.8 which de-duplicated logistic requests wasn't doing so for offline players. This could cause crashes as the internal data structures take it as granted.
  
• Fixed that download progress bar in the sync save with mods wasn't being updated.
  
• Fixed that exiting the connection in progress (by pressing escape) soon enough could result in a screen without any menu.
  
• Fixed some PvP game modes being won by launching a rocket.
  
• Fixed config.ini would be purged when game decreases graphics settings when loading sprites throws an error. more
  

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

• Added 'allow spectators' option to PvP.
  

• Changed rail world settings to have normal biters frequency.
  

• Fixed loading specific saves wouldn't migrate the character requests correctly to request from buffer chests. more
  
• Fixed that migrating saves would make research impossible in the level 4 of New hope campaign. more
  
• Fixed that inserters would try to put items into furnaces that could never fit. more
  
• Fixed requester chests wouldn't keep up with the request amount demand in logistic heavy saves. more
  
• Fixed that request chests weren't equally distributed when there were not enough robots.
  
• Fixed that migration to 0.16.8 which de-duplicated logistic requests wasn't doing so for offline players. This could cause crashes as the internal data structures take it as granted.
  
• Fixed that download progress bar in the sync save with mods wasn't being updated.
  
• Fixed that exiting the connection in progress (by pressing escape) soon enough could result in a screen without any menu.
  
• Fixed some PvP game modes being won by launching a rocket.
  
• Fixed config.ini would be purged when game decreases graphics settings when loading sprites throws an error. more
  

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