Add "No Item" to Roboport requests

[embermctillhawk]

Meta

Related but different prior suggestion; 689209

What?

nothingrobots.png (73.05 KiB) Viewed 617 times

Why?

uncommonbots.png (74.61 KiB) Viewed 617 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.