Reduce range penalty on robot charging stations

[Kahnugo]

TL;DR

Decrease the range penalty of robot charging stations, so that robots will go seek further for less congested charging stations.

What ?

Decrease the range penalty of robot charging stations when robots evaluate charging stations.

Why ?

The main issue I have with the way robots act now is that they seem unable to reasonably use the capacity of the current system. From a gameplay perspective it seems stupid that a robot is waiting in line to charge for 5-10 seconds when there's a queue less charging station less than a second away.
While I understand that there need to be a limit somewhere I would much prefer to have it make sense in a gameplay fashion, instead of being a seemingly arbitrary game mechanics limitation.

Is there any reason why the range penalty is this harsh?

Edit: fit it in the template, removed clutter.
2. Edit: Exchanged 'seek' with 'go' for clarity, I'm suggesting an adjustment of weights, not a fundamental change in behaviour.

[Koub]

If I understand things correctly, a robot will choose where to recharge, and then, never change its mind, even if one adds 50 roboports next to it while it's waiting.
Any form of periodical "recomputing" would degrade game performance, which is usually not a trade off the devs are willing to pay.

[Kahnugo]

But that would, as far as I can tell, still mean that you should see robots charging further away if there is always a large number of bots either charging or going to charge at a specific station and the value is so that they pick stations that are reasonable in terms of downtime?
What I mean is that over time with many robots you would expect it to stabilise over time, so that if it runs for 10 hours you wont see 20 robot queues with free roboports nearby.
Edit: or at least you would expect them to clear up then reappear, which could happen if the robots don't work continuously in an otherwise balanced system.

[ssilk]

I like this idea, because it would help especially when you construct things a bit far away and between is a lake or so (less roboports). And for the normal case I also think it can speed up things.

Can anybody calculate the optimal multiplicators for this suggestion?

[Koub]

I'm almost certain the current implementation is already optimal. I made a test with a full square of roboports save the center where I stacked a few infinite chests, and a sh*tload of logibots, and the waiting bots were arranged in a perfect disc, with more robots queuing close by, and fewer as the roboports were further away.

A bot consumes 5 kJ per tile, and drains 3 kW, which is 3 kJ per second.
Travelling 3 tiles is equivalent to hovering for 5 seconds.

With a 1.5 MJ buffer, that's :
300 tiles of travelling
500 seconds of waiting (8 minutes 20s)
Or any combination of both as long as they respect 5.nbTiles+3.secondsWaiting <= 1500 (in kJ)

[Kahnugo]

What I am suggesting doesn't change that behaviour, only the radius of the disc and the concentration of the rings. It's a problem if a robot waits for long periods of time because it negatively affects the network, creating the need to compensate by requesting more and buffering more.

Each of my robots can work for about 11 seconds per charge (with speed tech). if they wait 10 seconds per charge that's 22.5 seconds per effective 11 seconds work (the remaining charge I assume more or less counteract the work lost by moving to and from stations). If they instead wait 2 seconds, that is 14.5 seconds per 11 seconds work. That means I need a network that is over 50% larger in terms of robots, requests and buffer, if robots wait 10 seconds instead of 2.

This is best case (in reality limitations in the logistic manager seems to cause orders to be created in bursts requiring even larger networks to not dip below a certain average within critical time).

My network currently transports in the region of 5000 items per second to and from combined in an approximate 200x200 tile network with ~14500 robots and roughly 700 roboports.
If the average travelled distance of an item is around 75 tiles that is approximately 3 robot trips per charge. With 4 items per trip that would set a lower limit of about 4000 active robots to sustain. If they spend half of their time charging or waiting to charge that increases to 8k. This is assuming complete continuity of tasks, this is very far from the case.

The problems I have are not just caused by this, I don't even think it's the largest factor. So my base is not a perfect case study for this issue (I have already tried my best to design it with this in mind so the density of roboports in the high traffic areas is quite high). My point is that looking at energy as the balance factor between waiting and moving further does not translate into an effective base. It using 50 kJ extra (0.05 sec charging) to get to its destination 5 sec faster is worth it in my opinion.

Sidenote: There is no such thing as an optimal implementation, that depends on the case.

[ssilk]

@Koub: your calculation is correct, but only, when the roboports are not occupied.


When the roboports are occupied, the chance is 50% that a robot flies into the direction of the target for charging (when roboports are equally spreaded).

With a wider spread the chance, that they discharge, before they arrive at a roboport is now much higher. Sounds bad. But - and that is the point - instead of waiting - they fly... very slowly, but continuously more ore less into the direction of the target. Which means: a wider spread rises the chance for about 50% of the bots to travel more into the right direction. And for those that travel backwards: they don’t need to wait so long for recharging.

Hm.

I would even go further and add a very simple rule to implement: if a robot doesn’t find a free roboport in a range of X around him, he continues his current direction and tries a search for a free roboport Y seconds later. And I guess X might be around 200-400 tiles and Y about 30-60 seconds.

[Kahnugo]

With a wider spread the chance, that they discharge, before they arrive at a roboport is now much higher. Sounds bad. But - and that is the point - instead of waiting - they fly... very slowly, but continuously more ore less into the direction of the target. Which means: a wider spread rises the chance for about 50% of the bots to travel more into the right direction. And for those that travel backwards: they don’t need to wait so long for recharging.

To me the time before the bot becomes active is the important factor here, the problem as I see it is that robots tend to wait for much longer than it would take at higher tech to get to a free charging station 10 tiles away, or just a significantly shorter queue. It seems like it becomes a limiting factor for the performance of the network, before the charging limit per roboport area, which to me is not that satisfying.

I would even go further and add a very simple rule to implement: if a robot doesn’t find a free roboport in a range of X around him, he continues his current direction and tries a search for a free roboport Y seconds later. And I guess X might be around 200-400 tiles and Y about 30-60 seconds.

I'm not sure this is feasible, it would require very frequent scans for not to go way off target. I'd note as well that roboports have a range of 25 tiles around it.. :p and that, as I mentioned earlier, my robots can work for up to 11 seconds before they need to be recharged and move 20+ tiles per second.

[Squelch]

Bots are single minded when they have a task. They do not deviate from attempting to complete the task even if it means the route, or time spent is suboptimal as is the case demonstrated here. It would be nice if there was a way to cause bots to repath in a similar way to how trains work.

An example of the single mindedness can be seen if a logistics network ends up forming a L shape around a body of water. If a delivery needs to be taken from the end of one leg of the L to the end of the other leg, a bot will attempt to take the shortest, diagonal, route. The consequence of this is it will not have enough charge to reach the destination, so will return to the start, recharge and try again. This will continue indefinitely until either the bot is destroyed or the destination request is satisfied or changed. Even placing a new roboport along the route the bot is taking will not result in it using this, closer roboport. Another example can be seen when a bot flies over a roboport towards its destination, runs out of charge just before it reaches the drop off point, and then retrace its path the to roboport that it just flew over.

None of the above are optimal, even though bots do follow the most optimised path in general. It could also be said that repeating the same path over and over could have an overall impact on performance.

I had always considered this to be a player conundrum, and it was up to them to place roboports in most expedient locations to satisfy the charging needs. That might have been the intent early on during development, but bots do seem to waste a lot of time either charging, trying to charge, or repeating the same actions with no result more and more.

I think the solution might be to have a timer or counter that has a threshold to trigger a repath. This might cause a waiting for charge bot to seek another roboport, or break a fruitless cycle. Performance might be a big concern however. I do note that this request might be able to be achieved as a mod. All of the information is available via the API to force bots to find an alternative, but at the cost of performance once more.

[Koub]

Whatever the proposed solution, I think it will have to pass the thought experiment of "what would be the performance hit if I multiplied by 50 or 100k (or even more) robots in a megabase scenario ?". If the answer is "significant", I can't imagine it implemented.

The current bots' relative stupidity is directly linked to that : minimal intelligence, minimal computational footprint in the overall game update time, but still does the job pretty well most of the time.

[ptx0]

Whatever the proposed solution, I think it will have to pass the thought experiment of "what would be the performance hit if I multiplied by 50 or 100k (or even more) robots in a megabase scenario ?". If the answer is "significant", I can't imagine it implemented.

The current bots' relative stupidity is directly linked to that : minimal intelligence, minimal computational footprint in the overall game update time, but still does the job pretty well most of the time.

yes, we may as well make them collide with each other so that there's no *room* at the roboport. surely that won't nuke the CPU at all!

[Durr]

Would adding a charging limit (similar to the new train limit) to the roboport work here? I imagine it would work in a way that if the limit is currently met, robots looking for a place to charge would essentially be blind to the full roboport and path to the next closest one.

I don't know how it would work of all roboports are currently full though... Just a random thought for someone smarter to think it the rest of the way through lol

Edit: Maybe a weighted system so robots currently charging add a distance penalty to the pathfinding for robots looking to charge, so further empty roboports appear closer

[ssilk]

TL;DR
- we need to differ between logistic bots and construction bots, because this is also a question of balancing (logistic) bots vs. belts
- for logistic a slight increase of this rule (see subject) sounds feasible
- for construction bots I suggest
A) a stronger increase of this rule
B) a limited range, where robots search further for a “free” roboport (if the next free roboport is outside of range). In that case robots just continue their travel to their target and repeat a scan after some time.
C) exact numbers (how much spread,which range and rescan time) is part of in-game balancing.



@Durr That doesn’t work.
Why? It is so, that if you have the simplest possible network, which is two roboports, you can have between 50 and 100 logistic robots in, before the roboports are not longer able to charge all, when all robots are in usage.

Well, it’s some years ago, when I tested that, but I don’t think the numbers changed much, ... and it doesn’t matter, the point is: there is an absolute charge limit for any logistic network: when all roboports are occupied. It depends much on the size and form of that network, but it is there. And another limit is the number of robots that can be send out per tick.

So, even if you increase the spread very much, it would be very hard in a “normal” logistic network to occupy all roboports for charging.

@Koub the suggestion additions I made (when no roboport in range X the move into direction of target and repeat search after Y seconds) would significantly improve the game performance, because a) the search for a free roboport is limited to a certain range. b) the task (a placed blueprint) would be done much faster, which means less time, which means robots can return earlier to their home, less CPU usage.

And what I just thought is this: my extra rule doesn’t work well with logistic bots. It would work well with one-time logistic tasks, but on the other hand logistic bots are nerved in this way to not be better than belts. I can agree with that. So I think my rule might be implemented only for construction bots; would make builds way much faster.

@Squelch as said by you: that behavior is more or less purpose. But that is not the subject of this suggestion.

I'm not sure this is feasible, it would require very frequent scans for not to go way off target. I'd note as well that roboports have a range of 25 tiles around it.. :p and that, as I mentioned earlier, my robots can work for up to 11 seconds before they need to be recharged and move 20+ tiles per second.

Why should a robot need need frequent scans?
They runs some time - 11 seconds, I don’t know - then they look for recharging and if nothing can be found in range (when it could reload only outside the range), it just continues to the target. At some point it runs out of fuel and continues only slowly, then it does a rescan (maybe 30 seconds is too long when I’m thinking about it) and if still all occupied it just continues slowly, because that is still faster than to wait...

[Guenni7]

Sounds interessting, but honestly... I would put that on hold til logistics are gone multi-threaded.
Bots searching in an increased radius for roboports to charge will have most likely a huge impact on processing power needed because calculating the way to go of a bot is not that easy. And for thousands of bots, I can't even imagine.... I think the processing time needed is exponential when increasing radius as it is in two dimensions.

Additionally, I think they already spread very far to reach a free roboport, maybe what you're suggestioning is to limit the roboport-waiting-queue-for recharge?

[Kahnugo]

- we need to differ between logistic bots and construction bots, because this is also a question of balancing (logistic) bots vs. belts

I don't think that's necessary, the balancing should in my opinion be done through features you interact with as player (like number of charging stations per area, charging rate, robot buffer and energy consumption). I am not suggesting change to any of those, so balance is not really a concern for me here. At least not game balance.

Why should a robot need need frequent scans?

If you allow the robot to ignore its call to charge then I guess you could get away with just checking in once in a while without bots going wildly off target. Though then you have to consider that bots in congested networks might just never charge. Unless you keep track of even more stuff continuously (like how long it's been so you can overwrite the system). Have in mind that this would need to be done thousands of times in short durations.

They runs some time - 11 seconds, I don’t know

This is something we can know though. It turns out my numbers were even a bit outdated (from an earlier state with lower speed tech). Currently I have an 890% speedboost for robots, logistic robots move 3 tiles per second which translates to 29.7 tiles per second. Each tile traversed cost 5 MJ, so they can travel for at most 8.08 seconds before reaching 20% charge level. At this speed the passive drain is much less significant.

.. the point is: there is an absolute charge limit for any logistic network: when all roboports are occupied. It depends much on the size and form of that network, but it is there. And another limit is the number of robots that can be send out per tick.

So, even if you increase the spread very much, it would be very hard in a “normal” logistic network to occupy all roboports for charging.

I'm not sure what you're saying here, but animation limitations don't factor in when a roboport can charge a robot per 0.375 second. It is part of the gameplay limitation put on logistic networks that you can only charge robots at this rate on a 4x4 footprint. What I'd think would be achieved by a change in the weights when picking roboports for charging is that the networks' actual capacity is able to be utilised better for high traffic routes (that means a lot of robots travel the same route, which means a lot of robots will have the same roboports as the nearest one when they need to charge).

Sounds interessting, but honestly... I would put that on hold til logistics are gone multi-threaded.
Bots searching in an increased radius for roboports to charge will have most likely a huge impact on processing power needed because calculating the way to go of a bot is not that easy. And for thousands of bots, I can't even imagine.... I think the processing time needed is exponential when increasing radius as it is in two dimensions.

That depends on how it's actually done. I can't see it just from spectating the game ui. An old post about how robots pick charging stations suggest that a travel penalty is determined for all roboports in a network. That might have changed for optimisation reasons, but robots are able to find roboports for charging at great distances, so my guess would be that roboports are found on a list of sorts containing the roboports connected to that network. Changing the weights might or might not have a significant performance impact. I don't feel like I have much of a chance judging that without knowing more about how it's actually done under the hood.

[Guenni7]

I edited my post, maybe you haven't seen when writing yours:

Additionally, I think they already spread very far to reach a free roboport, maybe what you're suggestioning is to limit the roboport-waiting-queue-for recharge?

[ssilk]

Well, for construction bots my suggested change should take no extra CPU. I mean: otherwise the bots run to a roboport and adds themselves to the waiting queue. With that change it rescanns after some seconds... And as explained above I think it will reduce costs also, because the overall construction is then faster.

For logistic bots the problem is indeed a bit higher with more spread. But I mean this scan for roboports is super fast, I mean there is an range-indexed list of all roboports in a network. I’m sure it takes only a fraction of nanoseconds longer to scan some more roboports.

[Kahnugo]

@Guenni7
It is possible that I'm just overestimating the congestion of my network or that it has something to do with many robots being assigned simultaneously causing fluctuations in the queues. It is admittedly a bit hard to spot what's actually going on in a cluster bots.
I'm not suggesting to limit the queues, merely that it seems that roboports relatively close to robot highways aren't being utilised much, considering how fast the robots will get there and how long they seem to be hovering on the spot. That said I have been observing robots snap to free charging stations after hovering for a while at other roboports, so I am wondering if there is some sort of system that announces free charging stations.

[Guenni7]

From what I see in my networks, they spread 3 to 4 roboports away (all full distance roboports), so the radius is already quite large.
I also have seen that they cloud on one roboport even when there was a free roboport nearby, that lead me to the conclusion
that maybe not the radius is the problem, but the Bot-waiting-queue-for-recharging is set too high. With that queue set a bit lower they would spread wider to recharge.

[Kahnugo]

If the general behaviour is similar to early versions on the game, then radius translates into increased weight, which then translates into longer queue before alternatives are picked. So in my understanding increasing weights would in practice be similar to dynamically reducing the queue limit (acting as a soft cap).

.. I mean there is an range-indexed list of all roboports in a network. I’m sure it takes only a fraction of nanoseconds longer to scan some more roboports.

Can you elaborate on that, is there a source? Because I would really like to get some updated real information about the inner workings rather that going by what is mostly speculation based on old bits of information and general sense of how things work in the game (which is obviously potentially flawed because of my lack of in depth knowledge).

Side note: I feel a bit sheepish now trying to observe the robots directly when the edit:detailed debug info tooltips actually gives the waiting queue info.. :p I should probably have thought of checking that.

Edit: I tried to do a quick survey of roboports in a transition area between high traffic and no traffic, going 3-4 roboports away from the main flow.
Not an exact snapshot, but turned the game speed down to 1 ups and paused in between readings.
5 | S| 18 | 23 | 24
5 | 14 | 23 | 28
0 | 13 | 24 | 32
0 | S| 18 | 28 | 27
Where the numbers are robots in queue and S is a substation.