Read robot requests in circuit network?

[foxoftheasterisk]

Hi, I'm trying to use robot requests to control the amount of robots in my network. I want to insert robots if the number of requested robots is more than the total number of robots in the network (or possibly some other, related ratio). However, it doesn't seem that I can send the robot requests to the circuit network? Does anyone know of a way to do this (including using mods)?

(If not, consider this a feature request, I guess.)

[eugenekay]

While you can use the “Read Logistic Requests” mode of a Roboport to estimate how many Logistic Bots are needed; there is no equivalent for the Construction Requests. I usually just use the “Read Robot Statistics” mode, and some multiple of the Number of Roboports to determine the Bot auto-deploy limits.

In previous Feature Request posts it has been listed as are difficult-to-implement, because of the way in which Construction Jobs are queued. It would apparently either be very slow, or very inaccurate. There is a Ghost Scanner Mod which attempts to implement this functionality anyway; it has not been updated to 2.0.

Good Luck!

[mmmPI]

I think what you need to do is use a constant combinator and use the same logistic group to set up the number of requested robots. This means if you change the number of requested robots in a robotport, the constant combinator value will also update. Not sure i understand the use case though.

[mmmPI]

While you can use the “Read Logistic Requests” mode of a Robotport to estimate how many Logistic Bots are needed; there is no equivalent for the Construction Requests. I usually just use some multiple of the Number of Roboports to determine the Bot auto-deploy limits.

Ah this is why i'm not sure i understood the question, i think it was refering not to "read logistic request" but rather "robot request" the thing that makes robots of say "low quality" to be requested so that you can easily upgrade the quality level of the bots in a network by forcing them to dock in a specified roboport ( and extract them )

[eugenekay]

While you can use the “Read Logistic Requests” mode of a Robotport to estimate how many Logistic Bots are needed; there is no equivalent for the Construction Requests. I usually just use some multiple of the Number of Roboports to determine the Bot auto-deploy limits.

Ah this is why i'm not sure i understood the question, i think it was refering not to "read logistic request" but rather "robot request" the thing that makes robots of say "low quality" to be requested so that you can easily upgrade the quality level of the bots in a network by forcing them to dock in a specified roboport ( and extract them )

Could be either one - I took a guess and gave my best answer. I hope it’s helpful either way.

[foxoftheasterisk]

While you can use the “Read Logistic Requests” mode of a Robotport to estimate how many Logistic Bots are needed; there is no equivalent for the Construction Requests. I usually just use some multiple of the Number of Roboports to determine the Bot auto-deploy limits.

Ah this is why i'm not sure i understood the question, i think it was refering not to "read logistic request" but rather "robot request" the thing that makes robots of say "low quality" to be requested so that you can easily upgrade the quality level of the bots in a network by forcing them to dock in a specified roboport ( and extract them )

Yes, that. I wanted to know the total number of each kind of robot that is requested by all roboports in the network. Rather than do as I've done in previous games, add robots whenever all robots are busy (and end up with way too many robots and a network that eats all my electricity).

[mmmPI]

Yes, that. I wanted to know the total number of each kind of robot that is requested by all roboports in the network. Rather than do as I've done in previous games, add robots whenever all robots are busy (and end up with way too many robots and a network that eats all my electricity).

I think what i've mentionned earlier cannot solve the use case you describe if the network is setup with "robot request" in every robotport though. First because I don't see a way to read in circuits the number of roboport without manual update and second, because even if that was doable and you could multiply by the request of 1 roboport to sum up all the requested robots automatically, that wouldn't mean real robots, just request, maybe unfullfiled ; So i don't see how this could be used to manage the number of actual robots in the network. It was just a way to do something close enough that it would be the same for some situations, "reading a robot request in circuit".

Instead for the use case of limiting the total number of robots in a network, i would recommend using robot requests only in a single roboport, to make sure that particular one is always filled with a few robots that can be removed from the network when the number of idle bot is "too large". Which you would math out using the other statistics readable from roboport.

Something like if more than 1000 idle robots, inserter take some away from that single robotport with request set-up and put them in a chest. Other robots from elsewhere in the network will replace those because of the request, and if there are still more than 1000 idle robots it will continue. This, in addition to a mechanism to insert those robots back into the network if the number of idle robots becomes less than 500, would allows for the numbers of robots to scale dynamically over the course of the game.

[foxoftheasterisk]

That's a well-designed system, but it doesn't nearly cover my use case. I want to use robot requests to distribute robots throughout my network, and I want to have a number of robots in the system to make sure those requests stay fulfilled, without adding an excessive amount. Only having requests in a single roboport is pretty close to the opposite of that.

I appreciate the thought, though. Anyway, making a feature request, since it doesn't seem to be that I'm just missing something obvious.

[mmmPI]

That's a well-designed system, but it doesn't nearly cover my use case. I want to use robot requests to distribute robots throughout my network, and I want to have a number of robots in the system to make sure those requests stay fulfilled, without adding an excessive amount. Only having requests in a single roboport is pretty close to the opposite of that.

Ohhhh i think i finally understand.

I appreciate the thought, though. Anyway, making a feature request, since it doesn't seem to be that I'm just missing something obvious.

Yep, i don't think there's an obvious way. You could maybe use a constant combinator next to each roboport in a blueprint so everytime you add a roboport you also have an 'fake' interface for the requests and connecting those contant combinator with wire or radars to read the aggregate requests, not super handy.

Or still use a logistic group for "robot request" and use the GUI to read yourself as a human the number of entities using those groups, and update it from time to time in a constant combinator to do the multiplication with the amount of robot from one set , at a place that can add robots in a network, not super handy either.

[eugenekay]

I usually just use the “Read Robot Statistics” mode, and some multiple of the Number of Roboports to determine the Bot auto-deploy limits.

08-17-2025, 10-47-53.png (40.88 KiB) Viewed 78 times

This is pretty easy with a Homogenous Roboport network (you are using a Blueprint to place all your Roboports, right? ). If you know the Capacity of the per-Roboport Logistic Request Group (ie: Logistic Robot-Rare x5 + Construction Robot-Rare x2); and you know the "Roboports in Network" value, you can Calculate the number of Robots that the Network is short/over:

08-17-2025, 10-49-13.png (620.98 KiB) Viewed 78 times

0eNrNWN9v2jAQ/leYn7bJqXBIgKB1L+1LJV5W7WWqUBTIlVpL4tR22qGK/31nB4j4HdIO9oRj332++86+8/FGxkkBueSZJoM3wiciU2Tw8EYUn2ZRYuayKAUyIFKMRS6kJnNKeBbDHzJg8xElkGmuOZRa9mMWZkU6BokCdKmtNEDiTJ5AaUJJLhTqiMzAI47bbl/5lMxw1Lny53O6BeTWBXKPAHVWQJHk+ikFzSfORKRjnkVayF2QXgVIScwlTMplhkYhXVqKJBzDU/TCUR+VKuAQl2MLpszCI5dKhxWxepYbQ1641AXOVC5aCefGMK3AYNRX+mmURA4yKo0kDoqIQufFaTsjdyRPohnIMAY1kTxf4N1CoqPWPR4G3boRRWbOwxbL3uksdy/E8v1Olhcy5jZoWVhTHHMB9Ca9X5vRS9fMDDPQr0L+tvZLiMkANwVKphIAN3mMEgWbVm7rWLGVkkE4FEWFFMfH4uivTH+MlHZ4pkBqkAdvsLcZwf7uAE64nBRch5BF46TyeTm9CmrTm2NjF5m05vht85nmkbSnb0C+kbkNQYLOlIlrmdHoodBjtisUhCs9y/E2a936rLnrrF2Wpy2avts8sOVfj27VhC3XWOCWjvVwCwnPBebrirg3c5YXN3aN/IMhScSUK5NJynBQ8oxOoWG4lAmZWgfX7L+2E0Xpm3FkAekeivKpsCNz5USR48ID15BeL0kZ4YHZRV+/Fn3dc9JXZOhgirt/NIH1gPdSSBdI10ucfZwGNTjF21ZxuuumSYji0OyvwlTECNam5Zz1K8RboleX/gxBkZGEQ7w1icdRzOOhMBD7wsDa64ZgWjlW9pcJsLc3AVa0XiBt/JuscTRp7K7atlorB58fzv1CvvX5R7lv626K+0L86cuuQs5Y3ZrEArYMSbD7Cc3c+lj+MaxOgxdGcIlaOfyAN8XGSaz7nmBegwdFcPln2LDZ84L59Zq96qR22ntOV7cukn8MqXdqJ7sXqX9qK7sXKWjay1rEs3ZZwya97K+P6GWH7+1l3XbTZvb8NB9sZjezz/sb2eF/2shiXn3FWZOFHzqUUY92RtSOAsrsqEO7duStVj3qUny+uDj0cbJcRnHKSh2zRt1SgBkozMp23itlDIYRNTJmjD+LMVpjSjwaW/3VRkkSjSFZ1vTW7Z3KwaR1XHnBWmCd87tu4AWB3+syv8v68/lfJL+pcw==

Copy blueprint
Because the Roboports are each requesting the same number of Bots (in my setup: 5) they ought to automatically distribute themselves across the entire Network. Using the Y/T signal instead of the X/Z signal ensures that it will not over-fill the Network despite busy-ness. If you need more Robots to be distributed you need to only modify the Logistic Group (on the Combinator) and the Robot Request Group (on the right-hand Roboport). The inserters only activate when the Delta is above 50 Robots - this prevents it from "looping" the bots if the count is not perfect.

This circuit does not account for Quality differences - only the raw Number of Logistic/Construction bots. In this screenshot the mechanism is setup for "Rare" Quality; the Roboports on the left are setup to collect Normal/Uncommon into a Chest. In practice, I find that this works alright, since I only deploy one Quality of Robot per Logistic Network - the Normal-Epic ones all go into a Recycler as soon as Legendary becomes available.

Good Luck!