Add "No Item" to Roboport requests

[embermctillhawk]

Meta

Related but different prior suggestion; 689209

What?

nothingrobots.png (73.05 KiB) Viewed 1150 times

Why?

uncommonbots.png (74.61 KiB) Viewed 1150 times

Currently I use Uncommon Logistics Bots to force a Roboport to be empty.
This is the same underlying idea behind the Deconstruction Planner filter for Splitter trick; it's an impossible request that produces a desirable effect.

This works for me because I like playing with Quality.
This does not work in Factorio without Quality.
Without Quality, Factorio and Space Age only have 2 types for Roboport requests, and neither of them is practical to use as an impossible request.

Sure, we can keep on using a Deconstruction Planner as a menu-selectable item till the end of days for Splitters. That would be atrocious and honestly I'm shocked and disappointed that the linked suggestion hasn't already been implemented, but at least Deconstruction Planner is a slightly flawed answer, instead of no usable answer.

There is no usable answer without Quality.

Okay, but, why?

Roboport requests are primarily used to express "I want X bots in this area."
We should be able to express "I DONT want X bots in this area."

One use case of such an expression is "Roboports that are charging-only".
I know this is a desirable use case because there are popular mods (ex. Bob's Logistics Mod) which implement that.
What I'm saying here is that this is already possible with both community mods, and Quality.
It's even possible in base game by playing without one bot type, but that's a terrible solution, so let's fix it.

Note that this doesn't make modded charging-only ports irrelevant; they can have faster charging speed and more charging slots than a regular Roboport, so they still have a use.

Another use case is "Force Bots Into Network".
Currently, there is no way to automatically force bots into a network in the base game, except for doing the dumb thing and playing with only one bot type.
If you have both bot types, then it's possible that all slots in any Roboport you have set up to add bots to the network via Inserter are filled with the opposite bot type to what you want to add.

For example, let's say you have a moderately developed base with 10,000 logistics and 30,000 construction bots. You undertake a very large construction project, and all 30,000 construction bots are in the air. You may want to add more... but your logistics bots are currently relatively dormant, and too many of them have nested in the roboports being fed from your construction bot assemblers.

What are your options?

Well, if you are on the same surface, you can manually unjam the situation. But there should really be an answer that doesn't require you to be on the same surface, that was the whole point of the massive overhaul to Remote View...

You could use construction orders to unjam the roboports, hoping that some construction bot will randomly prioritize the unjam over the existing overloaded construction queue...

You could have a dedicated tank or spidertron sitting nearby with its own construction bots to unjam if you ever wind up in this situation... but that's basically just implementing a roboport where excess surplus from the main network can't fill it up and which excess demand cannot draw from. So, effectively a weird roboport which is forced to 0 bots. Where have I heard that before...?

You could use a filtered inserter to pull any undesired bots out, but that just kicks the can down the road because now you have to do something with these bots that happened to try resting in the wrong roboport, and the best thing to do with them is to re-add them to the network but in the right spot, which is what we're already trying to do in the first place...

You could set the bot request on the roboports to be only construction bots. That would allow you to be able to grow your bot swarm when it's highly stressed... but ONLY when it's highly stressed. You can't use this to gradually add more bots over time during low stress periods to prevent the high stress periods from happening in the first place.



Or you could skip all these complex answers and their downsides and just use an impossible request to say "No Bots Here".

TL;DR

"impossible item filter" already exists in the game for Splitters. Wube has already made it for Roboports with the Quality mod. Please add it to the base game for Roboports.

[Ranakastrasz]

The first thing I tried was to set a request for Max 0 robots, and it didn't work. That would probably be the most obvious way to do it, since it mirrors how all other logistic requests work.

Admittedly, you would then have to ban all robot types then.

[embermctillhawk]

The first thing I tried was to set a request for Max 0 robots, and it didn't work. That would probably be the most obvious way to do it, since it mirrors how all other logistic requests work.

Yeah, the way the requests work is that defines the minimum request. Like, if you set "50 logistics bots" then its equivalent to "50 minimum infinite maximum", so setting 0 robots of any type has basically no effect.

[macdjord]

Admittedly, you would then have to ban all robot types then.

Unless mods are involved, that's just 2 requests: Logibots, Any quality, Max 0, and Construction bots, Any quality, Max 0.

[mmmPI]

For example, let's say you have a moderately developed base with 10,000 logistics and 30,000 construction bots. You undertake a very large construction project, and all 30,000 construction bots are in the air. You may want to add more... but your logistics bots are currently relatively dormant, and too many of them have nested in the roboports being fed from your construction bot assemblers.

What are your options?

I feel you can use 2 different roboports to add bots in your network, one for logistic, one for construction , each with a request of 350 of their respective kind of bot, this way it's not possible for one kind of bot to nest in the wrong roboport and prevent the addition of new bots of of the other type.

If you think 350 bots of one kind is too low of a threshold you can use more than a single roboport for a bot type this way the addition of "construction bot" can be triggered when any drops under 350, so you would have at least 700 bots, or 1050 of a type to be idle before addition of new bots.

[embermctillhawk]

I feel you can use 2 different roboports to add bots in your network, one for logistic, one for construction , each with a request of 350 of their respective kind of bot, this way it's not possible for one kind of bot to nest in the wrong roboport and prevent the addition of new bots of of the other type.

If you think 350 bots of one kind is too low of a threshold you can use more than a single roboport for a bot type this way the addition of "construction bot" can be triggered when any drops under 350, so you would have at least 700 bots, or 1050 of a type to be idle before addition of new bots.

I already mentioned that solution here;

You could set the bot request on the roboports to be only construction bots. That would allow you to be able to grow your bot swarm when it's highly stressed... but ONLY when it's highly stressed. You can't use this to gradually add more bots over time during low stress periods to prevent the high stress periods from happening in the first place.

Sure, you can build more and more feeder ports to raise the growth trigger. But by the same token, you could also just scale up the bot extraction solution to decrease the likelihood of a jam. It's just kicking the can down the road still, whereas the impossible bot request simply works.

It'd be like building larger and larger fluid buffers for dealing with Advanced Oil Processing instead of any circuit controls. Like, yeah, it does literally work, but...

[mmmPI]

I already mentioned that solution here;

Ah yeah i didn't recognized it, i don't think it works only when it's highly stressed or is akin to building large buffer for the oil processing, because you build an automatic trigger and you have to dimension the threshold to your base and scale it up. And you can combine it with a buffer chest per robotport, so if you have 4 for construction bots, you could store 10K bots and still have some room to handle large bursts.

If you go this way , you can combine with requests of 50 bots or something on the regular roboports that you use for coverage so that there is no bots coming back to jam the area where you add them to the network, it allows to grow overtime the numbers of bots past the "emergency threshold" of 350 per safety roboports.

whereas the impossible bot request simply works.

Until it doesn't, this is essentially a mechanism to grow the number of bots "infinitly" if you don't control it, like feeding a purple chest from a miner. There are cases where you can do that, but it's also a risk if mishandled.

It makes sense though, it feels like factorio to offer tools that can overwhelm the player and jam if not handled properly, like the oil processing.

[Alfonse215]

If the goal is to be able to set a roboport to purge itself of bots, I think it would be better to directly expose this as a feature rather than through "request no item". This is mostly for discoverability.

It never occurred to me that I could purge a roboport of bots by requesting 350 bots of a type/quality that the network doesn't have. I would have assumed that other bots could still nest unless explicitly evicted by the other bot. I imagine I'm not alone in this.

As such, I think this should just be a switch on the roboport rather than requiring someone to know details of exactly how robot requests work.

[embermctillhawk]

If the goal is to be able to set a roboport to purge itself of bots, I think it would be better to directly expose this as a feature rather than through "request no item". This is mostly for discoverability.

It never occurred to me that I could purge a roboport of bots by requesting 350 bots of a type/quality that the network doesn't have. I would have assumed that other bots could still nest unless explicitly evicted by the other bot. I imagine I'm not alone in this.

As such, I think this should just be a switch on the roboport rather than requiring someone to know details of exactly how robot requests work.

Actually, I think you're right.

This is kindof an X-Y problem.

The problem being that bot requests don't work like regular logistics requests, where they have an upper limit. If an upper limit could be set, we wouldn't be having this conversation in the first place.

As-is, it's already possible to effectively set an upper limit, though limited to the granularity of stacks. 50 construction bots, 50 logistics bots, 250 uncommon construction bots, will cause a roboport to be limited to exactly 50 construction bots and 50 logistics bots. Well, with the Quality mod. Which is what this whole discussion is about, that the Quality mod provides a solution to a problem that shouldn't exist in the first place...

Yeah, honestly, just allowing an upper limit to be specified would be a cleaner solution.

[mmmPI]

But what is the purpose of purging a roboport from its robots ? to me it appears to be a tool to manage the distribution of robots in the factory and their addition overtime that works by pushing when currently the option are favouring pulling.

Presumably the upper limit would be set up to something like 150 of each types of robots on a single roboport, "always leaving room for insertion of new robots" because then robots exceeding that limit that would have been inserted from assembly would be requested to leave that roboport and relocate to another one. Or just clog weirdly in the sky if none is available, more and more as the assembly keeps feeding the roboport essentially acting like a purple chest now

As-is, it's already possible to effectively set an upper limit, though limited to the granularity of stacks. 50 construction bots, 50 logistics bots, 250 uncommon construction bots, will cause a roboport to be limited to exactly 50 construction bots and 50 logistics bots.

Why would you also request the 250 uncommon bots ? isn't the request of 50 bots of each type enough ? If your network is active , semi random movement and law of large numbers can distribute robots pretty well over the whole factory, there may be some "excess" at some point in time in some roboports, but is it that bad ?

The idea for me here was that the new roboports will be populated overtime "slowly", because you try to have "much more capacity" than robots, doing so means that the roboport you use for insertion from assembly are less likely to have their limits of 350 of a single type of bot filled, whereas when you don't use request on the "many roboport throughout your factory" but only the single 350 of one type for the insertion roboport, it becomes the priority nesting area for bots and they clog it immediatly.

If the combined number of requested bots from roboport throughout your factory largely exceed the number of bots you have in the network, then you have unfulfilled request pretty much everywhere except for the "very active places" but there you won't have that much "accumulation over the limit" , because there will be pending request of bots in plenty of other roboports so they will relocate naturally after the end of the "big construction project".

You can make it more than 50, like 150 of each type of bots, but then every roboport becomes more of a "large hangar" instead of a "small charging station", there is not as much "relocating" happening after a big project and it's less akin to what i feel you were refering to when mentionning modded robport with no docking capacity.

[Alfonse215]

Besides the obvious use case where you're inserting bots into a roboport or removing bots from a roboport (upgrading bots to a new quality; you don't want bots of the new quality to show up in that roboport), there are fringe uses.

For example, if you want to slow bots down from repairing walls damaged by attacks, you could use bot-less roboports near the walls. This forces bots to have to come from further away to repair the walls.

The OP mentioned that some mods provide charging-only roboports. I don't think that's meaningful here because most such modded tools are either cheaper than roboports, smaller than roboports, or provide more charging ports than roboports. That is, charging-only roboports are able to provide more charging ports in a given area. Purging a regular roboport of bots doesn't have that effect.

[worph]

But what is the purpose of purging a roboport from its robots ? to me it appears to be a tool to manage the distribution of robots in the factory and their addition overtime that works by pushing when currently the option are favouring pulling.

I actually just wanted to use this to keep bots from dying on Gleba.
They come to repair my tesla turrets and get sniped by strafers (very occasionally).
If I could forbid bots to rest in all but the closests roboports to the front lines I would probably lose even fewer, because the assault is over when they arrive.

But currently the entire roboport is filled with bots just ready to sacrifice themselves for a slightly damaged tesla turret.

grafik.png (7.35 KiB) Viewed 441 times

[mmmPI]

If I could forbid bots to rest in all but the closests roboports to the front lines I would probably lose even fewer, because the assault is over when they arrive.

Yes that's the very definition of "push", just set 0 request on the outer perimeter and not on the other roboports and bots will naturally relocate in a safer roboport after repairing your damaged turrets.

[mmmPI]

For example, if you want to slow bots down from repairing walls damaged by attacks, you could use bot-less roboports near the walls. This forces bots to have to come from further away to repair the walls.

You can achieve the same result by just not requesting any bots on the outer perimeter and having a combined request of bots on the inner roboport that is superior to your total number of bots.

[Alfonse215]

For example, if you want to slow bots down from repairing walls damaged by attacks, you could use bot-less roboports near the walls. This forces bots to have to come from further away to repair the walls.

You can achieve the same result by just not requesting any bots on the outer perimeter and having a combined request of bots on the inner roboport that is superior to your total number of bots.

This now causes a bunch of bots to hand out in those "inner roboports," rather than going where they would naturally congregate. And these roboport requests must be constantly updated when you add new bots.

Remember: the goal is not to keep bots in a specific roboport; it's to keep them out of a specific roboport. Using the former to achieve the latter is a fragile solution.

[mmmPI]

This now causes a bunch of bots to hand out in those "inner roboports," rather than going where they would naturally congregate. And these roboport requests must be constantly updated when you add new bots.

That's because you just mentionned the case where you don't want them to go in that place x) where you would have used the "no robots allowed to nest there", instead you can just request them elsewhere and it would work just fine. Have you tried it or is it just speculative ? How do you use the request for robots otherwise ?

Edit : Say you have 1000 roboport in your base, you could have up to 350 000 robots in them, but that would be very bad, they would lack charging capacity for a significant % to be active, and they would never find a place to rest. But if you have 35 000 bots, then it's fine, you have on average "35" bots per roboport, if you request 50 or each robots in most of your roboport, you force the 35000 bots to spread in at least 350 different roboports. So at worst you have like 35% of your roboports that are "unavailable" for bots to try and nest. But all the rest is free for them. And if wherever you don't request bots, say in corner of your base, or in a outer layer, then that create a "no nest zone", only charge, no hangar.

In such conditions, in an active network it is very unlikely statistically that the roboport you use for insertion reaches 350/350 of its own type of robots when you have around 700 other roboports that are trying to get "more robots". This allow to control the distribution of bots in the factory pretty well i found.

[worph]

This now causes a bunch of bots to hand out in those "inner roboports," rather than going where they would naturally congregate. And these roboport requests must be constantly updated when you add new bots.

That's because you just mentionned the case where you don't want them to go in that place x) where you would have used the "no robots allowed to nest there", instead you can just request them elsewhere and it would work just fine. Have you tried it or is it just speculative ? How do you use the request for robots otherwise ?

He is certainly right. Let's say I have 100 bots of each type and 20 roboports and I don't want either of the bots to go into 4 specific roboports.
Now I have several options
1. Request all bots in a single roboport (only works because we a dealing with such low volumes in this example). This may not be desired as now they always have to move from that one roboport back and forth no matter what. So this cannot be the solution.
2. Calculate the average number of bots for each of the non-excluded roboports (100each over 16 = 6.25 ~= 7). So we go and set each of the other roboports to request 7 of each bot. Now this likely work much better than solution 1 during live play after you set it up, but it is still bad. You need to configure every single roboport. Once you add new roboports it likely will break in some fashion. It certainly will break once you increase the number of bots (and most people keep putting robots into their networks). And setting it up is horrible, especially once you have a big network.

The clearly superiour solution would be to allow the interface, like it is with normal item requests, to set an upper limit. And then everything above that number is trashed (edit: poorly worded; every bot above the threshold moves out or is not even allowed to land in the first place).

[mmmPI]

He is certainly right. Let's say I have 100 bots of each type and 20 roboports and I don't want either of the bots to go into 4 specific roboports.

You request 50 bots of each type in every roboport except those 4.

Why would you care to calculate the average ? that's not what the suggestion is about ( i mean it's obvious here there is enough room for robots lol )

[Alfonse215]

He is certainly right. Let's say I have 100 bots of each type and 20 roboports and I don't want either of the bots to go into 4 specific roboports.

You request 50 bots of each type in every roboport except those 4.

And every time you add bots to the network, you have to update the roboports that request them or add new roboports that request 50 bots. And if you add roboports without adding bots, you have to decide which ones should request and which ones shouldn't.

Or you can just put the setting on the roboports that matter. The ones you don't want bots nesting in. It makes absolutely no sense to do this by setting every other roboport.

It should be noted that the game engine can already handle this functionality. If you request bots that don't exist in the network, it effectively reserves those slots and will not allow different bots to land there.

The question is whether there should be a more intuitive way to access the functionality which already exists. We're just talking about a more reasonable way to do what can already be done.

[mmmPI]

He is certainly right. Let's say I have 100 bots of each type and 20 roboports and I don't want either of the bots to go into 4 specific roboports.

You request 50 bots of each type in every roboport except those 4.

And every time you add bots to the network, you have to update the roboports that request them or add new roboports that request 50 bots. And if you add roboports without adding bots, you have to decide which ones should request and which ones shouldn't.

No you don't have to do that, bots can be added automatically by assembly+inserter connected to a roboport.

You don't have to do anything when you add a roboport you don't need to add bots at the same time, you can copy paste the settings from another one which shift click, or use a blueprint if you want to. If you don't it doesn't matter, it would just be a roboport where robots won't nest in normal operation, it will still provide coverage and charging capacity.

It makes absolutely no sense to do this by setting every other roboport.

Agreed ! Glad you don't have to do that x) It doesn't appear to me that we're one the same page regarding what needs be done, why and when.

You don't have to have such setting on every other roboport, you only have to have a higher total request than your number of robots to make sure they wont go where they aren't requested. Which makes sense only if you want robots to avoid "some" roboport and stay confined necessarily to "some others" . This way you can make sure your assembly that adds new robots to the network can do so slowly overtime. It won't get clogged by another type of robots, nor will it stay clogged with its own type of robots. That's the use case from OP. That's not the use case of " i want to prevent my robots from being in my defense perimeter because i like them to arrive late for repairing the wall", i do not consider this one to be the initial motivation of the suggestion but rather some made up illustrative situation for the sake of the discussion which hardly make sense in game but even this can still be achieved in practice.

For the original use case :

If you set the request to say 300 logistic to that one roboport where you add them from the assembly, when the inserter will add the 301, it will go to another roboport where it is requested (if you have such request in other roboports the first place). You are pulling the robots from the insertion zone into a defined location using other requests, instead of pushing them away " somewhere else ".

Problem: you can have 50 logistic bot there, on top of the 300 construction bot, which would prevent the insertion of a 301.

Naive solution : you request 350 construction bots. That's naive because if you (only) do so and that's the only place where you request robots in your whole factory, then that creates a "nest in priority there" request and it will clog the roboports , preventing future insertion from the assembly.

more in depth solution : You add other requests throughout your base, so that robots are not forced to nest back into the insertion area.

You CAN request in EVERY single other roboport, a precise amount or whatever the details. But you don't have to. As long as the number of request exceed the number of robots, you don't even have to request 350, you just request 300 bots of one type in a roboport that serve for the purpose of inserting new robots, and you are sure there will room there for the 301, because the robots from the other type will be trying to fill in the spots where they are requested. And that additionnal bot too.

The question is whether there should be a more intuitive way to access the functionality which already exists. We're just talking about a more reasonable way to do what can already be done.

No no, i'm trying to adress this :

You could set the bot request on the roboports to be only construction bots. That would allow you to be able to grow your bot swarm when it's highly stressed... but ONLY when it's highly stressed. You can't use this to gradually add more bots over time during low stress periods to prevent the high stress periods from happening in the first place.

To me, you CAN use requests to gradually add more bots over time during low stress periods to prevent the high stress periods from happening in the first place. This doesn't feel like a problem in my games, to me it's "solved" thanks to the requests.

This even without having the tool "purge roboports", which in case the suggestion is not implemented i think could still be useful for any factorio players facing the problem OP mentionned. So i'm willing to explain the methods i think works fine for me. I'm repeating there but i see the suggestion as essentially a "puple chest" roboport, i'm not necessarily against it in itself, it's "equally" risky , and could be made more "intuitive to access" as you call it, but when reading the use-case, i feel current tools ( maybe used a bit differently than in OP ) can achieve it.