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 263 times

grafik.png (99.14 KiB) Viewed 263 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.