Friday Facts #225 - Bots versus belts (part 2)
Idea to nerf bots - make them take up space
Bots today don't have physicality - they can infinitely overlap, with each other and with other game objects. A pretty intuitive and visually-interesting nerf would be to change that. Make bots get in each other's way. If there are a bunch of bots going in the same place, make them cluster and block each other. The more bots you have, the worse it would be - it feels like a pretty natural balancing.
From a code perspective, it would probably be a PITA; you'd have to figure out how to make bots do something reasonable and/or interesting when they block each other. On the other hand, it might open up interesting mods, that try different path algorithms or other logic to cope with bot clusters in interesting ways.
From a code perspective, it would probably be a PITA; you'd have to figure out how to make bots do something reasonable and/or interesting when they block each other. On the other hand, it might open up interesting mods, that try different path algorithms or other logic to cope with bot clusters in interesting ways.
@Kovarex, #BeltBuffs #OutputFilter
You wrote:
"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."
If the filtered items on the side do not get used by the factory at the moment, and the splitter is filled with these items and there are a few of these items on the belt on the incoming side of the splitter, this would effectively block the incoming belt and the belt on the side with the rest of the items, as the splitter stops taking items from the incoming side until it can put the filtered items on the side with the filtered items.
Is this true? Is this intended? This would be very different from a filter inserter setup, you are comparing it with.
The equivalent to the filter inserter setup would be, that excess filtered items, which can not be put on the filtered side, will be put on the unfiltered side and the incoming belt and the unfiltered side will not be blocked.
"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."
If the filtered items on the side do not get used by the factory at the moment, and the splitter is filled with these items and there are a few of these items on the belt on the incoming side of the splitter, this would effectively block the incoming belt and the belt on the side with the rest of the items, as the splitter stops taking items from the incoming side until it can put the filtered items on the side with the filtered items.
Is this true? Is this intended? This would be very different from a filter inserter setup, you are comparing it with.
The equivalent to the filter inserter setup would be, that excess filtered items, which can not be put on the filtered side, will be put on the unfiltered side and the incoming belt and the unfiltered side will not be blocked.
Last edited by Impatient on Thu Jan 18, 2018 4:01 am, edited 6 times in total.
Re: Friday Facts #225 - Bots versus belts (part 2)
+5 repZarylo wrote: I have read some players stating that bots are an integral part of factorio.
They are not.
Neither are belts or trains.
Inserters are integral. You can use inserters as your sole transportation method.
And you can't use belts, bots or trains without them.
Last edited by Impatient on Thu Jan 18, 2018 4:00 am, edited 2 times in total.
Re: Friday Facts #225 - Bots versus belts (part 2)
No. You literally cannot calculate "how many bots it would take" to replace belts for their base; you do not have the information required to do so (unless Nomadic Steppe has sent you their save file?). In order to determine an equivalent, you'd have to know the physical locations of all the machines in their base, from the trains through to the rocket, and the width of any set of belts connecting any given pair of input and output inserters.vampiricdust wrote:Because I love calculating costs....
It would take about 32,000 bots with capacity 4 & 187% speed to move the same number of items ideally. It would probably be more due to having to fly around, but with that many you would need 320 roboports, 1.28 GW of addition power, and all of the nessecary chests to load/unload. Just bots & roboports is about 6.5 million resources. You used 927k for your belts, which is ~14% of the resource costs ignoring the chests & extra power production.Nomadic Steppe wrote: For example, this part of my base only creates white science and they have 18,000 bluebelts inside.
That is about 83,555 bots with above researched with about 835 roboports. So that's just shy of 16 million resources.Nomadic Steppe wrote: the core of my base has forty-seven thousand (47,000), these numbers are insane, and that does not include mineral extraction zones.
I didn't multiply out the bots to take flying to charge & flying back to the starting point mainly because the base probably could have been built smaller overall, reducing flight times, but my general point stands. Belts cost less than 20% of what logistics bots do, but according to Kovarex, they are only 2 to 5 times better. So yeah, unless you can build the same production levels and get the cost ratio below 3x what the cost of the belt base is, your base is better resource for resource.
With that information, you could then determine the available item-throughput between inputs/outputs, as well as the distance over which the throughput is sustained, and from that you could calculate the amount of bots required.
Even then, the comparison would be apples-to-oranges, for two reasons:
- A base designed for bot usage wouldn't have its machines spaced anywhere near as far apart, so the input/output distance metrics would be invalid.
- You'd need to take into account bot charging requirements.
- This would be a comparison against the available throughput of the belt-links rather than the maximum consumed throughput any given belt-link could use given the requirements of its machine(s). Of course, if the factory section is designed to exactly consume its input throughput, the two will be equal, but otherwise it's almost certain that the available throughput will be either more or less than the maximum consumed throughput.
- vampiricdust
- Filter Inserter
- Posts: 317
- Joined: Wed Jan 14, 2015 1:31 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
Did you even read what I wrote? I was comparing belt to bot capacity and specifically stated that it was tough to guess being the base could be smaller so I didnt double the bots to make the back trip and charge time. I do cost comparisons and because Kovarex used a biased short straight shot, figured I would assume all the belts were straight shots as well. I even stated that making the base smaller would make it less.
That is also why I didnt include costs for chests or additional power generation. I have tried to be rather conservative in my cost analysis to be fair to the size difference.
That is also why I didnt include costs for chests or additional power generation. I have tried to be rather conservative in my cost analysis to be fair to the size difference.
-
- Manual Inserter
- Posts: 1
- Joined: Thu Jan 18, 2018 6:03 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
I agree with the idea that many other posters had of introducing a loading/unloading time and making it so a limited number of bots can access a chest at a time. However, I think that alone would be too much of a nerf without something else to compliment it. The best Idea I can come up with off the top of my head is making either bot capacity an infinite research, or making a new simultaneous access research that increases the number of bots that can access a chest at a time. That would keep bots as a late game improvement over belts but makes them take a while to get to the point of being overpowered instead of just instantly being better the moment you have them researched and automated.
I also like the idea of increasing the charging time, but maybe it would be better to also increase the battery capacity and make it an exponential increase in charging time the longer bots go without charging, meaning bots carrying items long distance have a large increase in charging time but for quick trips out of a personal roboport there wouldn't be much of a difference.
a couple more ridiculous ideas:
I also like the idea of increasing the charging time, but maybe it would be better to also increase the battery capacity and make it an exponential increase in charging time the longer bots go without charging, meaning bots carrying items long distance have a large increase in charging time but for quick trips out of a personal roboport there wouldn't be much of a difference.
a couple more ridiculous ideas:
- make bots require a full recharge regardless of distance traveled, making them better suited for larger scale tasks than small production areas
increase the complexity of setting up bot networks, like needing to actually wire together chests or wire them to the roboports in order to let the bots access them
introduce some kind of belt rack letting players run multiple lines of belts over the same tiles
Re: Friday Facts #225 - Bots versus belts (part 2)
I agree to almost everything you said.csdt wrote:That's funny and sad how several pages of interesting discussion that was getting somewhere were completely wiped out by new people on this topic who didn't read and/or didn't even consider that previous posts would already have interesting ideas.
This is an endless cycle, and this is probably not the first time that this topic loops, shamefully.
Knowing that, I really hope that devs will read every single post of this topic (good luck to them, by friday we will probably reach 1000+ posts).
Any resource consideration is "broken": making the cost of bots higher will not solve the balance problem, unless their cost is insanely high, at that point, we would just have killed all the fun of the bots.
Overlapping belts will probably never come as it would be inherently difficult to visually understand what is happening (and it would be difficult to program).
Introducing weights for bots is a bad idea: why bots should even consider item weights when all the rest of the game doesn't mind.
The player is able to carry hundreds of nuclear reactors, let's be it! Why bots should be different?
From the previous posts, we could argue that bots and belts aren't/shouldn't be for the same purpose:
- Trains: High throughput over long distances
- Belts: High throughput over short/medium distances
- Bots: Low throughput over short/medium distances (much simpler to use for complex recipes with lots of ingredients)
For that, 2 possibilities:
- nerf bots for high throughput (cooldown on chests, or limited bot density)
- buff belts for higher throughput (pallets/crates/packing: this should be done properly, not like in those mods that tried that)
Other possibilities not achieving this kind of balance:
- Make bots more fun (new building strategy keeps being fun): manual path scheduling of bots like trains
- Make belts more fun (prefer old strategy to keep having fun): fix all the little problems of belts (like belt compressing), belt planner
- spatially bigger logistic chests (like 2x2): reduce the machine density difference between belt-based factories and bot-based factories
Simple, they are off-topic: While they need to be fixed, they doesn't interact with bots vs belts balancing.bobingabout wrote:Everyone is talking about Bots and Belts... what about Pipes?
They deserve their own topic.
The chosen set of solutions should be simple to understand and intuitive to use while not being arbitrary.
As for now, I leave this topic and hope the cycle will not loop too many times.
I just don't see why any low throughput option should be of interest. If the player orders 1000 belts, I want to see high throughput. Or are we talking about placeable items like splitters? Such items tend to need low throughput in average. But the peak throughput is often also very high.
Generally speaking... If you don't need high throughput in factorio, you need very high throughput.
The throughput limiting factor is inserter speed.
Hence, I would characterize the purpose of the different logistics solutions as short, mid, long range for bots, belts, trains, respectively.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
that's one of the things I've considered with my mods a lot... do I double it every time, or just have the new item as a multiple of what tier it is multiplied by the base value? Some things I even do +half of the base value per tier. (so MK3 is double).XDbored wrote:my suggestion for the re-balance would be to adjust belt speed so throughput is increased from
13.333
26.666
40.0
to instead be
20
40
80
Anyway, your 20, 40, 80 values are insane speeds, Personally if I were to transition from a 1:2:3 ratio to a 1:2:4 ratio, I'd probably keep the final result the same, resulting in 10, 20, 40. I've seen other people recommend 15, 30, 60, but that also means that the blue belts are 50% faster than they are now.
Not that faster top tier belts is a bad thing, but you would need to adjust inserters to be able to grab items from these faster belts too.
My mod adds belts of speed 53.3 and 66.6. That's right, your suggested 3rd tier base game belt is faster than my 5th tier belt
Last edited by bobingabout on Thu Jan 18, 2018 12:33 pm, edited 2 times in total.
Re: Friday Facts #225 - Bots versus belts (part 2)
By low throughput, I target those items with complex recipes, but you usually don't need many of them, like nuclear reactors, energy shields, tanks, or even satellites.Bauer wrote:I just don't see why any low throughput option should be of interest. If the player orders 1000 belts, I want to see high throughput. Or are we talking about placeable items like splitters? Such items tend to need low throughput in average. But the peak throughput is often also very high.
Generally speaking... If you don't need high throughput in factorio, you need very high throughput.
The throughput limiting factor is inserter speed.
Hence, I would characterize the purpose of the different logistics solutions as short, mid, long range for bots, belts, trains, respectively.
I would say that belt processing needs high throughput.
Last edited by csdt on Thu Jan 18, 2018 10:07 am, edited 1 time in total.
- Deadly-Bagel
- Smart Inserter
- Posts: 1498
- Joined: Wed Jul 13, 2016 10:12 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
I found your 5th tier belt a bit overkill and difficult to utilise, mainly due to how many Inserters (even Express Inserters) would be required to utilise it all. It would work for a main bus but I had a rail-connected factory. That being said, nothing in Bob's Mods is really required in the same quantities as Iron and Copper is needed in vanilla so perhaps it isn't a good comparison.bobingabout wrote:Not that faster top tier belts is a bad thing, but you would need to adjust inserters to be able to grab items from these faster belts too.
My mod adds belts of speed 53.3 and 66.6. That's right, your suggested 3rd tier base game belt is almost as fast as my 5th tier belt
Money might be the root of all evil, but ignorance is the heart.
Re: Friday Facts #225 - Bots versus belts (part 2)
Who would go through the trouble of setting up a bot logistics network including the research to automate building a tank.csdt wrote:By low throughput, I target those items with complex recipes, but you usually don't many of them, like nuclear reactors, energy shields, tanks, or even satellites.Bauer wrote:I just don't see why any low throughput option should be of interest. If the player orders 1000 belts, I want to see high throughput. Or are we talking about placeable items like splitters? Such items tend to need low throughput in average. But the peak throughput is often also very high.
Generally speaking... If you don't need high throughput in factorio, you need very high throughput.
The throughput limiting factor is inserter speed.
Hence, I would characterize the purpose of the different logistics solutions as short, mid, long range for bots, belts, trains, respectively.
I would say that belt processing needs high throughput.
??
Re: Friday Facts #225 - Bots versus belts (part 2)
It was just an example, but I think on multiplayer, one could autocraft tanks for new comers, my other examples might be more relevant.Bauer wrote:Who would go through the trouble of setting up a bot logistics network including the research to automate building a tank.
??
EDIT:
But that's also the point of bots, setting up such an autocraft is trivial with bots and requires only 1 assembling machine, 1 reqester chest and 1 inserter, configure the chest and done. literally 10 secs.
Bots vs Belts - a simple solution
Humbly suggest you are focused on the wrong issue. Look at actual factories: the belt is not only a means of transport, it is also a queue or inventory. Bots are a transport and not an inventory (well not much of one without a very large number of bots). With bots you can't really control the number of bots assigned to a particular resource which would be required for optimization. And in actual factories which are adopting delivery bots, they are constrained both in terms of what the bot can carry, the efficiency (the electrical cost is larger than a belt per unit transferred) and the swim lane required for the bot to traverse.
Mirroring these things in game mechanics will likely add tedium, but there is a simpler solution. Bots are incredibly powerful because you've negated the advantage of belts as a queue through the use of chests. All you need to do, I think, is to place large limits on what a chest (or inventory point if you'd rather) can hold, as well as add delays for enqueuing and dequeuing to a chest, which can be expanded but at the expense of real estate, power, etc. Now bots are much more limited because they can't fill up a chest to 2.4k items, but 4 or 8 or some small number, which will limit the throughput of attached assemblers, etc. Having instead a belt acting as the queue means the assembler can run at full throughput (presuming the belt is fast enough).
If you want more accuracy, rather than item weight use item volume. I always wondered why the player can carry so many assemblers in their backpack too, perhaps a hand truck should be added and some items can only be carried one at a time using tools. It would also give some motivation to actually use a car to pick up items and deliver them, requiring large lanes between machines to allow the car to pass.
Best regards,
Mirroring these things in game mechanics will likely add tedium, but there is a simpler solution. Bots are incredibly powerful because you've negated the advantage of belts as a queue through the use of chests. All you need to do, I think, is to place large limits on what a chest (or inventory point if you'd rather) can hold, as well as add delays for enqueuing and dequeuing to a chest, which can be expanded but at the expense of real estate, power, etc. Now bots are much more limited because they can't fill up a chest to 2.4k items, but 4 or 8 or some small number, which will limit the throughput of attached assemblers, etc. Having instead a belt acting as the queue means the assembler can run at full throughput (presuming the belt is fast enough).
If you want more accuracy, rather than item weight use item volume. I always wondered why the player can carry so many assemblers in their backpack too, perhaps a hand truck should be added and some items can only be carried one at a time using tools. It would also give some motivation to actually use a car to pick up items and deliver them, requiring large lanes between machines to allow the car to pass.
Best regards,
Re: Friday Facts #225 - Bots versus belts (part 2)
While gererally ok-ish this is not easily implemented currently.bobingabout wrote:that's what of the things I've considered with my mods a lot... do I double it every time, or just have the new item as a multiple of what tier it is multiplied by the base value? Some things I even do +half of the base value per tier. (so MK3 is double).XDbored wrote:my suggestion for the re-balance would be to adjust belt speed so throughput is increased from
13.333
26.666
40.0
to instead be
20
40
80
Anyway, your 20, 40, 80 values are insane speeds, Personally if I were to transition from a 1:2:3 ratio to a 1:2:4 ratio, I'd probably keep the final result the same, resulting in 10, 20, 40. I've seen other people recommend 15, 30, 60, but that also means that the blue belts are 50% faster than they are now.
Not that faster top tier belts is a bad thing, but you would need to adjust inserters to be able to grab items from these faster belts too.
My mod adds belts of speed 53.3 and 66.6. That's right, your suggested 3rd tier base game belt is almost as fast as my 5th tier belt
The way belts work:
Every straight belt has 32 "slots" on every side (which corresponds with the number of pixels on its texture for smooth movement)
Item takes 9 slots (one for it and four free space on both sides).
Every tick items are shifted (1 slot for yellow, 2 for red, 3 for blue belt). So throughput is (60 / 9 = 6.66) per yellow belt side.
This logic is pretty discrete and can't be smoothly fine-tuned. This is why such simple tunes like "make it 10 items/sec instead of 13.33 can't be easily tuned. This is also a reason of why you just can't introduce infinite research (or any other smooth one).
The only change I would like to see here is making an item actually take 8 slots instead of 9 - that would make a straight belt always have 4 items per side which would be a really handy tool for detecting compression issues. This will also increase belt throughput to 15/30/45 and will finally be rounded up to a sane value.
Re: Friday Facts #225 - Bots versus belts (part 2)
I think that the best way to go about this issue is not to hurt UPS of megabases.
Going from that, as other people noticed we should add belt loaders (maybe 2 different items, that is loader and unloaders).
Plus, I believe that game called "Mindusrty" has an item that should facilitate the appeal of belts to the player it's called there "router". What it does is, when it is connected to entities like turrets or foundries (furnaces would be Factorio equivalent), it provides them with items from the belt without a need for inserters.
As a result we would have "bots + inserters" combo and "belts + routers + loaders" combo for the use in the late game, thus not decreasing UPS of megabases and improving appeal of the belts.
Going from that, as other people noticed we should add belt loaders (maybe 2 different items, that is loader and unloaders).
Plus, I believe that game called "Mindusrty" has an item that should facilitate the appeal of belts to the player it's called there "router". What it does is, when it is connected to entities like turrets or foundries (furnaces would be Factorio equivalent), it provides them with items from the belt without a need for inserters.
As a result we would have "bots + inserters" combo and "belts + routers + loaders" combo for the use in the late game, thus not decreasing UPS of megabases and improving appeal of the belts.
Re: Idea to nerf bots - make them take up space
This is a good idea, and (some of it at least) already exists in the game, currently used for recharging.domanite wrote:Bots today don't have physicality - they can infinitely overlap, with each other and with other game objects. A pretty intuitive and visually-interesting nerf would be to change that. Make bots get in each other's way. If there are a bunch of bots going in the same place, make them cluster and block each other. The more bots you have, the worse it would be - it feels like a pretty natural balancing.
From a code perspective, it would probably be a PITA; you'd have to figure out how to make bots do something reasonable and/or interesting when they block each other. On the other hand, it might open up interesting mods, that try different path algorithms or other logic to cope with bot clusters in interesting ways.
This isn't exactly getting in each other's way, but it does limit throughput quite a lot
It would just need to be set up the same for pickup and drop-off chests as well. One additional thing that should be coded is if you have multiple chests robots could pick up from that they would start using those. But I think they do that for recharging already, so if that logic gets applied to pickup (but not drop off, that's already balanced) it should work. This would allow small robot setups to work with little change, but massive ones would need some thought.
Re: Friday Facts #225 - Bots versus belts (part 2)
So, on a scale from 1 to 10, how afraid of tomorrow FFF everyone is?
Re: Friday Facts #225 - Bots versus belts (part 2)
0Avezo wrote:So, on a scale from 1 to 10, how afraid of tomorrow FFF everyone is?
Experience showed that Factorio devs are good to find proper solutions
Re: Friday Facts #225 - Bots versus belts (part 2)
As a player, 0. I totally trust Wube to do whatever is needed to make Factorio the best game ever (in its own niche).Avezo wrote:So, on a scale from 1 to 10, how afraid of tomorrow FFF everyone is?
As a moderator, 12. Because well ... there are some particularly polemic subjects that could set the community on fire, and THAT would give me a lot of work .
Koub - Please consider English is not my native language.
Re: Friday Facts #225 - Bots versus belts (part 2)
Yup. Honestly, I’m not too concerned either.Avezo wrote:So, on a scale from 1 to 10, how afraid of tomorrow FFF everyone is?
The devs have an overall excellent track record. I don’t think they’d entirely remove bots. And I don’t really “megabase” to the point where I need to optimize for UPS. So whatever balancing happens, I should be able to work around it.
The new smart splitter should allow me to replace my bot based sorters with a decent belt option. And that’s really the only remaining “high-throughput” bot construction I have.
I’m lucky enough to be where I can still build out instead of having to mass-beacon each setup. I’ll still probably try it sometime. But honestly I have the most fun with railways anyway.