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

Regular reports on Factorio development.
Locked
mrvn
Smart Inserter
Smart Inserter
Posts: 3734
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post by mrvn » Tue Apr 10, 2018 12:20 pm

Darthlawsuit wrote:Belts can only input so much into a factory at once. Bots can do infinite. Make it so only X number of bots can input/output from objects. Containers can allow a lot of input/output while factories can only do so many at a time.
And that is simply not true.

1) bot speed is ultimately limited by recharges. You can only have so many bots in an area before they back up on the roboport and everything breaks down.
2) requester chests request only so many goods. Divide that by the time to transport said goods multiplied by robot cargo space and you have an upper limit for goods/s.
3) same deal for provider chests, another upper limit for goods/s.

Belts give you a fixed amount of goods/s no matter the distance. Bots give you items/ms. The further away the source of the items the slower the throughput.

So say the bot takes 3200 ticks (somewhat under a minute) to travel from povider to requester and back and recharge along the way. Then that would limit your throughput to 1 item per second per requester chest. How war would that be? How far can a bot travel in 3200 ticks including breaks for recharge?

bobucles
Smart Inserter
Smart Inserter
Posts: 1588
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

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

Post by bobucles » Tue Apr 10, 2018 3:48 pm

So say the bot takes 3200 ticks (somewhat under a minute) to travel from povider to requester and back and recharge along the way. Then that would limit your throughput to 1 item per second per requester chest. How war would that be? How far can a bot travel in 3200 ticks including breaks for recharge?
We already figured out this math a long time ago. Bots not only have all those special item transporting advantages over belts, but after getting fully upgraded they straight up move more stuff.

Jap2.0
Smart Inserter
Smart Inserter
Posts: 2037
Joined: Tue Jun 20, 2017 12:02 am
Contact:

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

Post by Jap2.0 » Wed Apr 11, 2018 2:10 am

[quote="mrvn") requester chests request only so many goods. Divide that by the time to transport said goods multiplied by robot cargo space and you have an upper limit for goods/s.[/quote]
Generally if that happens people just increase the amount requested.
There are 10 types of people: those who get this joke and those who don't.

User avatar
vampiricdust
Filter Inserter
Filter Inserter
Posts: 314
Joined: Wed Jan 14, 2015 1:31 am
Contact:

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

Post by vampiricdust » Thu Apr 12, 2018 2:34 am

bobucles wrote: :evil:
We already figured out this math a long time ago. Bots not only have all those special item transporting advantages over belts, but after getting fully upgraded they straight up move more stuff.
Of course they move more stuff after you upgrade them. However, if you invested all the resources into blue belts & trains instead of research, you would have tens of thousands of blue belts and hundred of trains with thousands of rails. Bots excel in tight spaces where belts can't squeeze in the same way belts excel in tight spaces where trains & stations can't squeeze in. Not to mention bots are a higher tier of science and most of their power comes from infinite research. If belts had infinite research, this wouldn't be an issue.

This whole bots versus belts is like arguing a hardwired phone versus cell phones. OF COURSE HIGHER TECH IS BETTER.

Koub
Global Moderator
Global Moderator
Posts: 5087
Joined: Fri May 30, 2014 8:54 am
Contact:

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

Post by Koub » Thu Apr 12, 2018 5:47 am

vampiricdust wrote:Of course they move more stuff after you upgrade them. However, if you invested all the resources into blue belts & trains instead of research, you would have tens of thousands of blue belts and hundred of trains with thousands of rails. Bots excel in tight spaces where belts can't squeeze in the same way belts excel in tight spaces where trains & stations can't squeeze in. Not to mention bots are a higher tier of science and most of their power comes from infinite research. If belts had infinite research, this wouldn't be an issue.

This whole bots versus belts is like arguing a hardwired phone versus cell phones. OF COURSE HIGHER TECH IS BETTER.
I have noticed at work that people dismiss most of the time the hidden costs. You could invest billions of ressources into upgrading something, people will only look at the result and tell This thing is upright better.
Same thing in real life at my job. I'm in IT support.Typical discussion :
Financial department : "IT support is too expensive. Find a way to cost less money."
Boss : "Add self-care and Self-help for everything, and let the users help themselves. Less support, problem solved".
Me : "10 minutes of tech support time costs a lot less to the company than 1 hour lurking on the intranet to find answers for the end-user engineer"
Boss : "False : look at my excel spreadsheet : fucking DIY costs nothing, support costs money"
Financial department : "False : look at my excel spreadsheet : fucking DIY costs nothing, support costs money"

Conclusion, it is more profitable to pay people for not doing their job than to pay support to help people get back to work efficiently.

Same debate in bots vs belts. No matter how much bots cost to research, upgrade and upkeep, people only look at the most obvious result ans keep saying "See ? bots are OP".
I have a challenge for bot haters (and bot non haters, because it's a fun challenge) :
- Create a scenario with a fixed amount of raw ressources, lets say a million of each ressource, but no minable ore fields, no oil. Let it be in peaceful.
- Build/research whatever you want
- Goal is to move the contents of one full passive provider chest of green circuits 1000 tiles in any direction.
- Post your best time and the strategy.
Koub - Please consider English is not my native language.

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 684
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

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

Post by Oktokolo » Thu Apr 12, 2018 6:34 am

I don't know, if it is the case or not (not a heavy bot user and not into beacons myself). But if a botted layout would allow more productivity modules than a non-botted layout, the botted layout would always be destined to win the economic showdown for runtimes aproaching infinity. Then it would not matter, how big the initial investment is, because over time you would always use your resources more efficient with the botted setup than with the belted one.

The question is: Are there botted designs that are more resource-efficient, than the best belted designs for the most important products in the game?

mrvn
Smart Inserter
Smart Inserter
Posts: 3734
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post by mrvn » Thu Apr 12, 2018 8:56 am

bobucles wrote:
So say the bot takes 3200 ticks (somewhat under a minute) to travel from povider to requester and back and recharge along the way. Then that would limit your throughput to 1 item per second per requester chest. How war would that be? How far can a bot travel in 3200 ticks including breaks for recharge?
We already figured out this math a long time ago. Bots not only have all those special item transporting advantages over belts, but after getting fully upgraded they straight up move more stuff.
Apparently you figured it out wrong. Or at least you figured the opposite of me. I'm saying bots are limited. Belts are not. At least at range.

I guess it depends on how much a requester chest requests. Does it request more items than it can hold? Can I request a million iron plates in a single chest or will it limit the requests to how many iron plates will fit? It should be the later but now I'm not sure if it actually is. If a chest can request more than will fit then you can get an unlimited number of bots working on transporting. Then the only limit is the recharge spots.

mrvn
Smart Inserter
Smart Inserter
Posts: 3734
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post by mrvn » Thu Apr 12, 2018 9:01 am

Oktokolo wrote:I don't know, if it is the case or not (not a heavy bot user and not into beacons myself). But if a botted layout would allow more productivity modules than a non-botted layout, the botted layout would always be destined to win the economic showdown for runtimes aproaching infinity. Then it would not matter, how big the initial investment is, because over time you would always use your resources more efficient with the botted setup than with the belted one.

The question is: Are there botted designs that are more resource-efficient, than the best belted designs for the most important products in the game?
You can only put productivity modules in the assembler itself, not in beacons. Beacons only give you extra speed.

Playing with Bobs + Angels you can place more beacons in range of an assembler or furnace with speed modules than the game will handle. Ultimately you are limited by one recipe cycle per tick. That means you can skip a few beacons around the assembler or furnace giving you plenty of space for belts. Really slow recipes can use all beacons but then they don't need many belts. And the beacons, when maxed out, leave a 1 tile gap in all 4 directions for belts.

Pascali
Fast Inserter
Fast Inserter
Posts: 138
Joined: Wed Aug 23, 2017 8:24 pm
Contact:

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

Post by Pascali » Thu Apr 12, 2018 10:34 am

vampiricdust wrote:
bobucles wrote: This whole bots versus belts is like arguing a hardwired phone versus cell phones. OF COURSE HIGHER TECH IS BETTER.
The question is, what style is more fun. If you can use a system that will help you, you will use it. The game orientates on all features. Belts are fun. Its more fun to watch iron splitting on a beltsystem into differen directions. Feeling happy about the new iron coming in. With bots, it´s a mess. It´s more fun to build belts. Bot´s you don´t have to build oder puzzle. Yes, you can make a new beaming-science. And a new super-bot science. At the beginning of the game, you press the "S"-key on your keyboard. After that you have to wait for 2 hours and 10 rockets are launched every 20 minutes. You don´t have to touch any key or navigate with your mice - just look what´s going on on the screen. The journey is the reward!

Maybe focus on the belt-system and get bots out of the game. So optimize the game without bots(or only 2 setups where you can use bots, and 1 setup it´s more effective to use belts. So you can first build bot-system and then optimize with bels).

And add a kid-mode with the possibility to build bots. So all the programming-time is not lost. But the game is optimized to work without bots.

bobucles
Smart Inserter
Smart Inserter
Posts: 1588
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

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

Post by bobucles » Thu Apr 12, 2018 11:33 am

Apparently you figured it out wrong.
Um okay. That will just have to be your opinion, because I've already made my argument and have in game proof to back it up.
I'm saying bots are limited. Belts are not. At least at range.
False. Everything takes up real estate, and long belts are no exception. A long bus can be made out of roboports or belts, and in every possible situation the bot bus will take up less footprint as well as move more items period. That mountain of roboports and bots is also very expensive, but blue belts are no freebie either.

That's for a direct apples to apples comparison. Bots also have advantages outside a direct comparison that belts don't have, and belts have some conveniences that bots don't have. But generally the value of moving more stuff outweighs other considerations.

mrvn
Smart Inserter
Smart Inserter
Posts: 3734
Joined: Mon Sep 05, 2016 9:10 am
Contact:

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

Post by mrvn » Thu Apr 12, 2018 11:51 am

bobucles wrote:
Apparently you figured it out wrong.
Um okay. That will just have to be your opinion, because I've already made my argument and have in game proof to back it up.
I'm saying bots are limited. Belts are not. At least at range.
False. Everything takes up real estate, and long belts are no exception. A long bus can be made out of roboports or belts, and in every possible situation the bot bus will take up less footprint as well as move more items period. That mountain of roboports and bots is also very expensive, but blue belts are no freebie either.

That's for a direct apples to apples comparison. Bots also have advantages outside a direct comparison that belts don't have, and belts have some conveniences that bots don't have. But generally the value of moving more stuff outweighs other considerations.
And you skipped right over the important part.

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

My argument hinges on that and I assumed it was limited to the chest size. I'm not so sure about that anymore. But if it is limited then that limits the throughput of bots per chest at a distance. Which was my argument. Belt throughput is the same at any distance. Bots depend on the number of requests.

bobucles
Smart Inserter
Smart Inserter
Posts: 1588
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

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

Post by bobucles » Thu Apr 12, 2018 4:19 pm

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)

Kalamel
Burner Inserter
Burner Inserter
Posts: 6
Joined: Fri Apr 13, 2018 8:13 am
Contact:

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

Post by Kalamel » Fri Apr 13, 2018 11:29 am

I'm one-quarter late for this but I still want to share my view a bit.

First, I love belts and enjoy design belts input, even I know it's not really efficient as spaghetti maze took almost equal area to assemblers they feed. I buy this game after my friend show it, with bots logistics on late game. But I love belt more and launch my first-ever rocket with bot embargo, because it's more fun. Sky-darkening bot-swarm also is UGLY.
But I think I support bot in this case though I prefer combinations if possible.
I divided my wall of word into
1. Reason why I think current bot system is very hard to be nerfed to comparable with belts and vice versa with belt-buff.
2. Suggestion for possible solution.


REASON

My reason is that in my opinion, Logist-bots are NOT replacement for belt. It's replacement for belt SPAGHETTI themselves. They designed to bypass maze-designing for complex recipe, intentionally I think. But what's unexpected is that they have even more throughout than belts, and their scalability is not really expensive, as power are practically free with solar.

If you exclude required power, researchs and material costs and roboport placed far away, it is theoretical IMPOSSIBLE for belts to compete with bots in any meaningful case. Because minimum requirement for belt transfer system are 2 inserters, 2 belts and power pole. Those are already same things for COMPLETE active site for bot-transfer system, just replace belts with chest. Not to mention chest have more space for buffering. This mean that if somebody have surplus power, s/he can even use bots for pick-up items and drop them just few tiles away, which might be things designed for belt to do. With requester chest capable of request more than one type of item at time, things even worse for belts.

Expansion is fetal weakness for belt, as I think someone should already mentioned, because both increasing distance and throughout require space, most precious resources, and material themselves. You need 4x space to double distance and throughout in unoccupied land, with some obstacle that might increase, a lot.
With bots you just need to double robot counts, roboport and power-structure. And that just don't care about how crowded the area is. It is not cheap, but we are talking about late-game situation so that don't really matter.

As you can see, belt already draw at 0 tile distance, and lose more and more with increasing distance. So I think that train-bot combination answer all situation and no gap in middle for belts at all, if we don't care about power used. Belts probably can be used to move materials around in few underground-range, but they might not be close to any assemblers.


SOLUTION

More belt throughout is better, but I don't think it is a focus in this case. Even belt have throughout and dynamic equal to fluid pipe, but smarter and not connect unwanted, I don't think that most logist-bots users will start using belts, even as bot-belt combination. They choose bots to avoid spaghetti, throughout is just bonus. But belt-users will be pleased cause now their choice are not inefficient choice anymore, and assemblers one of their maze can feed will increased too.

Air-space limitation will solve the problem but obviously infeasible.

I also really want three-or-more-lanes belt as it will increase both throughout and emphasize one-tile-multi-component utilization of belt-system. Bots already have those, though.

If dev-team really hell-bent to make combination of bot-belt, bot-system must change a lot. Inserter must not be able to pick from requester/buffer-chest at all otherwise chest-inserter-assembler combo will persist.

Making single-filter requester/buffer will just call for more chest per assembler, as someone mentioned. It probably help a bit if chest has only one slot, more than that and merit of material storage will beat any pathetic 7-items per tile belts.

If requester/buffer chests have only a few slot, decrease stack size will help belts a whole lot, as they are not affected by stack size, just pathetic 7-items per tile limit. So if every items have stack size of 5, except ore and barrel (otherwise barrel will be obsolete) will automatically make belt better than bot in case that logist-chests have only a slot, but save loaded after update will probably have ground covered by everything spill from chests.

My suggestions are to prevent items in buffer chest to be picked by inserter and change requester chest to something like 'Drop-belt', an one-tile, one-lane directable belt design for receive requested-items dropped from bots and insert them to belt.
Bot might need to stay until all item dropped (in case target belt is full, might take a while) and another bot queue up for continue loading (nearby buffer chest will help), or drop-belt might have some buffer storage, essentially one-filter requester chest combine with loader in one tile.
This will force item transport from chest->bot->belt->inserter->assembler, add high-throughout of bots to belt and ENSURE bot-belt combination. Please note that it also might cause rage from both side of confilct as bots swarmer forced to change a lot and to increase efficiency, they must do mazes. While belt faction will blame it for simplify 'spaghetting'.

My other ideas to remove (unsightly) bots swarm are to nerf bots by make them produce (noise) pollution, decrease their stack size and combine with proposed upgrade removing and increasing recharge time to discourage them to use bots.
Another idea is but them to the hell so they can to same thing with fewer bots, such as increase charging speed, battery and cargo-size a lot AND make them able to drop item to more than one chest in one round. So they will have fewer logist-bot around and in exchange they might be more expensive, very few stack size like 5 (35 bots per roboport max, for logist-bot only) and sharp increase in their charging spike.

P.S. I didn't read the all related-thread yet. Is there any index for suggestion and their pros/cons?

vanatteveldt
Filter Inserter
Filter Inserter
Posts: 922
Joined: Wed Nov 25, 2015 11:44 am
Contact:

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

Post by vanatteveldt » Fri Apr 13, 2018 1:12 pm

I just tested in creative mode. You are correct that chest->chest throughput is limited by distance since effective request size is capped by chest capacity. You can request 100 arty shells, but it only delivers 48. A small test shows that a chest is already starved requesting artillery shells from around 150 tiles distance with a single inserter outputting items.

I would assume bot delivery throughput in items per second maximizes at request size divided by bot travel time, minus a bit of inefficiency for the bot to get to the provider chest. Bots at speed bonus 5 (the last non-infinite) travel 10 tiles per second. So, if you need to move something 1000 tiles (somewhat reasonable in a megabase), it takes 100 seconds for the bot to get from provider to requester.

Worst case scenario, you are requesting something with stack size 1 like artillery shells. So, no stack bonus and only 48 per chest. That means your throughput is only 0.5 per second (48/100), which is certainly a limiting factor.

Almost all bulk-transport cases, however, involve items with at least stack size 50. Stack size bonus doesn't actually help except for edge cases, but request size is now 48*50, so throughput is (48*50/100) or 24 items per second, which is less than the thoughput of a single stack inserter.

These numbers are assuming there are available pots close to the provider. If they have to travel back in response to a request, thoughput is halved. I would guess in most realistic scenarios throughput is at most 50-75% of the numbers here due to time to wake up, fly to provider, and possibly charge halfway to the requester.

If the distance between provider and requester is greater than the flying distance per charge, throughput will drop as bots spend time charging while delivering. Can anyone link bot battery capacity, usage, and charge time?

Conclusion: bulk transport by bot is indeed limited. However, you can get around this by placing N buffer chests close to the requester, since each buffer chest will have this throughput. Moreover, it only kicks in at around 1000 tile distances.

Edit: tested the model. Distance: 150 tiles. Speed bonus 6 (+305%) or 3*4.05=12.15 tiles/s. Expected throughput for artillery shells: 48*(12.15/150)=3.88/s. Observed throughput=3.6/s, so close enough.
Last edited by vanatteveldt on Fri Apr 13, 2018 10:17 pm, edited 1 time in total.

bobucles
Smart Inserter
Smart Inserter
Posts: 1588
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

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

Post by bobucles » Fri Apr 13, 2018 1:53 pm

Interesting analysis, vanatteveldt! Just a friendly reminder that 1000 tiles is approximately the permanent vision area of 4 x 4 well spaced radars. That's definitely a good sized base! Moreover, those """limitations""" exist for every individual requester chest in the network. Increasing throughput is a trivial matter of adding more requester chests, or bringing items closer with any number of buffer chests.

So we learned that a single requester chest, one tile of real estate, struggles to match an ENTIRE 1000 tiles of blue belt in terms of drawing items across the map. That's like complaining a pound of uranium isn't as powerful as a thousand pounds of TNT. So what. The footprint of requester chests is orders of magnitude smaller than anything the belt system will ever manage. Drop down a dozen requester chests and buffer chests, and suddenly your "requester capacity" has surpassed the throughput of a 10 wide bus. I'm pretty sure that setting up 20 blue/green boxes is less challenging than building a 10 width bus.

If anything the sheer requester capacity of blue chests simply serves to drive the knife in deeper. Roboports don't only PROVABLY provide more item motion per real estate, but the requester chests provide superior last mile routing as well.

All hope is not lost though. A large base of well organized belts is sexy. A gigantic hornet's nest of bots is cancerous. For aesthetic gentlemen that reason is good enough.

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 684
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

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

Post by Oktokolo » Fri Apr 13, 2018 4:16 pm

bobucles wrote:A large base of well organized belts is sexy. A gigantic hornet's nest of bots is cancerous. For aesthetic gentlemen that reason is good enough.
That is the sole reason, i only use bots for personal delivery and production of low quantity stuff needing odd ingredients (until i get it automated the right way). Also prefer wooden poles over medium ones and feed my smelters with reds splitting into yellows for ores and yellows converging into reds for plates (blues seem to not fit into my playstyle because of their odd throughput of 3 yellow belts).

vanatteveldt
Filter Inserter
Filter Inserter
Posts: 922
Joined: Wed Nov 25, 2015 11:44 am
Contact:

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

Post by vanatteveldt » Fri Apr 13, 2018 10:27 pm

bobucles wrote:Interesting analysis, vanatteveldt! Just a friendly reminder that 1000 tiles is approximately the permanent vision area of 4 x 4 well spaced radars. That's definitely a good sized base! Moreover, those """limitations""" exist for every individual requester chest in the network. Increasing throughput is a trivial matter of adding more requester chests, or bringing items closer with any number of buffer chests.

So we learned that a single requester chest, one tile of real estate, struggles to match an ENTIRE 1000 tiles of blue belt in terms of drawing items across the map.
Well, sure, and it was mostly academic, but at least we have now set some sort of limit on throughput which is affected by distance, which belts aren't. The devs compared 4 blue belts to a string of roboports to compare throughput and found that the roboport always wins, but this shows that there roboports only win up to a certain distance, depending on # of destination chests.

But indeed, you can solve all this with buffer chests, at the expense of a bit of extra real estate and extra buffering, which can quickly become more than the amount of items buffered on a belt, as the number of buffer chests per target chest increases with distance.

Also, for a fair tile-to-tile comparison you also need to include the roboports needed to keep the little buggers charged.

(And yes they do look cancerous, or at least like an infestation of sorts. )

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 684
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

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

Post by Oktokolo » Sat Apr 14, 2018 7:43 am

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... :P

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?

vanatteveldt
Filter Inserter
Filter Inserter
Posts: 922
Joined: Wed Nov 25, 2015 11:44 am
Contact:

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

Post by vanatteveldt » Sat Apr 14, 2018 9:52 am

Oktokolo wrote: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... :P

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 :)

Pascali
Fast Inserter
Fast Inserter
Posts: 138
Joined: Wed Aug 23, 2017 8:24 pm
Contact:

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

Post by Pascali » Sat Apr 14, 2018 10:32 am

Kalamel wrote: I know it's not really efficient as spaghetti maze took almost equal area to assemblers they feed. I buy this game after my friend show it, with bots logistics on late game. But I love belt more and launch my first-ever rocket with bot embargo, because it's more fun.
Yes, we don´t bots, too. But it´s in the game, so the game is polished to work with bots. So it would be nice, if bots sould be nerved strongly. Or be an extra feature, not useful/working with all fabrics.

Spaghetti is more fun and more complex to build - there must be a reward.

Locked

Return to “News”

Who is online

Users browsing this forum: No registered users