Roboport robot requests limit?

[AverseMoon]

Currently, we can set roboports to request a minimum amount of robots to station (which is very nice), but we cannot set a max amount of robots in a roboport, i found this out when i tried to make the roboport that adds robots to my network not get clogged up when its filled. So maybe we could get the ability to set a limit on how many robots of each type can be in a roboport, and if it exceeds that, the robots will attempt to leave the roboport and head to another (similar to how you can set a minimum and maximum of an item in a logistic request in your inventory).

Here is a concept i made really quick:

10-25-2024, 13-09-29.png (67.81 KiB) Viewed 605 times

[Koub]

How about adding an inserter that takes from the roboport robots in excess to dump them in a provider chest ?

[AverseMoon]

How about adding an inserter that takes from the roboport robots in excess to dump them in a provider chest ?

Well yeah that would fix the clogging but then the robots wont actually start working, they would just be sitting in network storage.

[sparr]

Currently robot requests on a roboport only set a minimum. It would be nice if they could set a maximum, similar to logistics requests, so I can prevent a roboport from filling up with the wrong kind of robot.

[Koub]

Well yeah. The robots have to be somewhere when they're not working. Either in the roboports, or in a storage chest. the advantage of robots in a storage chest is they can be requested for other roboports, whereas when they are sleeping in a roboport, they can't.

[Koub]

[Koub] Merged into an older thread with the same suggestion.

[AkBKukU]

I agree with this idea to add a maximum to the roboport requests.

How about adding an inserter that takes from the roboport robots in excess to dump them in a provider chest ?

Well yeah that would fix the clogging but then the robots wont actually start working, they would just be sitting in network storage.

To phrase this differently, the chest solution is not the same as telling the robots to get out. If a max was in place they would just go to another roboport without a max instead and would still be usable. The chest is a dead end for them.

AverseMoon's example of the bot supply roboports is probably the most useful. I would set those to have a maximum of 0 of both bots so they are forced out into the network as soon as possible. I'm reading the total roboports and amount of bots to decide with combinators how many should be added by disabling an inserter when there are enough. But the inserter can be blocked if there isn't currently a need for all the bots in the roboport and they just sit there.

I have another use case to provide, I'm building a dedicated rocket logistics supply area. I *never* want construction robots in those roboports using up space that the more applicable logistics bots could be in. But I also don't want to set all of the roboports to 500 logistics bots and have thousands of them sitting there just to do that. A maximum of 0 construction bots and 50 logistics bots would let me set it up how I'm trying to.

[EustaceCS]

If you don't oversaturate your network with drones, you won't have to solve the problem of them hibearnating happily at some distant roboport.
Wired inserters can listen to quantity of actually available-for-business bots in network. And, you know, not add more bots into network unless absolutely mandatory (read: available bots < 1).
This + minimal amount of bots requested in roboport itself should solve most of such problems just fine.

[AkBKukU]

If you don't oversaturate your network with drones, you won't have to solve the problem of them hibearnating happily at some distant roboport.

I want them spread throughout the network, buffer chests with bots always near by is good for rapid response.

Wired inserters can listen to quantity of actually available-for-business bots in network. And, you know, not add more bots into network unless absolutely mandatory (read: available bots < 1).

The method I'm using is 25 * [R] to calculate the number of bots needed to have half a stack stack in every roboport. It is an automatic limit based on available roboports. Large projects that use all bots available can make the [Z] < 1 method run unchecked and overproduce bots. Even more so in 2.0 after the bot charge rate was nerfed for non-quality roboports that charge the bots slower keeping them unavailable for twice as long.

Either way, that doesn't help with trying to make a roboport never have a specific kind of bot land in like my ideal logistic only restriction near rocket silos.

[spectria.limina]

I don't think "the robots need somewhere to go" makes sense as an argument against this feature, because roboports already have a maximum capacity and it's perfectly possible to overwhelm a network with more bots than it can actually hold.

This would be a very useful feature particularly for outposts far away from the main base but connected by network. We want a small number of construction bots there to rebuild damaged walls and turrets, but we definitely don't want logistic bots hanging out there as there will never be anything to pick up.

Logistic bota are solvable with the chest approach and a filtered inserter, but it's inelegant. If we have to unload logistic bots from the outpost roboport and ship them back, then another logistic bot will need to travel out to the outpost to carry its fellow members back to the rest of the base, which is very silly when they are perfectly capable of making the journey on their own. It also means that all the intermediate rovoports in between would *also* need unloaders and provider chests, which is (imo) unnecessary resources.

More annoyingly, the robots put into the chests must be somehow identified as "robots to put back in the network" and kept apart from robots being kept for e.g. shipping to other planets. This isn't impossible by any means, but it requires circuit control which is a fair bit much IMO.

For the construction bots, though, there is no solution to allow us to keep a max number of bots around. Because a roboport can't read its own robot contents to a circuit network, it's impossible to disable an inserter or conditionally filter so as to always leave, say, 25 construction bots behind but send the rest back to the main base.