So... Let's talk about bots, and how to fix them properly...

[bobucles]

On their own it won't be enough to deal with belt problems

I find that hard to believe. A blue belt with size 4 stacking will move 160 items/sec, with 80 items per lane. That's a lot of items!

inventory-to-belt transfer speed of Inserters are also a main source of the limitations at hand even with Stack Inserters

I also find this hard to believe. A flat belt can be saturated with 3 upgraded fast inserters per lane. Multiplying the belt capacity and inserter capacity by 4 (inserter 3 => stack inserter 12) leaves these values the same. It's not a big deal to use 6 stack inserters to super saturate a belt. That's one side of a train unloading station, with each train car saturating a super belt.

The small question is if such high capacity can feed a module/beacon setup. I think they can. The big question is if it players will use those stronger belts in their builds. That's a bit too difficult for me to know!

Edit: I don't think belt stacking has any benefit beyond low tech items. It's hard enough to load a belt with red circuits, never mind trying to saturate a rocket fuel belt. Oh well.

[MeduSalem]

On their own it won't be enough to deal with belt problems

I find that hard to believe. A blue belt with size 4 stacking will move 160 items/sec, with 80 items per lane. That's a lot of items!

I think you misunderstood what I meant with that. I didn't write that stack belts aren't capable of dealing with throughput problems. Actually I am pretty sure for bulk transfer it would be rather nice.

What I meant instead was that I think that in unison with some of the inserter problems it won't be enough to just increase the throughput, which I count towards the belt problems, hence the "on their own it won't be enough", or at least not for all applications, as described further below.

inventory-to-belt transfer speed of Inserters are also a main source of the limitations at hand even with Stack Inserters

I also find this hard to believe. A flat belt can be saturated with 3 upgraded fast inserters per lane. Multiplying the belt capacity and inserter capacity by 4 (inserter 3 => stack inserter 12) leaves these values the same. It's not a big deal to use 6 stack inserters to super saturate a belt. That's one side of a train unloading station, with each train car saturating a super belt.

The small question is if such high capacity can feed a module/beacon setup. I think they can. The big question is if it players will use those stronger belts in their builds. That's a bit too difficult for me to know!

How do you plan to put all the necessary inserters in between beaconized setups for high volume recipes like electronic circuits?

Electronic Circuits are currently already rather hardcore to try with belts between beacons. I tried, and couldn't get any setup to work reliable without serious machine stalling problems due to inserters being too slow or interfering with one another due to accessing the same belt. Inserters interfering with one another becomes actually a problem even with other recipes as well if they need a lot of ingredients, like for example Processing units, especially when two nearby inserters try to grab electronic circuits from the same belt lane forcing one of the stack inserters to jump back and forth between the near and the far side lane, further delaying the input due to how every time the inserter has to re-adjust the arm position costing additional time.

Even with normal recipe requirements for electronic circuits etc I already find it stressful to do it with Bots. Even with bots I already need 3 Stack Inserters (1 for Iron Plates, 2 for Copper Cables) with their inventory-to-inventory bonus to keep up with the input of Iron Plates and Copper cables and a 4th one for the circuit output so that the assembler doesn't start stalling. But it is do-able and I am using such a setup currently in my normal recipe difficulty games.

On expensive mode it is almost... impossible even with bots because of how you only have space for 6 inserters around the machine at best between beacons... and somewhere you have to get power from as well so a powerpole would probably also be somewhere, except if you use substations, but they are even more bulky and almost don't fit in without sacrificing some beacons or machines. So it is hard at the limit of what is possible.

So how do you do it with belts where the inserters are even slower and more limiting?

How do you think a stack belt with for example 4 items per stack would keep up with that if a stack inserter requires to wait for at least 3 stacks (if fully compressed) to come by before it can swing to achieve what a single Stack inserter can do from logistic chest-to-machine without having to wait? So you probably need more inserters to access the stack belt in parallel to avoid machine stalling... again, leading to all kinds of space problems as described above... hence why I would probably say screw that and go for bots... again.


So what that means for me is that some adjustments to the Inserters might be necessary as well, or otherwise the belt stack wouldn't solve all problems for why I abandon belts.


I mean on your slow crafting speed / low-ingredient / low-demand recipes Inserters don't matter anyway because even if it is a beaconized setup the inserters are faster at loading/unloading than the recipe can craft and require ingredients or output items. But on those recipes you mostly don't even need stack belts anyway because you only ever have maybe 1 belt or so of them and it doesn't even need to be an express belt.

Ore/Plates recipes are the most reasonable sweet-spot though... average crafting times and resource requirements, hence no inserter problems. Yet you still need a ton of ore and plates, hence where stack belts would shine most.

[factory65]

I don't think any changes should be made to bots, they are "fixed properly". I think you should make the changes to belts. Just throwing out ideas:

A. Faster Belts and the longer undergrounds to go with them - Ideally the fastest belt should be faster than bots over the same distance with higher throughput. Bots would still be more flexible.
B. Belt compression, balancing, splitting, and lane control should be easier to use and deploy. A simple on the belt lane switcher would be a start.
C. Built in on the belt inserters - these can be placed directly on the belt and the belt directly against assemblers and so on and insert according to belt throughput to enable new designs.

As I look over my bot based mall it comes to mind that for storage, distribution, and small scale flexible production the combination of bots, requesters, and passive providers is a pretty perfect solution for this. Having to do all that with belts would be step backwards in the evolution of the base. Nerfing any of that would be a shame. But when I look over at builds for things I want a lot of, like science packs, circuits, the main bus, the smelters... this is where belts should really shine, even if in some cases they don't. To me this is where the balance belongs between bots and belts and the changes that you make should be with one goal for bots, which, imo is already well implemented, and another goal for belts, which could use a lot of improvement.

My .02

[oracleofepirus]

You guys are still trying to match belt and bot throughput. That's never going to work if belts don't have unique advantages. Adding stacked belts just increases throughput. It does not make belts easier to deploy or give any advantages that bots don't have.

Choices are made primarily in two ways, sheer numbers, and unique function. Bots have belts beat on both ends. If you triple belt capacity to 120, bots are still better, because belts have to jump through hoops to separate lanes, inserters still can't keep up because belt-to-assembler inserter speed is like half of chest-to-inserter speed, adding capacity requires you to stop the entire thing and deconstruct it, and all sorts of other functions.

Belts need something that bots can never have, something like power usage, or fine-grained item movement, or whatever else. Increasing belt throughput should be second to enhancing belt function.

[bobucles]

Adding stacked belts just increases throughput. It does not make belts easier to deploy

Yes it definitely does. Ever tried organizing 40 belts of material? It is much more difficult than organizing 10 belts of material. The difficulty of balancing and ensuring maximum flow through the belt system increases with the number of belts. So if you need fewer belts, it only makes sense that a similar build will be easier to set up.

inserters still can't keep up because belt-to-assembler inserter speed is like half of chest-to-inserter speed,

Item stacking ALSO increases belt transfer rates in a dramatic way. There is an initial burst grab where the inserter can grab the first two or three items in quick succession. After that it has to wait for more items to stream in. A current inserter can grab 3 and then wait for the other 9 items to pour in, or it can grab 3 quad stacks and dunk the item right away. Thus the "half speed" gets buffed to something much closer to 80-90% speed, which is perfectly competitive with chest transfer rates.

[oracleofepirus]

Yes it definitely does. Ever tried organizing 40 belts of material? It is much more difficult than organizing 10 belts of material. The difficulty of balancing and ensuring maximum flow through the belt system increases with the number of belts. So if you need fewer belts, it only makes sense that a similar build will be easier to set up.

That's changes a quantitative property. It does not change the way they work. Belts need a qualitative advantage, not a quantitative buff. People have been asking for higher-throughput belts since forever. I have seen a handful of people ask for a smart splitter. In fact, a measureable portion of players thought that smart splitters would be too good.

Item stacking ALSO increases belt transfer rates in a dramatic way. There is an initial burst grab where the inserter can grab the first two or three items in quick succession. After that it has to wait for more items to stream in. A current inserter can grab 3 and then wait for the other 9 items to pour in, or it can grab 3 quad stacks and dunk the item right away. Thus the "half speed" gets buffed to something much closer to 80-90% speed, which is perfectly competitive with chest transfer rates.

Surely the one place this would have a guaranteed benefit is copper wire production. A yellow p1.0 assembler produces 5 copper wire per second. Beaconed p1.4 assemblers produce 30.8, 37.8, and 44.8 copper wire per second for 8, 10, and 12 beacons. A level 7 stack inserter has a 27.7 chest-to-chest speed and 12.2 chest-to-blue speed. Show me your math.

I'd rather argue for implementing an inserter pick/drop position ui, as that's already in the game and significantly changes every belt build. Bot setups would never care about such a thing, because their inserter layouts are already optimal.

[atmh]

I know this has already been said, but gonna add my vote for bot fixing:

TL;DR: To make replay the most fun, bots should be mid-level technology, but don't need to be more powerful than belts: Make bots have to wait in a queue to pickup/drop off, set speed to be similar to inserters, but return logistics bots to being an easier technology.

Belt load: Make it so chests can be loaded up and then transferred to a belt, similar to how barrels are handled now.


Longer version:

If bots are to be nerfed, the appropriate nerf should be making it so that they have to queue to pickup/drop off items. The time-constant for a bot to pick/drop can be tuned to make them however fast the devs want them to be: Either 0s for keeping them the way they are now, or maybe .5s to make them equivalent to a fast inserter. At the same time of doing this nerf, I think it's really damaging to replay to have the bots technology so deep now - when I replay factorio, I almost exclusively have a goal to build a certain kind of base (trains, etc) and right now it's ~20 hours of gameplay (for me) just to get a base setup with bots so that I can start generating my low-N products easier. It's not really fun. Even if I want to build a belt base, the logistics bots are so critical to just get the darn thing up and running without having a tangle of noodles everywhere.

As for belt load: when I first started playing factorio I thought for sure things would be able to be "palletized". Right now this is only true for fluids in barrels, and we can see that makes a pretty healthy throughput on belts. In fact, I thought that this is exactly what boxes would have been used for. It would be great if there wasn't a new item class, but if we could just put loaded boxes/chests onto belts.


***
(Factorio is, by hours count, my favorite game ever. In all my 30+ years I never put this much time into a game <3. Way to go, folks!)

[Aeternus]

You guys are still trying to match belt and bot throughput. That's never going to work if belts don't have unique advantages. Adding stacked belts just increases throughput.

Adding the ability to throw a full stack of an item (IE 200 electrical circuits, 100 Metal Plates or 50 Ore) as a single unit on a belt would cause belts to FAR exceed the max capacity of bots, and will also reduce the UPS hit that belt based megafactories take due to the ability for belts to reduce the amount of moving items by 95% or higher. And while I originally suggested a pelletizer for that kind of thing... why not make Stack Inserters move actual full stacks?

UPS wise, belts will only become better if the amount of items moving on them reduces while throughput is maintained.

[Caine]

Adding the ability to throw a full stack of an item (IE 200 electrical circuits, 100 Metal Plates or 50 Ore) as a single unit on a belt would cause belts to FAR exceed the max capacity of bots

It would also make belts compete on throughput with trains, thus creating an imbalance between trains and belts. This can be fixed by increasing the throughput of the trains and we will effectively have nerved bots. In other words, buffing belt throughput is not the solution.

[Aeternus]

Nah. At long distances, trains would easily outcompete belts on sheer speed alone. At short distances for bulk transport not so much. At mid distances... depends I suppose. Bots still win on flexibility and low volumes.

[ftbreizhbugs]

If i would change the way bots works, I would
- Delete all logi chest
- Make bots move items only from roboports inventory to roboports inventory (also apply to personnal roboport: must be equipped to receive item from provider roboport).
- Roboports act either as requester chest or provider chest. Bots can put item back into "a specific item roboport provider" if there is room in it (i mean even if number of slot is limited via the red cross, items carried by bots can be put back into it, but inserter could'nt -cause item from assembly comes from inserter and we dont want to overproduce)(if it were possible with actual provider chest it would avoir us the yellow chest spam for items that are mostly never put back onto the belt system again and can only be reused by the player own logi system)
- Limit the number of bots that can be controlled in a roboport network(100 logi AND/OR 100 construction bots-for example depending on the vision of the dev on the bot: a big support, a small mid range help...), more roboports in the same network is only extended area!
- Limit the number of 'item' slot in roboport (1-6 slots) (they dont act as storage chest but just as buffer to feed the logi network)
- Maybe make a separate type of roboport for the construction bots? (with more item slot where one slot equal on type of item)

[Nel]

Belts and bots are both extremes on the same spectrum, flexibility. Belts are 100% static and player driven, while bots are 100% dynamic and automatically managed by the game. The main points are:

• The path of each item on a belt is fixed and predetermined by the player, through the placement of splitters, inserters and sideloading belts, while bots distribute the pool of available resources to where they are requested in an autonomous way
• To extend the previous point, belts carry what they were given, which is usually a max of 2 different item types (one on each lane), while bots dynamically pick up whatever item is in need of transport
• Each element in a belt network takes up space and has to be incorporated into any factory design, competing with essential elements like assembling machines themselves, energy poles and beacons, while bots only require one 4x4 building to enable them access to an area
• Since belts are always active and always at their place, belt elements not carrying items or being stacked up are basically wasted resources, because they are not doing any work, whereby only the first case (not enough items) apply to bots
• Belts have a maximum throughput, and each item is transported at the same speed on a belt, recipes requiring different ratios of items require different belt layouts, while bots automatically distribute their capacity evenly, no matter how even or odd the requests

While increasing belt speed seems to be a very popular suggestion, I think this would not solve the issue, but rather make the game even more boring. Assume a belt would carry not merely one item, but whole stacks. While that would put belts ahead of bots in terms of throughput, the place currently reserved for the requester / provider chest would now be occupied by a belt line, the overall design would not change. This also means that there would be no puzzle to solve here, since belts would provide more throughput than can be practically used up, even with beaconed set-ups.

What I think is needed is a new transport network that is capable of delivering items dynamically and as requested like the bot network does currently, but actually has a cost in terms of foot print. I.e. it would bring items to a station, lets call them "cargo ports" (3x2 or 5x2 entity) with a reasonable throughput, which is served by autonomous entities that move alongside rails. Rails and cargo ports should be easy to integrate as providing points to a factory, but not easy enough that you would actually feed all (!) assembly machines right out of the cargo ports. Lets make an example with iron ore:
Iron ore would be transported by train to the unload station near the smelting array. From there, it would be unloaded into the cargo ports of this new network, which would carry the ore to local cargo ports of the array. There, the ore would be transported via belt to each smelter. The smelted plates will then be transported via belts to cargo ports, which will distribute the plates to other cargo ports requesting them, i.e. science pack factories, or steel smelting arrays, or wherever else they are requested. As such, this network would practically work as the main bus, which is currently realized with belts in most playthroughs, but at the same time allowing expansion not only downstream, but also up stream.

Unfortunately, the devs so far have not indicated their interest in such a transport option, or even in allowing mods to create it (e.g. by utilizing the train infrastructure that is already in the game).

[Aeternus]

While increasing belt speed seems to be a very popular suggestion, I think this would not solve the issue, but rather make the game even more boring. Assume a belt would carry not merely one item, but whole stacks. While that would put belts ahead of bots in terms of throughput, the place currently reserved for the requester / provider chest would now be occupied by a belt line, the overall design would not change. This also means that there would be no puzzle to solve here, since belts would provide more throughput than can be practically used up, even with beaconed set-ups.

There wouldn't? Try snaking a belt through some current beacon-heavy bot-only setups. Finding the space for belts, usually 2 in, 1 out, is a big part of the logistics puzzle. A part that the bot network completely solves by removing it entirely, without significant drawbacks.

[Eketek]

Belts and bots are both extremes on the same spectrum, flexibility. Belts are 100% static and player driven, while bots are 100% dynamic and automatically managed by the game. The main points are:

• The path of each item on a belt is fixed and predetermined by the player, through the placement of splitters, inserters and sideloading belts, while bots distribute the pool of available resources to where they are requested in an autonomous way
• To extend the previous point, belts carry what they were given, which is usually a max of 2 different item types (one on each lane), while bots dynamically pick up whatever item is in need of transport
• Each element in a belt network takes up space and has to be incorporated into any factory design, competing with essential elements like assembling machines themselves, energy poles and beacons, while bots only require one 4x4 building to enable them access to an area
• Since belts are always active and always at their place, belt elements not carrying items or being stacked up are basically wasted resources, because they are not doing any work, whereby only the first case (not enough items) apply to bots
• Belts have a maximum throughput, and each item is transported at the same speed on a belt, recipes requiring different ratios of items require different belt layouts, while bots automatically distribute their capacity evenly, no matter how even or odd the requests

While increasing belt speed seems to be a very popular suggestion, I think this would not solve the issue, but rather make the game even more boring. Assume a belt would carry not merely one item, but whole stacks. While that would put belts ahead of bots in terms of throughput, the place currently reserved for the requester / provider chest would now be occupied by a belt line, the overall design would not change. This also means that there would be no puzzle to solve here, since belts would provide more throughput than can be practically used up, even with beaconed set-ups.

What I think is needed is a new transport network that is capable of delivering items dynamically and as requested like the bot network does currently, but actually has a cost in terms of foot print. I.e. it would bring items to a station, lets call them "cargo ports" (3x2 or 5x2 entity) with a reasonable throughput, which is served by autonomous entities that move alongside rails. Rails and cargo ports should be easy to integrate as providing points to a factory, but not easy enough that you would actually feed all (!) assembly machines right out of the cargo ports. Lets make an example with iron ore:
Iron ore would be transported by train to the unload station near the smelting array. From there, it would be unloaded into the cargo ports of this new network, which would carry the ore to local cargo ports of the array. There, the ore would be transported via belt to each smelter. The smelted plates will then be transported via belts to cargo ports, which will distribute the plates to other cargo ports requesting them, i.e. science pack factories, or steel smelting arrays, or wherever else they are requested. As such, this network would practically work as the main bus, which is currently realized with belts in most playthroughs, but at the same time allowing expansion not only downstream, but also up stream.

Unfortunately, the devs so far have not indicated their interest in such a transport option, or even in allowing mods to create it (e.g. by utilizing the train infrastructure that is already in the game).

If you are interested in dynamic bot-less logistics, I modded in a partial implementation of this a few weeks ago (as somewhat of a response to belts vs bots, but mainly as a more sensible way to accomplish what I've been trying to do with combinators for a while). My mod processes and generates circuit signals which may be used by circuit-controlled junctions to make items individually routeable. Basically, the mod provides a LUA-based back-end [that would otherwise need a large and slow combinator setup] to support a circuit-controlled logistics system built out of combinators, belts, inserters, trains, and, if you want to be a bit whimsical about it, bots & requester chests.

Eketek's Routing and Pathfinding Mod

[ratchetfreak]

If we look at what a botnetwork is good at now I see 2 things:

1. random low throughput transport.
2. Big burst of transport with recovery time needed.

The burst capacity comes from how the bots are launched: launched with full battery without affecting the battery charge of the roboports.

low sustained throughput comes from recharge rates.

If instead roboports were unable to dump all 9 stacks worth of logi bots in under a minute but instead needs to recharge a launch battery after a dozen. This would reduce the big burst capacity of bots but not to 0. And it links sustained throughput (the most common issue with bot build I believe) to amount of roboports more intuitively rather than to number of bots as one would assume when you have bot throughput issues.

[Aeternus]

With sufficient roboports, that burst you mention becomes sustained. That's one of the things that causes an imbalance.

[ratchetfreak]

With sufficient roboports, that burst you mention becomes sustained. That's one of the things that causes an imbalance.

The UX imbalance with bots is also import to fix IMO.

It takes a very long time for a botnetwork to reach into the sustained throughput wall. It needs several recharge cycles before charging queues are distributed enough.

If you link the sustained throughput to the burst capacity in a clear way (by for example also not allowing bots to launch from the port when the port has bots in its charge queue) the UX problem goes away. Combine this with the way bots select where they park will also mean that bots become a lot less attractive for high throughput situations.

[MeduSalem]

It needs several recharge cycles before charging queues are distributed enough.

If you are experiencing charging queues you are doing something wrong in the first place... like not having enough roboports.

[ratchetfreak]

It needs several recharge cycles before charging queues are distributed enough.

If you are experiencing charging queues you are doing something wrong in the first place... like not having enough roboports.

I know that but that is not explained through gameplay and that is a big problem with the gameplay design of roboports that needs to be fixed

[Davy Crockett]

Add collision to robots so they can be effective at helping with annoying chores and less effective with mass production.
This also can be an opportunity to add more complex recipes to the game which were not feasible before because they relied on a belt web method for supplying components

I like this idea the best. If end game recipes required small amounts of special/rare materials on top of large amounts of abundant materials, this would work really well; you would have to use belts to deliver the bulk materials and bots to deliver the rare stuff.

This would shift the end game focus quite a bit though, and many people might not like it. Personally, I've always thought you should at least have to mine gold for electronics, which would be one of the rare resources in this scenario.