Friday Facts #225 - Bots versus belts (part 2)

[Oktokolo]

Note that buffer chests never pull from buffer chests, so there is no advantage to having multiple buffers along the way.

Damn, i expected them to basically split long paths into chunks. Too bad they don't work that way.

Tried it again with buffers at receiving end. I did a staggered startup, leaving minutes pass between enabling the requester and buffer chests. That way, i avoided the clusters of bots waiting for a recharge slot in random spots on the path.
I managed to compress four blue belts that way. But the setup with only one column of ports is absurdly brittle. Add some more buffer chests and you get clusters of exhausted bots again. I literally hat clouds of metal slowly wandering the sky above that port path... I had 60k logistics bots in that system (had multiple blue belts feeding roboports, so that also more or less should be the amount, the system demanded).

It's fun to test that stuff. The conclusion ist, that you would need a lot of infinite research until bots really could beat belts over long distances. And then it would still be a very brittle system with slowly rolling metall clouds in the air whenever demand increases by some chests. Certainly no fun in an actual factory.

Did you check the 'request from buffer chests' in the requester?

Of course. Not that i did never used bots - i just tried to avoid it for most stuff because it never looked good.

[bobucles]

I figured I'd give the long bus a test as well. The results are largely what I expected with a few surprises on buffer chests.
- 4.5 radars long (299 roboports - 1196 tiles)
- Bot speed 10
- 24 infinite providers
- 16 buffers (set to 3K ore)
- 27 requesters (set to 750 ore)
- ~8000 bots in the network.

Here are a few things I learned:
- A solid line of roboports still moves roughly the amount of items no matter how long it is. Naturally finding the sweet point for # of bots to maximize recharge+ idle efficiency is more difficult and it does take a much longer time to reach a stable equilibrium.
- Requester chests, even set to buffer mode, will absolutely have priority over buffer chests. I had to lower the blue chest demand to let buffer chests be used at all. As it stands the ore request (750*27 = 20K ore) will straight up demand 5000 bots, and they are all taking the long path to the providers. Only ~3K bots can be spared to handle buffer chests. This is confirmed in the screen shots (750 * 16 buffers => 12K requested ore => 3K bots)
- The 19.0K/s production is equivalent to 7.9 blue belts. Robos still have about twice the logistic power over belts. This can likely be further tweaked by getting the bot counts right.
- The buffer chests stayed very close to empty and never reached an equilibrium that I expected. I suspect that once a bot delivers to a buffer chest it has a very high chance of being told to pick it back up and finish the trip.

factorio long bus.jpg (1.11 MiB) Viewed 7563 times

It's important to note that in this test the item requesting power of the blue chests severely overwhelms the single roboport line's ability to move items. Because of that the buffer chests end up rarely used. I quickly repeated the test with only 4 requester chests demanding 2.4K ore. This limits the number of bots that can service the distance to 2400 bots/ 8000 total bots. At this point the buffer chests did their job admirably, activating the rest of the bots and allowing the system to operate at full motion. You can see there's a bit of a hiccup at the last mile. Tacking an extra robo or two at the end helps it smooth back out across the whole network and give the theoretical speeds yet again.

factorio short request.jpg (504.9 KiB) Viewed 7563 times

So TLDR:
The requester's logistic request capacity only determines the total number of bots that can service a request. It does not change the core item motion capability of roboports. If a requester chest can not summon enough bots to complete its path, more bots can be easily recruited by using buffer chests. The buffers will draw items in closer and allow the requester chest to not be limited by distance.

[vanatteveldt]

Good work

I think we should test with a single requester chest, and multiplying that will linearly multiply the amount of items transferred.
I would also think the buffers should be adjacent to the requester chest, since provider -> buffer is easy to scale, so you want to minimize the last mile of buffer -> requester, right?

Given infinite bots and roboports, I would predict a theoretical max throughput of [chest capacity=request size]/[travel time]. Buffer chests count for chest capacity, since the last mile is so few tiles it should not matter.

I'm not quite sure how to model the limit posed by the roboport charging and bot storage capacity?

Cargo size bonus should not help the first limit, but will lower the amount of needed bots and ports.

[bobucles]

I think we should test with a single requester chest,

The hardest part of this is emptying the chest fast enough to keep the requests flowing. I had to use 4 chests and 3 stack inserters each just to keep the requester empty, and it was barely enough to keep up. You will need a modded solution to void the requesters, which the creative mode mod has.

There will be some exacting formula that dermines how much flow rate a single requester chest is capable of. This is mostly limited by the chest's inventory capacity and item stack size. You can't request more than a full chest at a time, which is some number of bots, which travel at a certain speed to service that request. There's definitely a number to be dug out of there somewhere.

The maximum throughput of a requester chest isn't a major concern in base design. It starts off extremely high and increasing the limit is a trivial task. If the chest can't stay full, just use more blues or greens to increase the bot bandwidth. More bot speed will also do the trick. Pretty simple.

[Jap2.0]

I tried to get 4 blue belts worth of plates trabnsported with a 2k tiles long roboport-line having buffer chests every 25 ports. I only got around 3.5 blue belts out.
Buffer chests seem to be ignored by the bots if there are requester chests (that are also requesting from buffer chests) to serve. The implementation of buffer chests seem to be more suited for occasional delivery to the player in a cornucopia economy...

So at the current patchlevel i would suspect, that botted long-distance delivery is only feasible if the lines are separated into chunks somehow. But even if bot/buffer interaction gets improved, it does not look like a sane option to bring up at the next CFO meeting...

So long-distance bots seem to not to be superior above anything.

Bots are certainly superior for quick and lazy malls and low-throughput/high-ingredient-count stuff.
What are they also the superior logistiscs option for?

Good test!

Note that buffer chests never pull from buffer chests, so there is no advantage to having multiple buffers along the way. I think the way to get N times throughput would be

provider chest - 2k tiles of roboports - N buffer chests - requester chests

The requester will indeed be served first, but if there are enough robots and available items it should simulateneously fill the buffers. Then, the next request should come from the buffers, and since there are N buffers they should be able to request enough items to keep up the throughput. Did you check the 'request from buffer chests' in the requester?

But let's test it

I believe that buffers would probably be more useful for supplying the player and in a spread out area of production with varying consumptions.

[Oktokolo]

I believe that buffers would probably be more useful for supplying the player and in a spread out area of production with varying consumptions.

I believe, that that is what they where made for.

[Jap2.0]

I believe that buffers would probably be more useful for supplying the player and in a spread out area of production with varying consumptions.

I believe, that that is what they where made for.

Yeah - I was trying to point out that that was why they were misused in Bobucles' test.

[Oktokolo]

I believe that buffers would probably be more useful for supplying the player and in a spread out area of production with varying consumptions.

I believe, that that is what they where made for.

Yeah - I was trying to point out that that was why they were misused in Bobucles' test.

The entire long-range bot logistics thing is a misuse. The devs obviously planned the players to use rail for that. Bots look like they where designed as the UPS fix that they proved to be. They exhibit the least intelligent behaviour possible without going an extra mile to make them even dumber. They do not feature a collision system (but surprisingly they do queue up at robo ports and probably could do the same without too much a UPS hit at chests too) and always fly straight. They do not even anticipate the need for recharge wich would prevent them from "shortcutting" (and stranding without power while doing so) U-shaped layouts.

The discussion is about beyond end game use of bots and whether they are at that point better than belts for some or all use cases. I tested with regular research only, bobucles did infinite research to speed level 10 and used a much more optimized setup (i naively tried to let the bots sort it out themselves).
Naive logic dictates, that with the ability of endless improvements for bots where belts are at a standstill, bots indeed should prove to become better for any job, belts could also do - if you just throw enough research at it.
It currently looks like that is true.

[bobucles]

I was trying to point out that that was why they were misused in Bobucles' test.

Wait, you were? Yeah you'll have to explain that one. The buffer chests in my test worked exactly as they should. They brought items closer to the requester chests so that long distances wouldn't strangle requester throughput. I even explained why it worked as it did. Theory, practice, proven. There's not much to dispute.

Buffer chests can ALSO be used to support a player logistics system. Requester chests (such as a player) will attempt to pull items from the closest source, and buffers let you place those sources all over the base for easy access. It's simply a larger scale picture over the focused test I did.

You probably shouldn't build a thousand tile bus of bots, of course. But if you really wanted to do it, you could. The game makes it possible.

[Alice3173]

- The 19.0K/s production is equivalent to 7.9 blue belts. Robos still have about twice the logistic power over belts. This can likely be further tweaked by getting the bot counts right.

Yes but what is the power drain caused by the bots as well as the enormous resource sink to craft the roboports, logistics bots, and chests used? Having something so lategame taht's so expensive to build and keep running kinda offsets it being better than another item that serves the same basic function.

[bobucles]

Yes but what is the power drain caused by the bots as well as the enormous resource sink to craft the roboports, logistics bots, and chests used?

Let's see. 300 busy roboports, 4 bays, 1 MW recharge, pretty simple math. The live test hovered almost exactly at 1GW out of a theoretical max of 1200MW. It wasn't the most optimized setup for sure.

[mrvn]

Just answer this question: Can a requester chest request 1 million iron plates or will that get limited to the size of the chest?

That's getting into really strange, fringe situations. It is true that if the logistic chest doesn't ask for enough items or asks from too far away then the overall flow rate may not keep up, and thus the production stalls. But isn't this exact problem the reason why buffer chests (and perhaps building more than a single logistic chest because it isn't complete God mode) now exist? Is a finite logistic request queue even a real concern for most bases? How is paying the most basic of attention to base layout for a bot system any different than paying attention to the layout for a belt centric design?

Even so.

Show me just how far out of the way you have to set up a worst case scenario, such that the logistic system is somehow, SOMEHOW less than a belt's flow rate. (you can probably do this with artillery shells because surprise surprise, they don't allow logi bot cargo capacity)

Oh that would be simple. Artillery shells also have a stack size of 1. So if the chests are limited then only 48 bots will be tasked with filling the chest. A belt transports 13.3333 shells per second so at a distance where bots take 4 seconds to travel the belt will be faster. 4 seconds of bot travel in vanilla is what? 200m?

[mrvn]

I tried to get 4 blue belts worth of plates trabnsported with a 2k tiles long roboport-line having buffer chests every 25 ports. I only got around 3.5 blue belts out.
Buffer chests seem to be ignored by the bots if there are requester chests (that are also requesting from buffer chests) to serve. The implementation of buffer chests seem to be more suited for occasional delivery to the player in a cornucopia economy...

So at the current patchlevel i would suspect, that botted long-distance delivery is only feasible if the lines are separated into chunks somehow. But even if bot/buffer interaction gets improved, it does not look like a sane option to bring up at the next CFO meeting...

So long-distance bots seem to not to be superior above anything.

Bots are certainly superior for quick and lazy malls and low-throughput/high-ingredient-count stuff.
What are they also the superior logistiscs option for?

Thanks for testing this. Note that the throughput will be independent of the cargo capacity of bots. That only changes how many bots you need. If does depend on bot speed though.

Using multiple requester chests would increase throughput linear until you hit the limit of recharge speed. But that seems to be way above belt speed. Since you are testing a 4 belt setup using 4 requester chests would be fair and then the distance should be around 7000m before belts win again. Or buffer chests as suggested. Not sure how their mechanic works, never used them yet.


By the way. I think there is one thing we are overlooking. Provider chests need to be filled and requester chests need to be emptied. You can fit 4 stack inserters around a chest giving you ~100 items per second for something that stacks, right? 4 blue belts are 160 items per second. So 4 blue belts will always be faster than 1 requester chest. Or in other words: You need more than one requester chests.

[bobucles]

A belt transports 13.3333 shells per second so at a distance where bots take 4 seconds to travel the belt will be faster. 4 seconds of bot travel in vanilla is what? 200m?

Indeed artillery shells are the only thing in the game that makes a bot network weaker than belts. Congrats on breaking every single in game value possible to make it happen. Bots can NOT carry more than one shell at a time, so they lose 3/4 of their potency straight up. The logistic power of a roboport was only twice as good as belts, so after losing cargo capacity the ports will have half the logistic power compared to belts.

The slow transfer rate of a single chest can be trivially boosted with buffer chests. Every new buffer will activate up to 48 more bots to bring ammo closer to the destination. For my previous setup that amounts to about 170 buffer chests to activate the 8000 bots to cover 300 roboports of distance. Instead of 8 belts of transfer rate the loss of cargo capacity creates 2 blue belts of transfer rate. Tragic.

However.

Anything more than a shell per second is considered a HIGH transfer rate for artillery shells. The total sustained demand is only based on the expansion rate of nests, which is not very high at all. A single lane of yellow belt is more than enough ammo to keep a perimeter secure. Stocking a full blue belt of artillery shells is an absurd game stalling amount of ammo. Loading up a belt buffer of shells is a very expensive and a compressed belt represents a large initial investment. Bot transfer sends the ammo from start to finish very quickly and does not build up a large buffer of idle resources. This is especially important in the early artillery stages where players want to start using their guns as quickly as possible.

Even if the raw numbers don't favor them, the task of moving handful of artillery shells per second is definitely the "ideal bot situation" that players talk about. The demand is low and the need for a buffer is not that great. Why use belts and add a full layer of belt spaghetti? Bots may not be "the best" solution, but they are easy to set up and will work just fine.

[mrvn]

A belt transports 13.3333 shells per second so at a distance where bots take 4 seconds to travel the belt will be faster. 4 seconds of bot travel in vanilla is what? 200m?

Indeed artillery shells are the only thing in the game that makes a bot network weaker than belts. Congrats on breaking every single in game value possible to make it happen. Bots can NOT carry more than one shell at a time, so they lose 3/4 of their potency straight up. The logistic power of a roboport was only twice as good as belts, so after losing cargo capacity the ports will have half the logistic power compared to belts.

Wrong. The cargo capacity is irrelevant. Since shells do not stack 48 bots are activated. Would shells stack then only 12 bots would be activated. The throughput would be the same. Only the number of bots involved changes.

The slow transfer rate of a single chest can be trivially boosted with buffer chests. Every new buffer will activate up to 48 more bots to bring ammo closer to the destination. For my previous setup that amounts to about 170 buffer chests to activate the 8000 bots to cover 300 roboports of distance. Instead of 8 belts of transfer rate the loss of cargo capacity creates 2 blue belts of transfer rate. Tragic.

Aparently not so trivial since one person already failed above.

However.

Anything more than a shell per second is considered a HIGH transfer rate for artillery shells. The total sustained demand is only based on the expansion rate of nests, which is not very high at all. A single lane of yellow belt is more than enough ammo to keep a perimeter secure. Stocking a full blue belt of artillery shells is an absurd game stalling amount of ammo. Loading up a belt buffer of shells is a very expensive and a compressed belt represents a large initial investment. Bot transfer sends the ammo from start to finish very quickly and does not build up a large buffer of idle resources. This is especially important in the early artillery stages where players want to start using their guns as quickly as possible.

Even if the raw numbers don't favor them, the task of moving handful of artillery shells per second is definitely the "ideal bot situation" that players talk about. The demand is low and the need for a buffer is not that great. Why use belts and add a full layer of belt spaghetti? Bots may not be "the best" solution, but they are easy to set up and will work just fine.

Indeed. Bots are really good for low throughput, low buffer transport.

Although for artillery I would use the train instead. Just having one train going from station to station at 3m intervals should suffice to keep quite a large area free of nests.

[bobucles]

Wrong. The cargo capacity is irrelevant. Since shells do not stack 48 bots are activated. Would shells stack then only 12 bots would be activated. The throughput would be the same. Only the number of bots involved changes.

What? No. You're forgetting that two things are happening at once:

- Roboports are affected because cargo size is affected.
- Requester throughput is affected because total chest capacity is affected

Roboports have their efficiency cut by 75% because artillery bots only haul 1 shell at a time. That has a very tangible effect on the bot network's overall efficiency. Artillery requester chests can only summon 48 shells at a time, which amounts to 48 bots. That total transfer rate is very limited, but buffer chests still do their job of increasing the requester bandwidth. Requester bandwidth was never a big deal and even in this worst case scenario it is a small problem that is easily addressed.

Aparently not so trivial since one person already failed above.

Buffer chests are really easy to use when increasing requester bandwidth. Place a bunch of them around the blue chests. Bandwidth increased. Done.

Buffer chests don't work very well as a "half way" point because of chest priority. The bot network will prioritize filling blue chests directly if the green chests are empty. Green chests only get filled if there's bot capacity to spare, so they may stay permanently empty if the network is stressed.

[Jap2.0]

A belt transports 13.3333 shells per second so at a distance where bots take 4 seconds to travel the belt will be faster. 4 seconds of bot travel in vanilla is what? 200m?

Indeed artillery shells are the only thing in the game that makes a bot network weaker than belts. Congrats on breaking every single in game value possible to make it happen. Bots can NOT carry more than one shell at a time, so they lose 3/4 of their potency straight up. The logistic power of a roboport was only twice as good as belts, so after losing cargo capacity the ports will have half the logistic power compared to belts.

The slow transfer rate of a single chest can be trivially boosted with buffer chests. Every new buffer will activate up to 48 more bots to bring ammo closer to the destination. For my previous setup that amounts to about 170 buffer chests to activate the 8000 bots to cover 300 roboports of distance. Instead of 8 belts of transfer rate the loss of cargo capacity creates 2 blue belts of transfer rate. Tragic.

However.

Anything more than a shell per second is considered a HIGH transfer rate for artillery shells. The total sustained demand is only based on the expansion rate of nests, which is not very high at all. A single lane of yellow belt is more than enough ammo to keep a perimeter secure. Stocking a full blue belt of artillery shells is an absurd game stalling amount of ammo. Loading up a belt buffer of shells is a very expensive and a compressed belt represents a large initial investment. Bot transfer sends the ammo from start to finish very quickly and does not build up a large buffer of idle resources. This is especially important in the early artillery stages where players want to start using their guns as quickly as possible.

Even if the raw numbers don't favor them, the task of moving handful of artillery shells per second is definitely the "ideal bot situation" that players talk about. The demand is low and the need for a buffer is not that great. Why use belts and add a full layer of belt spaghetti? Bots may not be "the best" solution, but they are easy to set up and will work just fine.

Power armor mk. I and II, cars, tanks, blueprints, deconstruction planners, blueprint books, rocket silos, and nuclear fuel all have a stack size of one. (as well as possibly other items added by mods)

[bobucles]

Power armor mk. I and II, cars, tanks, blueprints, deconstruction planners, blueprint books, rocket silos, and nuclear fuel all have a stack size of one.

Cool story bro. What's your point? The entire necessary throughput for all those items PUT TOGETHER is still lower than the throughput of a burner inserter chain WITH fuel. How many bots will it take to service all those needs? 5? 10? Extremely low throughput favors the bot network over belt spaghetti.

If you want to prove me wrong by loading a sushi belt with armor, cars, tanks, blueprints, etc just to prove it's more effective than using bots. Uh. Everyone needs a hobby I guess.

[Jap2.0]

Indeed artillery shells are the only thing in the game that makes a bot network weaker than belts.

Power armor mk. I and II, cars, tanks, blueprints, deconstruction planners, blueprint books, rocket silos, and nuclear fuel all have a stack size of one. (as well as possibly other items added by mods)

What's your point?

[McDuff]

That's a bit pedantic isn't it mate?

Surely the point is that there are some things that need to be moved in bulk and some things that don't. If it's got a stack size of one, it probably doesn't need to be moved in bulk, and therefore "throughput" is somewhat meaningless.