Chests should have a max bots/s limit and more

[netmand]

https://mods.factorio.com/mod/LiquifyIntermediates
https://mods.factorio.com/mod/LiquifyRawMaterials
https://mods.factorio.com/mod/LiquifyScienceandLab

Though those don't make assemblers take liquid input. That would b a bit of a pain to implement with more than two inputs.

yeah, and piping has issues of its own.
I'm glad my chests have no silly limitation!

[mrvn]

The penalty for using excessive amounts is the ever increasing number of roboports required.

At megabase level such costs are theoretical and negligible. In practice you just blueprint couple of nuclear plants or square kilometer of solar panels and problem is solved in short time. In that phase only limit is computer's speed and players ability to play with low fps. All game resources are free. Such base produce and build infrastructure needed to overload computer in no time.

You didn't get the problem. It's not that you have to build the roboports and power them. It's that the roboports take space and charging takes time.

The number of bots/s a chest can have is strictly limited by the number of roboports near it and the diatance between the source and destination as well as the roboports. You can add more roboports but that increases the distance and you get an ever decreasing return for each additional roboport. Eventually at some point the roboports will be too far away for the bots to pick them for recharging. Which sets an absolute upper limit on the number of bots.

So there already is an upper limit for bots/s for a chest. Just indirectly. And maybe too high for you to notice. It also only works long term for sustained operations. For short bursts you can have basically unlimited number of bots (still limited by number of roboports near * storage space per roboport but that's HUGE and then some).

[Yoyobuae]

Bots absolutely excel at short bursts of high throughput.

But when bots need to be constantly moving the need to recharge really starts to limit them. A straight "road" of roboports and a bus of four blue transport belts take the same space and can support similar throughput (assuming the amount of logistic bots is suitable).

[Hannu]

The number of bots/s a chest can have is strictly limited by the number of roboports near it and the diatance between the source and destination as well as the roboports. You can add more roboports but that increases the distance and you get an ever decreasing return for each additional roboport. Eventually at some point the roboports will be too far away for the bots to pick them for recharging. Which sets an absolute upper limit on the number of bots.

Yes, you are right and it is probably which makes ultimate limit. But the limit is currently so extremely high that I do not see any reason to increase it or even keep it if there could be more interesting things instead. I do not even know what is the highest throughput base built with last versions but increasing it would be just copying more stuff and/or increasing numbers on screen. It would not bring any new interesting ways to build production plants or challenges to be solved even there were teleport chests with unlimited capacity. Building of 99 % maximum throughput bot factory is a trivial task (from engineering point of view).

If I want to get just large numbers I play Swarm simulator. I have 2.88E5526 (288 followed by 5524 zeros) units of meat in my current game. But I want to use actual time 2 minutes in every 3 days in such numbergames. I expect more intelligent challenges from Factorio like games I use hundreds of hours to play and in my opinion bot based megabases are just boring number game.

[Hannu]

Bots absolutely excel at short bursts of high throughput.

But when bots need to be constantly moving the need to recharge really starts to limit them. A straight "road" of roboports and a bus of four blue transport belts take the same space and can support similar throughput (assuming the amount of logistic bots is suitable).

Which consumes more CPU time?

But it is not a good idea to transport items over long distances on belts or bots. The most effective system uses bots to transport input items from miners or input station to assemblers and from assemblers to output station. Trains are the most effective in long range transport.

Assembling system use straight insertion from assembler to another when possible and avoid CPU consuming belts. Different items are produced in different bot networks so that bots never transport over long distances.

[Yoyobuae]

Which consumes more CPU time?

Bots use significantly more CPU than belts, but splitters are even worse than bots:

https://imgur.com/a/1yKeQSM

I placed 1152 parallel blue belts transporting green circuits from one box into another. That was the only thing on the map. The UPS was ~260.

Then I made the equivalent using roboports. I carefully adjusted the amount of robots until they achieved the same throughput as as the blue belts. The UPS was ~14.

Then as a final test I replaced the belts in the first test by a weave of spliters. The UPS was ~10.

If you use belts and keep splitters to a mininum then belts can win by a margin of ~10x.

[mrvn]

The number of bots/s a chest can have is strictly limited by the number of roboports near it and the diatance between the source and destination as well as the roboports. You can add more roboports but that increases the distance and you get an ever decreasing return for each additional roboport. Eventually at some point the roboports will be too far away for the bots to pick them for recharging. Which sets an absolute upper limit on the number of bots.

Yes, you are right and it is probably which makes ultimate limit. But the limit is currently so extremely high that I do not see any reason to increase it or even keep it if there could be more interesting things instead. I do not even know what is the highest throughput base built with last versions but increasing it would be just copying more stuff and/or increasing numbers on screen. It would not bring any new interesting ways to build production plants or challenges to be solved even there were teleport chests with unlimited capacity. Building of 99 % maximum throughput bot factory is a trivial task (from engineering point of view).

If I want to get just large numbers I play Swarm simulator. I have 2.88E5526 (288 followed by 5524 zeros) units of meat in my current game. But I want to use actual time 2 minutes in every 3 days in such numbergames. I expect more intelligent challenges from Factorio like games I use hundreds of hours to play and in my opinion bot based megabases are just boring number game.

As said again just recently the current limit for bots is about what blue belts give you with the same space used for the belts as for the roboports. So I don't think the limit is outrageous. And if you limit it even more so short distances feel so overpowered then long distances will become useless.

The biggest benefit of bots is that they fly. You can just put down a provider chest, a requester chest and a number of roboports and goods will flow. Unlike belts you can place the roboports away from the beacons allowing you to put more beacons per assembler. That and not having to worry about splitting and balancing goods when you have multiple provider and requester is what makes bots so useful. As said throughput wise they are about the same as blue belts and worse than trains. (Except with bots the factory can be more compact giving you an edge.)


I can see 2 ways to balance this overpowered feel of bots:

1) Have pickup/drop off points like recharging pads. So like you suggested a max bot/s limit on the chest. But that turns into a cloud of bots hovering around each chest waiting for a spot. Worst case you get a case where every bot runs out of charge before it reaches the head of the queue and goes for a recharge. So no bot ever delivers anything or picks up anything. So not a good idea.

2) Don't allocate more bots than there is space left in the chest. I think this isn't done yet. Untested: If you set a requester chest to 1000000000 iron plates will you get 1000000000 bots moving towards the chest? Or is there a limit there somewhere? Never had enough bots yet to truly test for limits.

3) Picking up items and dropping them of could take time and/or power. This would penalize short trips without making long distances hopeless.

[Koub]

[Koub] Moved to balancing.
@OP : this is one of the many, many (many) suggestions that came out during the infamous bots vs belts war, back in the beginning 2018.
For more info on this :
viewtopic.php?f=38&t=56218
viewtopic.php?f=38&t=56519

I think the single most broken thing is how you can get infinite throughput to/from a single chest.

Show me a save with a proof of concept of infinite throughput between two chests over ... let's say 100 tiles over 1 hour.

[ssilk]

I think we should make that all much more cpu efficient. Instead of inserters the producing device should transfer/beam the items directly into the device, which needs it.

[Optera]

I think we should make that all much more cpu efficient. Instead of inserters the producing device should transfer/beam the items directly into the device, which needs it.

[sarcasm]
For perfect CPU efficiency we should add a higher tier assembling machine capable of multiple crafting steps.
Ores in > Space Science Packs out
[/sarcasm]

[5thHorseman]

[sarcasm]
For perfect CPU efficiency we should add a higher tier assembling machine capable of multiple crafting steps.
Ores in > Space Science Packs out
[/sarcasm]

Hand crafting is OP! We need assemblers that can hand craft!

[Optera]

Didn't Biffa try that with his horde of followers?

[Hannu]

Bots use significantly more CPU than belts, but splitters are even worse than bots:

https://imgur.com/a/1yKeQSM

I placed 1152 parallel blue belts transporting green circuits from one box into another. That was the only thing on the map. The UPS was ~260.

Then I made the equivalent using roboports. I carefully adjusted the amount of robots until they achieved the same throughput as as the blue belts. The UPS was ~14.

Then as a final test I replaced the belts in the first test by a weave of spliters. The UPS was ~10.

If you use belts and keep splitters to a mininum then belts can win by a margin of ~10x.

I can not see imgur for some reason (i tried Firefox and Edge, same results). But if I understand your description correctly that does not seem very realistic test, if you use source and sink chests and loaders. I would like to compare realistic systems from input stuff in chest to output in chest. As far as I have understood loaders and full belts are very effectively optimized but partially filled belts and inserters used to load to and take from belts affect UPS much worse. It is also trivial to move stuff between two inventories, because there is no need for create a item and make physics checks. If item is moved to or from belt there are checks for nearby items or empty rooms etc.

Is bases of highest published throughput belt based or bot based? Several versions ago all biggest factories was bot based. They changed belts after that but I do not know what is practical situation now.

[Hannu]

I can see 2 ways to balance this overpowered feel of bots:

I think there is no ways. Nerfing of bots would hit to one of the most common and visible playstyles and induce too much resistance. This is more academic discussion than real try to change things.
In my opinion an option of bots with collisions and flock dynamic would be nice for aesthetic reasons. It would not be very laborious to program (flock dynamics is much simpler to program and faster to execute than it looks) and there would certainly be significant number of players who never build high throughput robot factory but appreciate those beautiful flight patterns of bot flocks. And if it was an option bot builders could choose current immaterial behavior and build their megabase with 100000 bots. But I do not hold my breath or delay new games during wait.

[Koub]

Remember that bots are limited by the amount of roboports you can cram to power them.

[Yoyobuae]

I can not see imgur for some reason (i tried Firefox and Edge, same results). But if I understand your description correctly that does not seem very realistic test, if you use source and sink chests and loaders. I would like to compare realistic systems from input stuff in chest to output in chest. As far as I have understood loaders and full belts are very effectively optimized but partially filled belts and inserters used to load to and take from belts affect UPS much worse. It is also trivial to move stuff between two inventories, because there is no need for create a item and make physics checks. If item is moved to or from belt there are checks for nearby items or empty rooms etc.

My test used inserters to put items into the belts and didn't quite fill the belts. They were almost full but still had a few micro gaps.

Is bases of highest published throughput belt based or bot based? Several versions ago all biggest factories was bot based. They changed belts after that but I do not know what is practical situation now.

10K SPM bot based megabase = 8 UPS: https://imgur.com/a/hAngDer

10K SPM belt based megabase = 83 UPS: https://imgur.com/a/Qkre7bX

Oh my would you look at that, there's almost exactly a 10x UPS difference between them.

Remember that bots are limited by the amount of roboports you can cram to power them.

And by size of the network. Too large a network results in bots picking stuff from the other corner of the base and then taking minutes to deliver it, even if there are provider chests much closer.

Any bot base necessarily requires an alternate system to connect the various separate logistic network blocks (usually trains are used).

[Koub]

10K SPM bot based megabase = 8 UPS: https://imgur.com/a/hAngDer

10K SPM belt based megabase = 83 UPS: https://imgur.com/a/Qkre7bX

Oh my would you look at that, there's almost exactly a 10x UPS difference between them.

Unfortunately, you compare things that are hardly comparable. chunk aligned grid train network are appealing to the eye and OCD friendly, but are known to be bad UPSwise. Also the belt based base doesn't include power generation : power is provided by an electric interface (while the other base is nuclear powered, which is not the ups friendliest solution) also I don't know how much taxing the circuit network is on the bot base.
LAstly the belt base relies very heavily on direct insertion, which is very UPS friendly.

I'm not saying that belts >> bots, but those bases just don't compare.

[Qon]

Unfortunately, you compare things that are hardly comparable. chunk aligned grid train network are appealing to the eye and OCD friendly, but are known to be bad UPSwise. Also the belt based base doesn't include power generation : power is provided by an electric interface (while the other base is nuclear powered, which is not the ups friendliest solution) also I don't know how much taxing the circuit network is on the bot base.
LAstly the belt base relies very heavily on direct insertion, which is very UPS friendly.

I'm not saying that belts >> bots, but those bases just don't compare.

While agree with you mostly, I would say that comparable bases don't exist. They would have to be made similarly, maybe by the same person to be as close as possibly the same style . And developed at the same time with similar efforts into UPS optimisations. And so on. They take too much time to build for that to be realistic. So Hannu should accept it anyways or the standard for proof is insurmountably high and basically just a way to deny reality to argue nerfing bots regardless of the reality.

Also the grid rail is tiny. I really doubt grid rails are that bad, and that it matters in practise compared to everything else, and in particular I highly doubt the grid rail in this example is actually a significant detriment here.

The bot base could have power replaced with electric energy interface though to make them more comparable. Might be the easiest and and most impactful way to make the comparison more apt.

[Yoyobuae]

Unfortunately, you compare things that are hardly comparable. chunk aligned grid train network are appealing to the eye and OCD friendly, but are known to be bad UPSwise. Also the belt based base doesn't include power generation : power is provided by an electric interface (while the other base is nuclear powered, which is not the ups friendliest solution) also I don't know how much taxing the circuit network is on the bot base.
LAstly the belt base relies very heavily on direct insertion, which is very UPS friendly.

I'm not saying that belts >> bots, but those bases just don't compare.

I made a specially crafted test which isolates as best as possible the UPS impact of transport belts VS bots while keeping every other variable the same, and was told that my comparison was not valid either.

I think some people just refuse to accept that maybe their understanding of bots being the best for UPS is no longer valid after the many optimizations belts have received.

I can not see imgur for some reason (i tried Firefox and Edge, same results). But if I understand your description correctly that does not seem very realistic test, if you use source and sink chests and loaders. I would like to compare realistic systems from input stuff in chest to output in chest. As far as I have understood loaders and full belts are very effectively optimized but partially filled belts and inserters used to load to and take from belts affect UPS much worse.

I updated my test to use chests+inserters for both the source and sink of items and I also verified that belts had gaps in them (there were small gaps every 10~12 items). The result remains the same: belts are more UPS efficient than bots.

I did make a new discovery: Filter inserters are absolutely awful for UPS.

It is also trivial to move stuff between two inventories, because there is no need for create a item and make physics checks. If item is moved to or from belt there are checks for nearby items or empty rooms etc.

My updated test shows that the cost of inserters moving items into/from belts is still lower than the cost of bots flying from provider to requester and occasionally stopping to charge. The cost of inserters is a one time cost at the source and at the sink. The cost of bots flying grows linearly with distance traveled. Belts have almost no UPS cost increase with transport distance.

[ssilk]

I would say that observation matches more or less my own. Bots suck for UPS, when you have too much of them. I could not put any number on it, how much slower, but so much slower, that you can definitely feel it.