Active Robots

[SoulForge]

Is there a limit on the number of active robots that can be out? I have a lot of things they can be built by them but most of my bots are sitting idle in the roboport.

[Smarty]

only construction bots can place stuff

[SoulForge]

only construction bots can place stuff

Yes..........I know.

[daniel34]

viewtopic.php?p=193621#p193621

Robots are dispatched at a maximum of 3 per tick in a cyclic loop over all ghosts.

This means that every second there should be 180 robots (60 ticks/s * 3 robots/tick) dispatched to ghosts or deconstruction orders. If you have construction/deconstruction tasks outside of the construction range then they will still be included in that calculation but no robots will be dispatched, making the overall dispatch rate lower and this can cause that issue. If all your (de)construction orders are inside the construction range but your construction robots sit idly in roboports and do nothing then please upload your save file.

[bk5115545]

viewtopic.php?p=193621#p193621

Oh would you look at that. It's the thread where I brought up math numbers which show the dispatch logic doesn't remotely optimally use bots.

Instead of dispatching a maximum number of bots, I feel like it would be better to time the bot-dispatch code and try to make a time target.

Potential Scenario:
Bot dispatch can take at most 1 ms and the server dispatched 8 bots in 1.345 ms last tick.
Average dispatch time is 0.168 ms (1.345/8).
max = previous_max - (last_tick - time_target)/average_dispatch_per_bot
max = 8 - (1.345 - 1)/0.168
max = floor(5.95)
max = max==0?1:max; // max will never be 0
Dispatch at most 6 bots this tick (if there's 6 ghosts). Keep times for next tick.

There must be at least 1 bot to compute times with or else you'll get some divide-by-zero's. Timing an operation every tick is going to be fairly high overhead though. A quick solution is to only capture the execution times every 300 ticks or so.
The worst case is when there are too many ghosts and max goes down to 1 which gives us the same result as the old system.

Looking forward to see how this goes.

[Deadly-Bagel]

Your numbers in the other topic don't add up for me. You use 5000 / 60 * 10 to calculate 60 bots dispatched per tick taking 10 seconds per task for 5,000 tasks, but that's incorrect. That calculation is for if you had 60 bots in your network and they were all dispatched instantly. The actual calculation is more complex but basically it's a maximum of 5,000 / 60 + 10 which is 93 seconds (total time to loop ghosts plus job time).

A more efficient approach would probably be to have ghosts enter an idle state when not in roboport range, the trick is efficiently updating this status when in range of a personal roboport.

[bk5115545]

Your numbers in the other topic don't add up for me. You use 5000 / 60 * 10 to calculate 60 bots dispatched per tick taking 10 seconds per task for 5,000 tasks, but that's incorrect. That calculation is for if you had 60 bots in your network and they were all dispatched instantly. The actual calculation is more complex but basically it's a maximum of 5,000 / 60 + 10 which is 93 seconds (total time to loop ghosts plus job time).

You're right that the calculation is a little off (it's too short by 2 seconds per 60 bots in the network). I account for the network being out of bots by using a different way to total working time.
Does this breakdown make more sense?

I have 5000 tasks. I have 60 bots.
5000/60 = 83.333 tasks per bot.
Each task takes 10 seconds (theoretical).
ceil(83.333) * 10 = 840 seconds total.

The calculation error is only 2 seconds because the bots are initially dispatched over the first second i.e. the system isn't efficiently operating until the second second. The system's startup latency is translated into a 1 second sliding window of 100% efficiency (100% efficiency is when all bots are working on a task). The second second of error comes in at the end of the tasks where there are more bots than their are jobs to be done. The spin-up and spool-down rate is dependent on the number of bots available in the system. The number of bots in the system is dependent on the initial count and the length of the tasks. Knowing this information, we can find how many bots optimally exist in a network where there are more ghosts than bots.

Assuming a 10 second task time and going off of the previous stated dispatch rate of 1 bot per tick, we need 10 * 1 * 60 bots in the network to maintain 100% efficiency. We know from the above that every 60 bots adds another 2 seconds of inefficient operation by increasing how long the sliding window takes to reach 100% efficiency. To achieve close to the 833 second calculation, we would need to have 600 bots and 5000 tasks. The problem is that the 2 seconds of inefficient operation add 600/60 or 20 seconds of delay (I think you calculated 10s here; really we're thinking the same).

Based on the above math, the below 3 scenarios are true.

Scenario 1:
I place a blueprint with 5001 tasks in a network with 5000 bots. There are more tasks than bots so at most 1 bot will be dispatched per tick. Lets still assume that it takes 10s per task.
Optimally, it would take ceil(5001/5000)*10 or 20 seconds. This is obviously not possible to implement without absolutely destroying the game's performance so there has to be some limit.
With the limit of 1 bot per tick or 60 bots per second, it will take 5001/60*10 or 835 seconds. This is because this scenario doesn't matter how many bots we have in the network (as long as there is always 1 ready to be dispatched), it only depends on the dispatch rate and the number of ghosts.

Scenario 2:
If I have a network with 1800 bots and place a blueprint which requires 600 tasks then at most 3 bots are dispatched per tick. These tasks still take 10s.
Optimally, it would only take ceil(600/1800)*10 or 10 seconds. This still isn't possible for the same reason as above.
With the limit of 3 bots per stick or 180 bots per second, it will take 600/180*10 or 33 seconds. This is because the dispatch logic limits the amount of bots which can be dispatched to maintain better performance.

Scenario 3:
If I have a network with 1200 bots and place a blueprint which requires 5000 tasks then at most 1 bot is dispatched per tick. Tasks take 10s.
Optimally, it would only take ceil(5000/1200)*10 or 42 seconds. This still isn't considering game performance.
With the limit of 3 bots per tick, we will have at most 600 bots airborne at any given time (60 bots dispatched per tick times 10 second task time is 600 airborne). That leaves half my bots unused which I really don't like. Total task time is ceil(5000/600)*10 or 84 seconds.

Evaluation:
Scenario 1 takes 835/20 or 41.75 times longer than optimal ergo my complaint about how my resources aren't being used efficiently.
Scenario 2 takes 33/10 or 3.3 times longer than optimal. While I don't like the numbers, this scenario doesn't feel slow and changing it would significantly buff the bot build times for large blueprints.
Scenario 3 takes 84/42 or 2 times longer than optimal. This is a good efficiency ratio however 600 bots are being wasted. This is what I have a problem with. No matter how many bots are added, the blueprint takes the same amount of time until I have as many bots as tasks.
Scenario 1 and 3 are actually the same scenario with different numbers.

Final remarks:
The degree of inefficiency gets larger when I place blueprints of larger and larger sizes. I would prefer a system of fairly static inefficiency but it's not possible to be programmed when performance is of a concern. I can't suggest how the problems raised above could be fixed but scenario 3 might be considered to be "not working as intended."

Edit:
Changed wording of final remarks to clarify task vs blueprint total time.
Clarified scenario description in "Evaluation".

[websunil007]

Only Construction Bots.

[Deadly-Bagel]

I have 5000 tasks. I have 60 bots.
5000/60 = 83.333 tasks per bot.
Each task takes 10 seconds (theoretical).
ceil(83.333) * 10 = 840 seconds total.

The calculation error is only 2 seconds because the bots are initially dispatched over the first second i.e. the system isn't efficiently operating until the second second. The system's startup latency is translated into a 1 second sliding window of 100% efficiency (100% efficiency is when all bots are working on a task). The second second of error comes in at the end of the tasks where there are more bots than their are jobs to be done. The spin-up and spool-down rate is dependent on the number of bots available in the system. The number of bots in the system is dependent on the initial count and the length of the tasks. Knowing this information, we can find how many bots optimally exist in a network where there are more ghosts than bots.

Assuming a 10 second task time and going off of the previous stated dispatch rate of 1 bot per tick, we need 10 * 1 * 60 bots in the network to maintain 100% efficiency. We know from the above that every 60 bots adds another 2 seconds of inefficient operation by increasing how long the sliding window takes to reach 100% efficiency. To achieve close to the 833 second calculation, we would need to have 600 bots and 5000 tasks. The problem is that the 2 seconds of inefficient operation add 600/60 or 20 seconds of delay (I think you calculated 10s here; really we're thinking the same).

I think you're overcomplicating this. It would take ~16.7 seconds to release all 1,000 bots (1000 / 60). After 10 seconds, bots start returning ready for a new job, if each takes exactly 10 seconds they will return at exactly the rate they are being dispatched so the process is perpetual and the ONLY limiting factor is how fast it can loop over the ghosts. It takes (5000 / 60) = 83.3 seconds to dispatch robots to all ghosts, and 10s for the last robot to finish, therefore 93 seconds. In fact it's less than this because once the ghosts fall below 1,000 it speeds up to 180 robots per second, so really (4,000 / 60) + (1,000 / 180) + 10 = 82.2 seconds.

Your calculations seem to assume that during the 10s window that 60 robots are performing their duty, the roboport is not dispatching additional robots which is of course nonsense, a constant stream of 60 robots per second (if I understand it correctly) is being dispatched by the roboport so the time required to do the job doesn't come in to play until either you run out of robots to dispatch or a robot is sent to the last ghost.

Based on the above math, the below 3 scenarios are true.

Scenario 1:
I place a blueprint with 5001 tasks in a network with 5000 bots. There are more tasks than bots so at most 1 bot will be dispatched per tick. Lets still assume that it takes 10s per task.
Optimally, it would take ceil(5001/5000)*10 or 20 seconds. This is obviously not possible to implement without absolutely destroying the game's performance so there has to be some limit.
With the limit of 1 bot per tick or 60 bots per second, it will take 5001/60*10 or 835 seconds. This is because this scenario doesn't matter how many bots we have in the network (as long as there is always 1 ready to be dispatched), it only depends on the dispatch rate and the number of ghosts.

See above, your calculation again takes the amount of time to dispatch robots to all ghosts and then multiplies it by the time taken. Because the robots are completing the task faster than all robots are dispatched, the answer is the same as if you have 1,000 robots or even 600, it's the time required to dispatch robots to all ghosts plus the time for the last robots to finish (5,000 / 60) + 10

Scenario 2:
If I have a network with 1800 bots and place a blueprint which requires 600 tasks then at most 3 bots are dispatched per tick. These tasks still take 10s.
Optimally, it would only take ceil(600/1800)*10 or 10 seconds. This still isn't possible for the same reason as above.
With the limit of 3 bots per stick or 180 bots per second, it will take 600/180*10 or 33 seconds. This is because the dispatch logic limits the amount of bots which can be dispatched to maintain better performance.

It takes 3.3 seconds to dispatch 600 robots at 180 per second, plus ten seconds for the last robot to complete its task is 13.3 seconds.

Scenario 3:
If I have a network with 1200 bots and place a blueprint which requires 5000 tasks then at most 1 bot is dispatched per tick. Tasks take 10s.
Optimally, it would only take ceil(5000/1200)*10 or 42 seconds. This still isn't considering game performance.
With the limit of 3 bots per tick, we will have at most 600 bots airborne at any given time (60 bots dispatched per tick times 10 second task time is 600 airborne). That leaves half my bots unused which I really don't like. Total task time is ceil(5000/600)*10 or 84 seconds.

YES! This one is more or less accurate (though a bit roundabout). Indeed only 600 robots are active at any one time but this is only due to the short nature of the job, often they might take at least thirty seconds to pick up an item and place it which allows for 1800+ active construction bots.

Evaluation:
Scenario 1 takes 835/20 or 41.75 times longer than optimal ergo my complaint about how my resources aren't being used efficiently.
Scenario 2 takes 33/10 or 3.3 times longer than optimal. While I don't like the numbers, this scenario doesn't feel slow and changing it would significantly buff the bot build times for large blueprints.
Scenario 3 takes 84/42 or 2 times longer than optimal. This is a good efficiency ratio however 600 bots are being wasted. This is what I have a problem with. No matter how many bots are added, the blueprint takes the same amount of time until I have as many bots as tasks.
Scenario 1 and 3 are actually the same scenario with different numbers.

I don't get your last line here. You're basically saying it's the exact same conditions but you came up with wildly different figures but you can't see that?

Sure, it's not instant and it's not making full use of all the robots in your network. If you want to do that you would need to have more robots than blueprints (5001) which would be WAY more wasted robots at that short a task length, however given the complexity of the game and performance limitations I think ~1.5 minutes to complete such an enormous task is perfectly acceptable.

IMO the only optimisation that might want attention is 'deactivating' ghosts outside of roboport range because these are the real killers in performance due to the fact that they consume one of your 1 or 3 per tick but don't actually get actioned so keep coming up. I guess the workaround for now is not to put ghosts everywhere (don't know why you would do this anyway) and from memory they time out anyway? So not really a big deal.

[bk5115545]

I think you're overcomplicating this. It would take ~16.7 seconds to release all 1,000 bots (1000 / 60). After 10 seconds, bots start returning ready for a new job, if each takes exactly 10 seconds they will return at exactly the rate they are being dispatched so the process is perpetual and the ONLY limiting factor is how fast it can loop over the ghosts. It takes (5000 / 60) = 83.3 seconds to dispatch robots to all ghosts, and 10s for the last robot to finish, therefore 93 seconds. In fact it's less than this because once the ghosts fall below 1,000 it speeds up to 180 robots per second, so really (4,000 / 60) + (1,000 / 180) + 10 = 82.2 seconds.

Your calculations seem to assume that during the 10s window that 60 robots are performing their duty, the roboport is not dispatching additional robots which is of course nonsense, a constant stream of 60 robots per second (if I understand it correctly) is being dispatched by the roboport so the time required to do the job doesn't come in to play until either you run out of robots to dispatch or a robot is sent to the last ghost.

I believe I specifically stated that there were only 60 bots. Thank you for mostly confirming my calculation.

See above, your calculation again takes the amount of time to dispatch robots to all ghosts and then multiplies it by the time taken. Because the robots are completing the task faster than all robots are dispatched, the answer is the same as if you have 1,000 robots or even 600, it's the time required to dispatch robots to all ghosts plus the time for the last robots to finish (5,000 / 60) + 10

I noticed a slight parenthesis error on my part which would lead you to assume your calculation is similar to mine. When I wrote, 5000/60*10, it should have been 5000/(60*10)+10, or 18.33 s.

YES! This one is more or less accurate (though a bit roundabout). Indeed only 600 robots are active at any one time but this is only due to the short nature of the job, often they might take at least thirty seconds to pick up an item and place it which allows for 1800+ active construction bots.

This may be true but it still takes way too long to place solar panel blocks. I even fill storage chests right next to the central roboport with panels and based on these numbers, I'm not making the process go any faster; I'm just making it use less bots. In an actual scenario, when I mark a bunch of trees around me for deconstruction (outside of any network range) and my personal roboports handle it then the main base also slows down building it's solar and the outposts slow down repairs. A better system would as follows:

When a ghost is created, it is registered in the network covering it's location.
If there is no network, it is added to a global ghost registry which the player roboports will loop over like normal.
When a roboport network is modified, that network loops over the global ghost registry as well (to check for ghosts that are now in range).
Each network will dispatch dones individually. Global maximum is determined dynamically via timed performance goal as I described earlier in this discussion.

This way I can design a base to work around what I consider to be a problem. It also removes a counterintuitive mechanic while simplifying the potential modding interface.

Scenario 1 and 3 are actually the same scenario with different numbers.

I don't get your last line here. You're basically saying it's the exact same conditions but you came up with wildly different figures but you can't see that?

I did get that. The increasing figure was meant to help people see how the system fails to use increasingly larger numbers of bots.
Also,

but you can't see that?

is very different than typing "but can't you see that?" The first attacks my character while the latter is a legitimate question. Since English isn't the only, or even most important, language on Earth; I forgive you.

[Deadly-Bagel]

I believe I specifically stated that there were only 60 bots. Thank you for mostly confirming my calculation.

Yes, however you said it was a breakdown of this calculation:

I have 1000 construction drones and 5000 ghosts. If we assume that it takes a drone 10s to complete it's task ... dispatching only 1 drone per tick (since I don't have enough drones) means that it will take about 833s (5000/60*10) which is around 14 minutes.

Therefore this is what I was referring to, not your calculation of 60 robots which is correct but irrelevant to my query. You're using the same calculation for both so I used the relevant figure of 1000 that I originally referred to.

I noticed a slight parenthesis error on my part which would lead you to assume your calculation is similar to mine. When I wrote, 5000/60*10, it should have been 5000/(60*10)+10, or 18.33 s.

Are we talking about the same quote here? Because what I was quoting was not similar to mine, nor is your corrected version. Also your point in the fragment I quoted was "bots take ages" but in your corrected calculation they don't take any time at all. Also I'm not entirely sure what it's supposed to be representing. Total jobs divided by (robots times job time)? That would imply that the longer the job takes, the quicker it gets done.

This may be true but it still takes way too long to place solar panel blocks. I even fill storage chests right next to the central roboport with panels and based on these numbers, I'm not making the process go any faster; I'm just making it use less bots. In an actual scenario, when I mark a bunch of trees around me for deconstruction (outside of any network range) and my personal roboports handle it then the main base also slows down building it's solar and the outposts slow down repairs.

Yeah but how many trees could you possibly be marking within 90 seconds of placing a 5,000 entity blueprint? The "optimal solar/accu ratio setup" (kinda looks like a chest) has under 400 components. You would need to place at least 13 of these simultaneously to get the sort of 'poor' performance we're talking about here. If you place them one at a time a robot will be dispatched to every single component in about two seconds. If you place four at a time it would take eight seconds (it would take you longer to line the next lot up) as long as you have at least 1600 robots.

I did get that. The increasing figure was meant to help people see how the system fails to use increasingly larger numbers of bots.
Also,

but you can't see that?

is very different than typing "but can't you see that?" The first attacks my character while the latter is a legitimate question. Since English isn't the only, or even most important, language on Earth; I forgive you.

First of all that isn't even remotely close to an attack. The way I said it isn't a question of if you can see it, it's a statement that (as far as you're letting on) you can't tell the two scenarios are identical with identical completion times and I'm wondering why. However this is purely semantics and is irrelevant. If you want to read attacks into my replies then suit yourself but rest assured I have no interest in your character.

So then, which figure is increasing? Scenario 1 uses 5000 bots which you calculated at 835 seconds. Scenario 3 uses 1200 bots which you calculated at 84 seconds. I see no logic here. Adding more bots won't make a task take longer.

[Dasani]

I'm not sure if they cap out at some extreme end of the spectrum, but if they do have a cap, you really shouldn't ever reach it.

The method I use for my bots is I have an entire section of the factory dedicated to mass producing the flying robot frames and I keep 100 of them in a chest at all times. That chest then feeds 2 assembling machines, one for construction bots, one for logistic bots, and the output from each assembler is a filter inserter dumping straight into a roboport and it is only active when there are 0 available robots of a given type.

What this means is, it only creates more robots when it actually needs more robots and the rest of the time it doesn't do anything. So my robot numbers quickly grow up into the realm of 2000 or so, then they tend to stop there. And it only uses near that many when i'm doing something that kind of spikes their activity like that inevitable point in the game where I decide to fill up the rest of the walled off area of my megabase with more solar panels just because I can. That is when it tends to spike up to much higher numbers.

So I can't say if there is a hard cap or not, but if there is, it is so high that you should never ever hit it unless you're doing something absolutely nuts like blueprinting your entire factory and duplicating the entire thing elsewere, concrete and all and letting your robobuddies build it for you. I find you tend to run out of materials far sooner than you run out of robots, unless you just had a massive stockpile of everything laying around for whatever reason.

[Deadly-Bagel]

I'm not entirely sure what you're saying here Dasani.

Let me recap. Ghost entities 'request' a robot at a rate of 3 ghosts per tick (180 per second), if there are more ghosts than available robots then it slows down to 1 per tick (60 per second). This means if you put down a blueprint of 400 entities and you have 500 robots, each of the ghosts will request a robot in just over two seconds.

At reasonable numbers this isn't a problem, however when you have around 2,000 robots and put down a blueprint with say 5,000 entities in it, performance drops quite significantly. Because there are more ghosts than robots only 60 ghosts are processed per second, and it takes 33.3 seconds to dispatch all 2,000 robots. If the task only takes ~10 seconds, robots start returning before all the robots are dispatched and out of 2,000 available robots you can only have about 600 in the air.

Therefore there isn't a hard cap, but there are two soft caps. The first is 60 multiplied by the job time (more ghosts than robots), and the next cap is 180 multiplied by the job time (more robots than ghosts). But that isn't the point of this discussion.

[Xeanoa]

Why does the game deploy only so few robots per second? That seems to make no sense.

[bk5115545]

Why does the game deploy only so few robots per second? That seems to make no sense.

The simple answer is that dispatching a bot takes a lot of steps. I'd like to know the real answer too but I like to know everything.

We don't have enough information (debug timings) to claim that this is a large or small number of bots dispatched per second.
The only valid request that we can make is that the number dispatched should be relative to game performance instead of something that seems arbitrary.


Deadly-Bagel.
Let's just agree that the drone dispatch could make better use of the resources we put into building drones.