Add a flush/purge option for roboports to be vacated

[JackTheSpades]

TL;DR

A checkbox for a roboport such that all bots vacate it for manual deconstruction and automated population purpose.

What ?

I feel like the idea is self explanatory by this point but to describe it in further detail:
A (permanent) option to be enabled or disabled for individual roboports so that any bot currently inside the port (or placed inside it in the future) will leave the port and look for a new port to call their home. Similar to how bots behave if you place them by hand.
Of course, a port with this option enabled would not work as a housing port either though it can still charge bypassing bots.

Why ?

The why is twofold.
For one, it makes manual deconstruction easier. Currently when you pick up a roboport, you also collect all the bots inside it which you then have to manually place for them to be "live" again. This certainly isn't the most bothersome aspect all things considered so if it were just for that I honestly wouldn't make this post but it is a nice side effect.
The second and really main reason I feel this option would be beneficial is for the production of robots. Assembly lines need place robots in roboports for them to be live. If the port is full no new bots can be added. This can be mitigated by using belts and a large array of roboports but by and large you're just delaying it.
If a roboport could be set to immediately have bots placed inside it to move elsewhere (where ever that may be) it would allow for the assemblyline to work continuously only to be stopped by logistic networks when all roboports are full (Actually, I don't think there's a way to check for this yet but you could still add a fixed limit)

[bormand]

If the port is full no new bots can be added.

If the port is full, the bots are idle. It the bots are idle, there are no reason to inject more. You can buffer some in the chest, if you want.

The real problem is that roboport may be full of contruction bots, but you need more logistic bots. Or vice versa. But it happens quite rarely if you don't add bots too aggressively.

[Kyralessa]

You can use a logistics request to set the maximum number of bots that will stay in your inventory. The rest will go to trash, where they can be redeployed assuming you have a requester chest for them that deposits them in a roboport.

(For example, my main robo network is set to autoscale, adding new bots to a roboport from a requester chest whenever the number of available construction or logistics bots hits zero.)

So even if you deconstruct and end up with bots in your inventory, they don't have to stay there.

[ssilk]

You can remove robots from a roboport with an (filter) inserter. What’s missing is to know, how many robots are inside.

There is also another idea: a roboport can request robots. That works nearly like the buffer chest: if there are too less robots in a roboport it will request some from other roboports. The robots will fly themselves to that roboport. That will empty those roboports, that are “too full”.

[starlinvf]

You can remove robots from a roboport with an (filter) inserter. What’s missing is to know, how many robots are inside.

There is also another idea: a roboport can request robots. That works nearly like the buffer chest: if there are too less robots in a roboport it will request some from other roboports. The robots will fly themselves to that roboport. That will empty those roboports, that are “too full”.

I've been giving some thoughts to using pathfinding weights to have idle bots seek out or avoid certain roboports..... But theres a reoccurring issue of how to deal with large logistics networks, and how bots can end up across a factory, and then cross it again later due to how the request queue works.

This keeps coming back to the best solution being isolated networks. But that loses the flexibility when building new factory segments. For a while I was thinking of a bridge port to link Logistics networks together, favoring local supplies over remote ones. But as best as I can tell, nothing in Vanilla does something like that; and would need a bunch of things that are currently global to be broken down into network ID structures. If anything were a candidate to prototype this on, it would be electrical network priorities.

[ssilk]

Network priorities: low chance of implementation.

In the end this is kind of wanted side-effect: logistic bots are not useful for transport of large quantities of bulk material over large distances; therefore belts are much more useful.

If you use belts for those big transports the traffic goes down and the bots behave much better.

For building I would think for trains. Feed up with needed materials or automate them, I think that is the much more interesting challenge.

[foamy]

It'd be nice to have, basically, a roboport version of an active provider chest. As it is my usual answer is to have two roboports, one for logistics and one for construction, with filter inserters pulling the unwanted ones and reinjecting them into the correct port, and then supplemental stuff added from production based on the use %.

But a flat Go Forth! ejection option would be a lot cleaner.

[bormand]

It'd be nice to have, basically, a roboport version of an active provider chest.

Why do you want to overstuff your network with bots?

If they don't want to fly away, there are no job for them. And if all of them are accidentally parked into this port, you definitely have a serious problem with charging queue.

In properly working network this issue is rare. I seen overcrowded ports only during deconstruction, and you usually don't inject new bots during deconstruction.

[foamy]

It'd be nice to have, basically, a roboport version of an active provider chest.

Why do you want to overstuff your network with bots?

If they don't want to fly away, there are no job for them. And if all of them are accidentally parked into this port, you definitely have a serious problem with charging queue.

In general I trickle-feed in bots so long as my utilization is above 20% or so, so that my network is always consistently well-supplied with bots and can handle spikes in load (e.g. the player walking into log coverage or a construction project being ordered). As the number of bots in network climbs, though, it becomes possible to both want to have bots be loaded in and have the roboport you're trying to add to be full or nearly so, because the 'bots in use are being ejected from other stations.

As I said before, it works, but it'd be cleaner to set systems up if this were an option. It'd also mean no need for pulling the incorrect kinds of bots out of a roboport, too.

[starlinvf]

I kind of wish there was a way to set hot zones for them, just to have them automatically favor hanging around a central area when not needed elsewhere.

But then again... I mostly use bots for big bursts of activity. The rest of the time they're doing garbage collection stuff.

[ssilk]

Foamy: from my experience it is not better to feed the network with bots until all satisfied. Because then the bots needs more charging, which leads to longer queues at charging ports, which leads to longer transports, which leads to more demand on robots.