So... Let's talk about bots, and how to fix them properly...
Re: So... Let's talk about bots, and how to fix them properly...
I would shudder to leave "fixing bots" in the hands of people who don't even know how to actually optimize them with active providers (that's the only explanation I have as to why someone came up with the buffer chest).
That "throughput comparison" where they compared "X tiles of bots to X tiles of belt" was hysterical.
Obviously, to be effective without needing tens of thousands of them in the first place, bots need their input in the smallest production area possible, which you achieve with either trains or belts so combining them is already the most efficient option.
You can't have an entire megabase with bots alone already, they become h.o.r.r.i.b.l.y inefficient if you stretch the network over the entire map so scrambling to come up with something to create "parity" because they are "OP" is just puzzling.
That "throughput comparison" where they compared "X tiles of bots to X tiles of belt" was hysterical.
Obviously, to be effective without needing tens of thousands of them in the first place, bots need their input in the smallest production area possible, which you achieve with either trains or belts so combining them is already the most efficient option.
You can't have an entire megabase with bots alone already, they become h.o.r.r.i.b.l.y inefficient if you stretch the network over the entire map so scrambling to come up with something to create "parity" because they are "OP" is just puzzling.
Re: So... Let's talk about bots, and how to fix them properly...
Hey! Don't diss it if you don't get it. This is very important math that gets directly to the heart of the problem. If you understand the process that ultimately describes why bots move more than belts, you can also understand how to buff or nerf them completely at will.That "throughput comparison" where they compared "X tiles of bots to X tiles of belt" was hysterical.
So.
Moving items from Point A to Point B is the most basic logistic challenge in the game. Satisfying this challenge means building things that generate a "logistic force" I.E. the ability to move items. Moving items a longer distance takes more "logistic power", and moving more items ALSO takes more "logistic power". You can not simply move a lot of items a short distance and accomplish something, and similarly you can not move one item across the world and have a successful base. You need both factors working together, or nothing happens.
Some items have blatantly more ability to move items than others. For example a blue belt very clearly moves items better than a yellow belt. Let's start with a tile of land that can be either a yellow belt or a blue belt. Choosing the blue belt lets us move more items in a superior way vs. picking the yellow belt. So the end result is that blue belts have more logistic power than yellow belts. In addition to having more power they make more efficient use of land space than yellow belts. Simple enough?
With a little bit of math we can turn those ideas into hard, measurable metrics. In this case the most relevant metric is defined as moving X number of items across one tile, per second I.E. (Item*distance / sec). A single blue belt moves 40 items across 1 tile every second. Five blue belts move 200 items across 1 tile every second. Alternatively they move 40 items 5 tiles every second. In either case 5 belts represent 200 "logistic power" and in every situation it provides "40 logistic power per tile". (This math also helps us understand trains, since we know that they move "a lot of items, very fast" and thus they have enormous logistic power.) Try to keep up, this is going somewhere.
Roboports do not have any obvious metric of "logistic power". Without some way to equate them to belts we have no real way to know if I can move more items with a solid block of roboports vs. a solid block of belts. There's always the real world tests but everything that happens in the game is done by a computer doing simple math. We must be able to find a comparison that uses simple math, right? Fortunately a simple comparison is possible.
Robots move items. Robots consume a fixed amount of energy for every tile they move an item. Roboports also have a fixed amount of recharge rate that they can impart into bots. Think about that. If a robot takes 5kJ to move an item across one tile, and a tiny charging station recharges at 20kJ/sec, then we have the ability to keep our robots moving items across 4 tiles every second. Does "moving X items across 1 tile every second" sound familiar? It's the same metric we're using for belts! Now we have a way of establishing a Roboport's logistic power and directly compare them to belts. The raw, frictionless sphere equation is a very straight forward understanding of energy cost and energy recharge:
Code: Select all
Roboport Logistic Power == (Recharge rate / energy consumed per tile)
 Twice the cargo means twice the item movement, thus twice the logistic power. Cargo size multiplies the system's total logistic power.
 If a bot carries an item from point A to point B, it must return to point A empty handed to do the trip again. This type of bot is only working half the time, thus it's wasting half of its potential logistic power. The bot pathing only does useful work some percentage of their time.
 Bots have a second energy drain of 3kJ per second. Take a bot moving across 10 tiles, consuming a base of 50kJ. If a very slow bot takes 10 seconds to move the distance then it's burning an extra 30kJ, totaling 80kJ of demand. If the bot teleports instantly then it doesn't burn any extra energy at all, using the base 50kJ. Bots have a speed factor where a percentage of energy isn't being spent on movement. Lower efficiency costs logistic power.
 Roboports don't have perfect 4MW recharge. Bots take time to latch to the station and slower bots take longer to advance the queue. In the end we have a percentage efficiency of the roboport's recharge stations where 100% efficiency gives full logistic power.
All these factors are easy to understand on their own and real values can be discovered through in game testing. The total equation multiplies together in a very simple way to give a complete formula of roboport logistic power:
Code: Select all
Roboport Logistic Power(improved) == (Recharge rate / energy consumed per tile) * (Cargo size) * (Pathing efficiency%) * (Recharge efficiency%) * (speed efficiency%)
Code: Select all
(4000kW / 5 kJ/tile) * 4 cargo * 50% pathing * 90%+ recharge * 90%+ time efficiency
Now we apply the final step. Every tool we have to "move items across a distance" takes up real space in the game world. This space is in the form of square tiles. A single Roboport fills up 16 tiles. This real estate could have been used for 16 blue belts instead. If we tore down the roboport and used those 16 blue belts instead we'd be able to move 640 items across 1 tile, every second. Thus 16 belts have 640 logistic power.
We now have matching metrics and took all the major factors into account. Let's directly compare these two options. The single roboport gives 1300 logistic power. Replacing it with 16 blue belts will give 640 logistic power. We can prove (in this situation) that when you use Roboports to simply move items in a straight line, they are flat out more powerful than belts. We even have the math to back it up.
Last edited by bobucles on Wed Mar 21, 2018 8:21 pm, edited 2 times in total.
Re: So... Let's talk about bots, and how to fix them properly...
Like I said, the logistic power of bots isn't constant, it becomes exponentially less effective the larger the area they have to cover for a variety of reasons, which is a problem belts don't have.
That's why comparing "x tiles of belt" to "x tiles of robots" is silly.
You don't build bots the way you build belts.
That's why comparing "x tiles of belt" to "x tiles of robots" is silly.
You don't build bots the way you build belts.
Re: So... Let's talk about bots, and how to fix them properly...
But a larger area ALSO needs more belts. Moving 40 items a long distance takes a LOT more belts than moving 40 items a short distance for the exact same reason it takes more roboports. That reason is because you are moving X items over Y distance per Z time. That's the magic "logistic power" number I keep talking about. More items need more power. More distance needs more power. Doing it all in less time needs more power. More power equates to building more roboports and longer:wider belts. Longer belts may not seem like it's more logistically expensive but it still counts.dood wrote:Like I said, the logistic power of bots isn't constant, it becomes exponentially less effective the larger the area they have to cover for a variety of reasons, which is a problem belts don't have.
That's why comparing "x tiles of belt" to "x tiles of robots" is silly.
You don't build bots the way you build belts.
It's still a fair apples to apples comparison.
A few geometric things that I didn't discuss also happen, such as belts only move in straight X or Y lines while bots can shortcut a diagonal, or roboports don't need to be placed in a chain and surrounding roboports can support item motion. Those two factors only tilt the value even more in favor of bots.
Last edited by bobucles on Wed Mar 21, 2018 3:58 pm, edited 1 time in total.
Re: So... Let's talk about bots, and how to fix them properly...
Like I said. Again.
One is constant, the other is exponential.
How is that apples to apples?
One is constant, the other is exponential.
How is that apples to apples?
Re: So... Let's talk about bots, and how to fix them properly...
First, reread my post. Then take some time to study it. You'll realize that when a bot network grows, the only requirements that change are (number of items to move), the (distance to move those items), and the (timeframe used to measure it). I'll give you a hint. I already defined that value. It begins with an L and ends with an R.Like I said. Again.
One is constant, the other is exponential.
How is that apples to apples?
When a belt network grows, the exact same growth of complexity happens. The (number of items) grows. The (distance to move items) grows. The (timeframe of reference) is whatever you want to be. Days, minutes, seconds. You need a vastly increased number of belts to move more items and to move them more distance. This is fundamentally no different than needing more roboports to do the same thing.
Logistic power is just a measurement that combines throughput and distance. Its only purpose is to give a common ground to compare the indirect throughput of a roboport vs. the direct throughput of a belt. That's literally all it is.
Re: So... Let's talk about bots, and how to fix them properly...
No it doesn't because it's linear.bobucles wrote:When a belt network grows, the exact same growth of complexity happens.
You can't focus your 1 tile wide beltline to move things between 2 tiles especially fast. It'll always be 40 items a second over its entire length.
You can absolutely focus the entire bot network to instantly empty a chest and fill the chest right next to it.
Re: So... Let's talk about bots, and how to fix them properly...
Bots do have a frontloaded ability to move items and then collect on charging stations. I'm not accounting for that because you can't keep a base going on a burst of bots. They'll simply pile on the roboports, reach capacity and then you have to wait for more bots to charge before more items can move. That is the ultimate limit of the roboports and is the true, sustained display of their Logistic Power. My discussion only concerns sustained throughput (I.E. more than 10 minutes), which is a function of item count, distance and time. I feel like the process to understand it has already been thoroughly explained.
Once again the roboport's unique ability to move lots of items in a frontloaded burst gives them favor over belts. A train can unload itself, the bots go nuts, and they can charge during the downtime while a new train moves in. Belts can not front load their item movement, and empty belt slots squander their potential for moving items.
Once again the roboport's unique ability to move lots of items in a frontloaded burst gives them favor over belts. A train can unload itself, the bots go nuts, and they can charge during the downtime while a new train moves in. Belts can not front load their item movement, and empty belt slots squander their potential for moving items.
We'll just have to agree to disagree. Moving an item 1 tile is different from moving an item 10 tiles and long belts take up more space than short belts. If you can't work with that and see how it ties into the full picture then there's nothing more I can do.It'll always be 40 items a second over its entire length.
Re: So... Let's talk about bots, and how to fix them properly...
You can however make it as compact as possible. Which has a profound effect on the throughput of bots.bobucles wrote:Bots do have a frontloaded ability to move items and then collect on charging stations. I'm not accounting for that because you can't keep a base going on a burst of bots.
Yes that also goes for sustained usage, obviously, and by the by, that burst logistic thing is yet another reason why directly comparing x tiles of belts to x tiles of "bots" is silly.
Belts can't be diluted nor compressed nor can they burst.
Out of everything, you chose to disagree that a blue beltline will always have a throughput of 40 items a second?bobucles wrote:We'll just have to agree to disagree. Moving an item 1 tile is different from moving an item 10 tiles and long belts take up more space than short belts. If you can't work with that and see how it ties into the full picture then there's nothing more I can do.It'll always be 40 items a second over its entire length.
What even is this.

 Filter Inserter
 Posts: 939
 Joined: Sat May 23, 2015 12:10 pm
 Contact:
Re: So... Let's talk about bots, and how to fix them properly...
But you can use those numbers to calculate the cost of the bots vs. the cost of the belts.dood wrote:You can however make it as compact as possible. Which has a profound effect on the throughput of bots.bobucles wrote:Bots do have a frontloaded ability to move items and then collect on charging stations. I'm not accounting for that because you can't keep a base going on a burst of bots.
Yes that also goes for sustained usage, obviously, and by the by, that burst logistic thing is yet another reason why directly comparing x tiles of belts to x tiles of "bots" is silly.
Belts can't be diluted nor compressed nor can they burst.
Out of everything, you chose to disagree that a blue beltline will always have a throughput of 40 items a second?bobucles wrote:We'll just have to agree to disagree. Moving an item 1 tile is different from moving an item 10 tiles and long belts take up more space than short belts. If you can't work with that and see how it ties into the full picture then there's nothing more I can do.It'll always be 40 items a second over its entire length.
What even is this.
To transport n items / second over a distance of x with bots you need n*x*constant roboports and n*x*constant robots
To transport n items / second over a distance of x with belts you need n/40 lanes over a distance of x (== n*x*constant belts) + a buffer on the input to manage bursty input + balancer
Once you know the constants you can apples to apples compare the raw resources needed to build the logistics required to achieve that throughput.
Re: So... Let's talk about bots, and how to fix them properly...
ratchetfreak wrote:apples to apples
Re: So... Let's talk about bots, and how to fix them properly...
A cost comparison isn't that simple. Faster bots get jobs done in less time, burn energy faster and thus need more roboport time. Bots that demand more roboport time will max out the roboports and thus saturate the network faster. So when bot research and speed goes up, the number of bots needed to saturate the network goes down. We can see that in action with a simple bot base. As bot speed increases, the max number of bots needed to work the bot base go down and thus the setup becomes cheaper.But you can use those numbers to calculate the cost of the bots vs. the cost of the belts.
To transport n items / second over a distance of x with bots you need n*x*constant roboports and n*x*constant robots
The cost of belts vs. bots mostly controls the tech progression for players, but it doesn't really change where players end up. Players will seek out the best option that they can afford. They can afford different things at different stages of the game. In the post game players will simply build the best, no matter what it costs.
Tech progression is easily observed in any average player's game. Yellow belts are an obvious first grab because they're effective and super cheap. Red belts are a reasonable upgrade at a reasonable price and even find their way into speed runs. Blue belts are a big leap up in cost and a full system upgrade is pretty costly. You can probably ignore them before the first rocket. A handful of bots is fairly cheap and can save a lot of belt spaghetti for odd recipes that don't really saturate belts. The convenience is worth it for some players. High end bot research easily surpasses the cost of blue belts, and super bot bases don't really warm up until deep into this research.
Bots definitely end up more expensive than belts in a major way because of unlimited research. So should bots be superior because they're more expensive? That's a matter of hotly debated opinions. But keep in mind that the later stages of bot speed don't change a robot nework's sustained throughput THAT much. The reason is spelled out in the roboport's logistic power equation:
Code: Select all
Roboport Logistic Power(improved) == (Recharge rate / energy consumed per tile) * (Cargo size) * (Pathing efficiency%) * (Recharge efficiency%) * (speed efficiency%)

 Filter Inserter
 Posts: 939
 Joined: Sat May 23, 2015 12:10 pm
 Contact:
Re: So... Let's talk about bots, and how to fix them properly...
Eh, no Bots scale linearly to the distance,dood wrote:https://i.imgur.com/1cvE9sU.jpratchetfreak wrote:apples to apples
A bot's travel time is linear with the distance, So to have the same throughput over twice the distance you need twice as many bots (and twice as many robotports). You need to adjust the requesters to make sure bots are always getting dispatched but that is independent from number of bots.
Re: So... Let's talk about bots, and how to fix them properly...
Check your math dood. You are confusing the width of a bus with the total amount of belts needed. A two lane bus reaching 10 tiles needs 20 belt items. You need to address the total number of belts being used or the comparison is not apples to apples.img
Re: So... Let's talk about bots, and how to fix them properly...
Okay.ratchetfreak wrote:Eh, no Bots scale linearly to the distance,dood wrote:https://i.imgur.com/1cvE9sU.jpratchetfreak wrote:apples to apples
A bot's travel time is linear with the distance, So to have the same throughput over twice the distance you need twice as many bots (and twice as many robotports). You need to adjust the requesters to make sure bots are always getting dispatched but that is independent from number of bots.
But you can then, after doubling your bots and ports, half the distance for twice the throughput and that's something belts can't do.
Correct?

 Filter Inserter
 Posts: 939
 Joined: Sat May 23, 2015 12:10 pm
 Contact:
Re: So... Let's talk about bots, and how to fix them properly...
no becasue if you put the 2 sections of belt next to each other you have double the throughputdood wrote: Okay.
But you can then, after doubling your bots and ports, half the distance for twice the throughput and that's something belts can't do.
Correct?
Re: So... Let's talk about bots, and how to fix them properly...
What.ratchetfreak wrote:no becasue if you put the 2 sections of belt next to each other you have double the throughputdood wrote: Okay.
But you can then, after doubling your bots and ports, half the distance for twice the throughput and that's something belts can't do.
Correct?
Re: So... Let's talk about bots, and how to fix them properly...
Uh. You mean like this?You can't cut belt distance in half to double the throughput
Re: So... Let's talk about bots, and how to fix them properly...
If you have a
4 belt bus, okay?
You have a 4 BELT BUS, OKAY?
That's 160 items per seconds, yes? 160 items per second is the throughput on this 4 belt bus, understand?
That bus is 100 tiles long, you got that? 4 belt bus, 100 tiles long, 160 items per second throughput. You with me so far?
Now at 50 tiles, you cut the distance of that 100 tile bus in half and look at the throughput at 50 tiles.
You only use half of your 4 belt bus, okay? What's the throughput you get?
What is it?
160 items per second.
Same as with any length of it. Amazing.
Now you have a bot network that transports the same 160 items over 100 tiles.
And now you place the requesters and providers not 100 but 50 tiles apart from each other within the network. What happens?
Is it still 160 items per second?
4 belt bus, okay?
You have a 4 BELT BUS, OKAY?
That's 160 items per seconds, yes? 160 items per second is the throughput on this 4 belt bus, understand?
That bus is 100 tiles long, you got that? 4 belt bus, 100 tiles long, 160 items per second throughput. You with me so far?
Now at 50 tiles, you cut the distance of that 100 tile bus in half and look at the throughput at 50 tiles.
You only use half of your 4 belt bus, okay? What's the throughput you get?
What is it?
160 items per second.
Same as with any length of it. Amazing.
Now you have a bot network that transports the same 160 items over 100 tiles.
And now you place the requesters and providers not 100 but 50 tiles apart from each other within the network. What happens?
Is it still 160 items per second?

 Filter Inserter
 Posts: 939
 Joined: Sat May 23, 2015 12:10 pm
 Contact:
Re: So... Let's talk about bots, and how to fix them properly...
That's 160 items per seconds, yes? 160 items per second is the throughput on this 4 belt bus, understand?dood wrote:If you have a
4 belt bus, okay?
You have a 4 BELT BUS, OKAY?
That's 160 items per seconds, yes? 160 items per second is the throughput on this 4 belt bus, understand?
That bus is 100 tiles long, you got that? 4 belt bus, 100 tiles long, 160 items per second throughput. You with me so far?
Now at 50 tiles, you cut the distance of that 100 tile bus in half and look at the throughput at 50 tiles.
You only use half of your 4 belt bus, okay? What's the throughput you get?
What is it?
160 items per second.
Same as with any length of it. Amazing.
Now you have a bot network that transports the same 160 items over 100 tiles.
And now you place the requesters and providers not 100 but 50 tiles apart from each other within the network. What happens?
Is it still 160 items per second?
That bus is 100 tiles long, you got that? 4 belt bus, 100 tiles long, 160 items per second throughput. You with me so far?
Now at 50 tiles, you cut the distance of that 100 tile bus in half and put the belts you don't use anymore next to the part still being used and look at the throughput at 50 tiles.
now you have a 8 belt bus
320 items per second
Who is online
Users browsing this forum: No registered users