Add "No Item" to Roboport requests

[quineotio]

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

Just have a check box for "Charging only".

[mmmPI]

Or just don't request robots only in the roboport that is fed by the assembly ^^

[worph]

Or just don't request robots only in the roboport that is fed by the assembly ^^

The interface is already there. There is a slider where you can select the number of bots. All we are asking for is that this can be set to an upper limit or something similar.
We understand that you disagree.
But having to configure machineB to get the desired effect on machineA is inherently bad design, I think that should be obvious at like a deeper philosophical level. No matter if it's the only currently working solution, that is exactly why we want something more elegant (and reliable).

[mmmPI]

The interface is already there. There is a slider where you can select the number of bots. All we are asking for is that this can be set to an upper limit or something similar.
We understand that you disagree.
But having to configure machineB to get the desired effect on machineA is inherently bad design, I think that should be obvious at like a deeper philosophical level. No matter if it's the only currently working solution, that is exactly why we want something more elegant (and reliable).

Have i said i disagreed ?

I only mentionned that the problem this is meant to adress can already be adressed by using properly the requests in case it was missed by players which apparently is a necessary reminder not only for OP but also for others like you who seem to misunderstand and overcomplicate how to use the limit. I asked you why you would calculate the average but you didn't answer, i thought you had realized how the method you were describing were needlessly convoluted but didn't want to admit it.

I literally said i had no problem if you want to have a roboport act like a "purple chest" for robots, but since to me it appears to comes from misunderstanding of the tools available, i don't expect this suggestion to be implemented, the tools are already there and visibly it need be explained to some players which may end up like OP not realizing it. Currently robotport act like "blue chest", or "yellow chest", if you want nothing to sit in your yellow chest you indeed configure something somewhere else to achieve the result. Hopefully this comparaison makes it easier to understand.

[worph]

[...] the tools are already there and visibly it need be explained to some players which may end up like OP not realizing it. Currently robotport act like "blue chest", or "yellow chest", if you want nothing to sit in your yellow chest you indeed configure something somewhere else to achieve the result. Hopefully this comparaison makes it easier to understand.

This is where I disagree.
The request interface for robots is a just an intentionally constrained version of the normal item request-interface.
All I am asking for is that the normal request interface is applied here, too, so I can set an upper limit.

grafik.png (36.18 KiB) Viewed 797 times

grafik.png (99.14 KiB) Viewed 797 times

[mmmPI]

This is where I disagree.
The request interface for robots is a just an intentionally constrained version of the normal item request-interface.
All I am asking for is that the normal request interface is applied here, too, so I can set an upper limit.

Yeah and in every suggestion there is a "why" , so far, there is one from OP which appears to differs from yours that i understood as willing to setup bots so that they arrive late to repair the wall due to not being allowed to rest near where they are needed for repair to prevent them from getting hurt in the repair process.

OP mentionned a desire to be able to grow slowly overtime the number of bots.

Both are possible currently, if any players find this suggestion because of the same use cases but are more willing to solve their issue with their factory than argue over the method that should be in the game to do so, they can by using requests higher than the number of bots, there won't be bots standing where they aren't requested.

[worph]

Just for the record: Your solution works perfectly fine in the current version and I immediately implemented it after I reading this message (two days ago):

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

My roboports are requesting 50 or 100 or whatever number of bots in every roboport except those that shouldn't have any. Perfectly reasonable in terms of functionality. I simply forgot to mention that, mea culpa. No ill intent. My disagreement has nothing to do with being "unwilling to solve the issue" in my current game or whatever.

I am simply suggesting something more intuitive using already existing and well understood UI-elements. So that in the future, when somebody tries to do the same thing they don't have to look through the forums for a bit of an unintuitive workaround (frankly).

[mmmPI]

Just for the record: Your solution works perfectly fine in the current version and I immediately implemented it after I reading this message (two days ago):

Well thanks for saying out lout, and also congrats, because reading the thread again, i have to admit that, it wasn't well explained from my end :

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.

But that's already what OP was doing, when really what mattered more was the configuration of the "other" roboports. And if they do request robots, then a request of 350 bots in those roboports used for insertion isn't necesarily a good idea, it's better in this context maybe to request "less" so that the bots added mechanically by the assembly that exceed the amount that the roboport is requesting are not compelled to stay in the roboport but on the opposite, are called in other roboports and leave the insertion area "not-clogged". ( or any other area where bots aren't welcome ).

There can still be bots that nest in area where they aren't requested over the course of the game, when you have a drop in robot activity, because the requests maybe were fullfilled or close to be with XXXX amounts of bots in the air, and suddenly those all turn idle, and now you have an excess, in my games i also have used chest to remove the robots from the roboport in the insertion area when there are too many idle and they are re-injected them during stress period.

I am simply suggesting something more intuitive using already existing and well understood UI-elements. So that in the future, when somebody tries to do the same thing they don't have to look through the forums for a bit of an unintuitive workaround (frankly).

I understand this as a sligthly different direction, where the previous part was about "what is a available currently" where i had a disagreement, and this is more about the pros and cons of the suggestion itself, even though i think it would be somewhat redundant and as such unlikely, i have no objection to it being in the game, sometimes redundancy is a positive. It would be "like a purple chest" as in another method to deal with the problem, another way to shoot one-self in the foot too if mis-managed, when thinking about that i feel that's the fun in the game.

I agree that the UI and the "what it does when i click this" would be intuitive from the perspective of a experienced player, it's familiar, and it would not add clutter.

It's a bit less intuitive to me how you would use it at scale. I don't mind a discussion about the method that should be in the game, how would it be different than "current method" but i felt it couldn't happen if we already disagreed on what was the "current available methods". The "trash excess bots" / suggestion, seem intuitive to me at the insertion area, you want to push the bots away from there to keep adding some more. But eventually you may also need a mechanism to prevent your network to be congested with 350 bots in every roboports no ? or is the timeframe required for this to happen is generally "unreasonnably far" in your games ? I feel reading the total number of bots and counting roboports from the electric stats to eyeball a ratio would be necessary to know when to stop the addition of new robots with the suggestion. no ?

Where i find the current request system "intuitive" in a way, is that they function like "the rest of the factory", in that if the "consumer"/"requester" has enough, it backs up and it automatically stops the assembly lines, if you only add roboports with request, you make it 'easy' to "keep the ratio", to not overfill your network. ( with the caveat that there may be slight excess sometimes).With the suggestion, i'm not too sure how i would do, or which way i would recommend.

[macdjord]

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.

Of course, doing this means you can't use bot request for what they're actually intended for, i.e. making bots go to particular place. Got a mall and want to make sure the roboports near it have lots of construction bots in them, ready to pick up items and head off the moment you slap down a blueprint? Sorry, you've already got more bot requests than bots, and there's no way to prioritize the ones near the mall any further.

[mmmPI]

Of course, doing this means you can't use bot request for what they're actually intended for, i.e. making bots go to particular place. Got a mall and want to make sure the roboports near it have lots of construction bots in them, ready to pick up items and head off the moment you slap down a blueprint? Sorry, you've already got more bot requests than bots, and there's no way to prioritize the ones near the mall any further.

No, if you want bots in the mall and not in the construction area, you just request bots in the mall and not in the construction area. The way to prioritize is to use a higher request where you want more bots. As long as you request more than you have, you know the places that do not request won't have bots in them. If you have a place like a mall where know you want the bots to gather that is different than the area where you add them, then that is in this mall that you request them, make sure the request is large enough and bots won't wander around in undesirable places.

How would you make sure the bots goes in the mall otherwise with the suggestion ? you would also have to .... request them in the mall ! Same thing, try it out ^^

[macdjord]

Of course, doing this means you can't use bot request for what they're actually intended for, i.e. making bots go to particular place. Got a mall and want to make sure the roboports near it have lots of construction bots in them, ready to pick up items and head off the moment you slap down a blueprint? Sorry, you've already got more bot requests than bots, and there's no way to prioritize the ones near the mall any further.

No, if you want bots in the mall and not in the construction area, you just request bots in the mall and not in the construction area. The way to prioritize is to use a higher request where you want more bots. As long as you request more than you have, you know the places that do not request won't have bots in them. If you have a place like a mall where know you want the bots to gather that is different than the area where you add them, then that is in this mall that you request them, make sure the request is large enough and bots won't wander around in undesirable places.

How would you make sure the bots goes in the mall otherwise with the suggestion ? you would also have to .... request them in the mall ! Same thing, try it out ^^

Yes, if I want bots in the mall, I have to request bots in the mall. But - and this is the neat part - as long as I don't already have more bot requests than bots, they'll just show up! Like magic! Whereas with your idea, since you have more bot requests than bots, there will always be some requests that go unfulfilled, and you have no way of controlling whether those absences happens in your mall (where you actually want bots to always be) or in your construction area (where you don't really care where the bots are, as long as they're not in the ports that are right next to the walls).

[mmmPI]

Yes, if I want bots in the mall, I have to request bots in the mall.

Very good. I think that's it. Request more than you have there and voila. Why would bots not show up ?

[Alfonse215]

Yes, if I want bots in the mall, I have to request bots in the mall.

Very good. I think that's it. Request more than you have there and voila. Why would bots not show up ?

Because requests don't have a priority system.

The default logic of a bot that has finished a task is to go to the nearest roboport. I don't know precisely what the logic of a bot is when requests are available, but I suspect it is "go to the nearest roboport with an open request for my bot type".

The whole point of requesting bots is to make sure that bots go there rather than somewhere else. So ideally, you use requests where you want bots to go.

The idea you're talking about is to use requests everywhere, except for where you don't want bots to go. Well, if everywhere is a requester... nowhere is. And since requests don't have a priority system, there's no way to force bots to show up in a specific location if there are closer roboports that have open requests.

So if most roboports are requesting, bots will basically go to any roboport, even if you have more requests near your mall. They'll only go to your mall if every roboport between where they finished and the mall has no open requests. Which could be hundreds of request slots.

Making most roboports request bots is a poor solution to the problem of keeping bots from going to specific roboports.

And I again remind you: the ability to make bots never go to a specific roboport already exists. It's part of the engine. It's just not in a convenient form.

[mmmPI]

Because requests don't have a priority system.

Check this out :

Say you have 10 000 bots in your network. Request 12 000 in mall , and voila. The bots will show up on the mall , and nowhere else.

But i have 2 malls !

Easy , request 6000 in each mall.

No i have 10 malls and when i request 1200, there is a risk one of my mall doesn't have any robots because 9 mall are requesting 10800 and i only have 10000 robots.

Correct you see the problem, you're streching the system, you need to request at most 1111 robots per mall.

Still more than you have total robots,( 10*1111 > 10000 ) to make sure they don't wander in undesired places. But NOT so much that it can deprive any of your mall from robots. 9*1111= 9999 = 1. So All your malls will have at least 1 robot. If you request 1100 robots per mall, then 9 of them can at most hold 9900, and you have 10K bots, so there will be .... 100 in the least filled mall.

And I again remind you: the ability to make bots never go to a specific roboport already exists. It's part of the engine. It's just not in a convenient form.

I mentionned plenty times i am not against the suggestion, but i think you forgot its purpose : What is the goal of the suggestion ? : To have a way to increase over time the number of bots in the factory without them clogging the roboport in which you insert them from the assembly.

You don't need to "push" them away from that roboport, you can "pull" them where you need them with a set of request that always exceed, the amount of bots you have.

IF you want to also make sure every roboport that request robots get served the most precise amount, you make that excess the smallest possible. Smaller than the smaller request.

It's needlesly complex, but possible, just for the sake of the demonstration, as that was never the goal of the suggestion. Rather the suggestion was intended for a purpose that match more likely the case where you can have a large request on your mall, so your production area isn't clogged. Or you request in every roboport a little, if you don't have a mall to act as the area that can take the bots away from the production area.

[macdjord]

Because requests don't have a priority system.

Check this out :

Say you have 10 000 bots in your network. Request 12 000 in mall , and voila. The bots will show up on the mall , and nowhere else.

But i have 2 malls !

Easy , request 6000 in each mall.

No i have 10 malls and when i request 1200, there is a risk one of my mall doesn't have any robots because 9 mall are requesting 10800 and i only have 10000 robots.

Correct you see the problem, you're streching the system, you need to request at most 1111 robots per mall.

Still more than you have total robots,( 10*1111 > 10000 ) to make sure they don't wander in undesired places. But NOT so much that it can deprive any of your mall from robots. 9*1111= 9999 = 1. So All your malls will have at least 1 robot. If you request 1100 robots per mall, then 9 of them can at most hold 9900, and you have 10K bots, so there will be .... 100 in the least filled mall.

Great! So now literally all you bots are located in the malls. So every job anywhere else in the base takes forever, because there are never any idle bots nearby; they've all flown off to the mall as soon as they finished whatever job they were assigned.

This is as opposed to what happens normally, which is that idle bots tend to end up somewhere near where they finished their job. That's exactly what you want, generally, because areas that had a lot of jobs in the past are likely to have lots of jobs in the future! Of course, there are exceptions, such as the mall itself, which tends to have a lot of jobs start there but very few end there. Which is exactly what bot requests handle; you can set them to ensure some - but not all - of your otherwise idle bots make their way to where you expect to need them before they are needed.

Yes, using bot requests elsewhere to keep certain roboports empty can be done, but there are always huge tradeoffs. Either you have considerably more total requests than you have bots, in which case requests in places you actually want bots to be no longer work reliably, or you carefully manage it so that your total number of bot requests is always nearly exactly equal to your number of bots, in which case you have to micromanage the system constantly every time the number of bots or the number of actual I-want-more-bots-here requests changes.

[mmmPI]

Yes, using bot requests elsewhere to keep certain roboports empty can be done,

That's my point, it can be done currently, that's what is missing from the OP as options imo, that solve the problem mentionned by OP for me in my games.

This is as opposed to what happens normally, which is that idle bots tend to end up somewhere near where they finished their job. That's exactly what you want, generally, because areas that had a lot of jobs in the past are likely to have lots of jobs in the future! Of course, there are exceptions, such as the mall itself, which tends to have a lot of jobs start there but very few end there. Which is exactly what bot requests handle; you can set them to ensure some - but not all - of your otherwise idle bots make their way to where you expect to need them before they are needed.

I'm not sure if you are doing it in on purpose or not seeing it at this point x). In no way you need ALL you bots to be in your mall x)

Like you have 10 000 bots, you have 2 malls, you can request 6000 in each, then yes they are all requested so they will all end up in your mall.

If you only request 4500 in those , in total that makes it 9000, waow that means you now need to have "some request" of say 50 bots in at least 20 of your roboport in your base .... to make sure you request "all" bots. That's the same of having 10 malls except 1 is much bigger and the other have lower priority. Those "request" are used to spread bots in loction where they are likely to have lots of job in the future ! That's a "pull" system, as opposed to a "push" system, that's indeed what the request are intended to do, and it can be used for that purpose ! And even more , it can also be extended to be used for excluding some roboport, by default.

You don't have to be super precise, you can request 50 bots in between 20- and 80 or so roboports . Then it's possible all the bots find to nest outside the mall so you increase the request in the mall.

[mmmPI]

How you can handle bot insertion in a factory : have a mall where you insert robots in roboports, and request a desired amount of robots for your purpose in there. Say 300 logistic and 300 construction in 2 different roboport. Limit the insertion when bots > 301. In game when expanding add roboport that request "50" of each type of bots whenever you add roboports.

If you add 10 right away , you create a "500" hole, that's bigger than the mall, that's "risky", you dimension the mall and their request accordingly.

[Alfonse215]

Because requests don't have a priority system.

Check this out :

Say you have 10 000 bots in your network. Request 12 000 in mall , and voila. The bots will show up on the mall , and nowhere else.

The goal of requesting bots at a mall is not to exclude them from being "nowhere else". It's just to make sure that some bots are always available at the mall.

And I again remind you: the ability to make bots never go to a specific roboport already exists. It's part of the engine. It's just not in a convenient form.

I mentionned plenty times i am not against the suggestion, but i think you forgot its purpose : What is the goal of the suggestion ? : To have a way to increase over time the number of bots in the factory without them clogging the roboport in which you insert them from the assembly.

No, the goal of the suggestion is to have certain roboports be empty of bots. There are several use-cases for this functionality; insertion after construction is just merely one such use case.

What about keeping perimeter roboports empty so that bots are less likely to be killed when making repairs (they have to go farther so they're unlikely to jump into the middle of a battle in progress)? Doing it your way requires spreading requests to every non-perimeter roboport and making sure that you never add more bots than you have requests.

And let's see what happens when you combine these two use cases.

Let's say that you want perimeter roboports to be empty. And you want the insertion-target roboport(s) to be empty. And you want (at least) 200 construction bots to be at the mall. And you want 600 construction bots in the system in total.

With the desired functionality, you simply request the 200 construction bots in your mall like normal, then designate the perimeter and insertion-target roboports to be empty. Given this, if you have 600 construction bots, 200 will be in the mall area, and the other 400 will scatter themselves around various roboports, but never into the purged roboports.

This is the state of affairs that is desired: 200 near the mall, none in the purged roboports, and 400 wherever they happen to land.

Your method cannot achieve this. At the very least, you have to pick specific roboports for those 400 to go to, instead of letting the internal logic take care of it (which is usually useful).

And of course, if you insert just one bot without updating some requests somewhere, the system breaks down. So anytime you need to up the number of construction bots, you must up the number of requests accordingly.

[mmmPI]

What about keeping perimeter roboports empty so that bots are less likely to be killed when making repairs (they have to go farther so they're unlikely to jump into the middle of a battle in progress)?

I think the user that was mentionning this use case was able to solve their problems :

Just for the record: Your solution works perfectly fine in the current version and I immediately implemented it after I reading this message (two days ago):

With the desired functionality, you simply request the 200 construction bots in your mall like normal, then designate the perimeter and insertion-target roboports to be empty. Given this, if you have 600 construction bots, 200 will be in the mall area, and the other 400 will scatter themselves around various roboports, but never into the purged roboports.

Yeah that's another way, but it's not in the game, and when listing the options in OP it appeared that what i do just fine in my games wasn't listed, hence why i explain that it can be done currently in game. I do understand the suggestion and even said i was not against it. I think you are not undertanding what i explain.

This is the state of affairs that is desired: 200 near the mall, none in the purged roboports, and 400 wherever they happen to land.
Your method cannot achieve this. At the very least, you have to pick specific roboports for those 400 to go to, instead of letting the internal logic take care of it (which is usually useful).

So the answer is "YES IT CAN" , and you could even have that internal logic too ! if you request the same in every non mall and non excluded roboport. It's not my method lol anyone can do that, it's commonly used, at least i've seen that couple times in multiplayer. It don't feel the method is the problem, nor my ability to explain at this point. You can in fact create a system to slowly increase the number of bots overtime while having some roboport never hosting any robots and not clogging the insertion area. I understand the system doesn't appear straightforward for you, you don't want to consider the idea that you could be using blueprints to build roboport, that's fine, i understand your position is more radically in favor of the suggestion not just because you see it as an alternative but because you seem unable to understand/use the current possibilities, that's kind of a demonstration you're making, but it's kind of unecessary i feel, because obviously you're not going to convince me that what i use in my game is impossible x), and i'm already not "against" the suggestion.

[Alfonse215]

Yeah that's another way, but it's not in the game

It is in the game. To purge a roboport, simply request robots that aren't going to be put into the network, like uncommon construction bots or something.

What we're asking for is a less convoluted way to say the same thing.

So the answer is "YES IT CAN" , and you could even have that internal logic too ! if you request the same in every non mall and non excluded roboport.

I just did at test. I created 2 roboports, one with a request for 50 construction bots and one with a request for 100, both in the same network. I added 10 construction bots to the network. The desired behavior is that the 100 requesting roboport has more bots than the 50 requesting roboport.

I placed something at the end closest to the 100 request roboport. The bot flew there, placed the item, and went to the 100 request roboport: the nearest one with an open request.

I placed something at the end closest to the 50 request roboport. The bot flew there, placed the item, and went to the 50 request roboport: the nearest one with an open request.

I repeated the experiment with a non-requesting roboport and a 50 request roboport. In both cases, the bots when to the 50 request one. Which was the desired behavior.

I fail to see how "YES IT CAN" when it clearly did not have the desired behavior. The only way to make it work is to have precisely 150 bots in the network. Which means that you must maintain a 1:1 ratio of bots to requests.

I understand the system doesn't appear straightforward for you, you don't want to consider the idea that you could be using blueprints to build roboport, that's fine, i understand your position is more radically in favor of the suggestion not just because you see it as an alternative but because you seem unable to understand/use the current possibilities, that's kind of a demonstration you're making, but it's kind of unecessary i feel, because obviously you're not going to convince me that what i use in my game is impossible x), and i'm already not "against" the suggestion.

I'm not sure the passive-aggressiveness is warranted here. The setup you're talking about is cumbersome, requires a bunch of specialized blueprints for roboports, and needs a way to constantly add or remove bots based on whether you've added or removed roboport requesters (which is not something supported in the game, so you have to build a system to do that).

The idea that this added complexity is absurd when we already have the desired functionality is very bizarre.