[Genhis][2.0.11] Roboports queue logic 2.0 not working

[Hares]

My suggestion makes it so a more out of the way roboport is chosen but preferably one that is reachable with the current charge. By not going zig-zag flight time is significantly reduced for the recharge when considering the same roboport.

When they initially proposed the changes in FFF, I wrote an algorythm on how to determine recharge route which is very similar to what you're describing. That algoryyhm, however, does not take into account robots charge time (and thus queue time), it only goes from one roboport to the other -- you can't predict charging queue when the task is assigned. Thus, implementing roboport to roboport route is hard tricky or even impossible. You can, however, combine both methods, but this would come with a huge computational costs (need to select a roboport for recharging AND plan a route each time robot leaves a roboport -- even mid-task), so forget about it.

[mrvn]

My suggestion makes it so a more out of the way roboport is chosen but preferably one that is reachable with the current charge. By not going zig-zag flight time is significantly reduced for the recharge when considering the same roboport.

When they initially proposed the changes in FFF, I wrote an algorythm on how to determine recharge route which is very similar to what you're describing. That algoryyhm, however, does not take into account robots charge time (and thus queue time), it only goes from one roboport to the other -- you can't predict charging queue when the task is assigned. Thus, implementing roboport to roboport route is hard tricky or even impossible. You can, however, combine both methods, but this would come with a huge computational costs (need to select a roboport for recharging AND plan a route each time robot leaves a roboport -- even mid-task), so forget about it.

The devs mentioned that roboports now have a count for bots going to it for recharge, they register. So you can predict recharge time well enough by assuming you arrive at the roboport after all the currently listed bots arrived and they all need a full charge.

That prediction might be off as you might arrive before other bots or after more bots have selected the roboport. Some bots might only need a partial charge and finish far faster than bots that are out of juice. But that shouldn't matter much. It's about orders of magnitude difference in expected charge times that is the current problem with 100000 bots going to one roboport and none to the next.

So estimate wait time at a roboport as <bots registered> * <time to charge one bot fully> and that should be a good enough estimate to balance roboport usage. Far better than now anyway.

[Hares]

The devs mentioned that roboports now have a count for bots going to it for recharge, they register. So you can predict recharge time well enough by assuming you arrive at the roboport after all the currently listed bots arrived and they all need a full charge.

That prediction might be off as you might arrive before other bots or after more bots have selected the roboport. Some bots might only need a partial charge and finish far faster than bots that are out of juice. But that shouldn't matter much. It's about orders of magnitude difference in expected charge times that is the current problem with 100000 bots going to one roboport and none to the next.

So estimate wait time at a roboport as <bots registered> * <time to charge one bot fully> and that should be a good enough estimate to balance roboport usage. Far better than now anyway.

As you might have noticed, I mentioned the term queue time a lot during our conversation. The problem is queue time is a function of time, and storing the entire time table or time function for each roboport is extremely expensive. Why? Because if a longer route is requested, assigned, planned, and started, and then a task with intersecting/overlapping shorter route is assigned, the roboports on the intersection might already or might not be "blocked" -- you should know that info to plan a route. In current implementation, each roboport just stores a tick when it should be free again, and each robot charging just increases that number (or something similar).

[BlueTemplar]

[...]
They do split between the two roboports, but they will eventually stack up to ONLY those two roboports to charge. Over 7000 robots trying to charge at two roboports instead of spreading out to the other roboports just across the gap seems like the queue logic isn't working.

What kind of gap is this ? If it's in another logistic network, then that seems to be by design — if you want to transfer bots from one to another, use ground methods ?

[...]
It's slightly more than what large power poles can span.
[...]

Have you considered using higher quality ones ?
(Same goes for faster charging roboports.)

An issue that might or might not be related :
[2.0.15] Construction robots do not set a landfill

[mrvn]

The devs mentioned that roboports now have a count for bots going to it for recharge, they register. So you can predict recharge time well enough by assuming you arrive at the roboport after all the currently listed bots arrived and they all need a full charge.

That prediction might be off as you might arrive before other bots or after more bots have selected the roboport. Some bots might only need a partial charge and finish far faster than bots that are out of juice. But that shouldn't matter much. It's about orders of magnitude difference in expected charge times that is the current problem with 100000 bots going to one roboport and none to the next.

So estimate wait time at a roboport as <bots registered> * <time to charge one bot fully> and that should be a good enough estimate to balance roboport usage. Far better than now anyway.

As you might have noticed, I mentioned the term queue time a lot during our conversation. The problem is queue time is a function of time, and storing the entire time table or time function for each roboport is extremely expensive. Why? Because if a longer route is requested, assigned, planned, and started, and then a task with intersecting/overlapping shorter route is assigned, the roboports on the intersection might already or might not be "blocked" -- you should know that info to plan a route. In current implementation, each roboport just stores a tick when it should be free again, and each robot charging just increases that number (or something similar).

If you want to plan the full route then sure. My suggestion only plans a single step in the route and for that there is enough info. Planning the full route is probably pointless anyway as so many things change dynamically that any long term planning will be just wrong. Even without dynamic changes and storing a full timetable any solution you would find wouldn't be the optimal solution.

And even if you keep a full time table for each roboport then what is a bot supposed to do when it reaches a roboport that is free but not free long enough to charge itself? If the bot waits then that looks very bad to the player. But if the bot skips the queue then the whole time table is corrupted and won't work at all. I don't think any full-route-planning is going to be possibly cheaply nor would it look good to the player. Keep the planning just one step at a time and charging as first comes first served.

[Hares]

If you want to plan the full route then sure. My suggestion only plans a single step in the route and for that there is enough info. Planning the full route is probably pointless anyway as so many things change dynamically that any long term planning will be just wrong. Even without dynamic changes and storing a full timetable any solution you would find wouldn't be the optimal solution.

And even if you keep a full time table for each roboport then what is a bot supposed to do when it reaches a roboport that is free but not free long enough to charge itself? If the bot waits then that looks very bad to the player. But if the bot skips the queue then the whole time table is corrupted and won't work at all. I don't think any full-route-planning is going to be possibly cheaply nor would it look good to the player. Keep the planning just one step at a time and charging as first comes first served.

Ah, I see now. I can see some flaws in that design too (edit: most notably -- the higher divergance between estimate roboport free time & actual roboport free time compared to the current implementation) but all of them are minor and things I can live with.

[Genhis]

Thank you for reporting this issue. I was able to identify the problem (mainly thanks to 121378) and it should be fixed for the next release. The logic which picks roboports closer to target to charge in will only be used for crossing gaps over lakes.

[Hares]

Thank you for reporting this issue. I was able to identify the problem (mainly thanks to 121378) and it should be fixed for the next release. The logic which picks roboports closer to target to charge in will only be used for crossing gaps over lakes.

Does "lakes" mean that if I have waterless surface without roboport coverage AND network around it, the older "can never reach target because of U-turn" behavior will be used? Struggled this a lot when playing Space Exploration – my rail network has roboports, and I used it to build more mines completely remotely.

[Genhis]

Lakes = any area which doesn't have roboport coverage. The internal rule is that a robot is not allowed to pick the same roboport for charging twice if it didn't complete any tasks during that time. If such roboport is still considered to be the best candidate, the robot will search the whole network and picks a roboport which is as close to it as possible while still being closer to target than robot's current position.

[Hares]

Lakes = any area which doesn't have roboport coverage. The internal rule is that a robot is not allowed to pick the same roboport for charging twice if it didn't complete any tasks during that time. If such roboport is still considered to be the best candidate, the robot will search the whole network and picks a roboport which is as close to it as possible while still being closer to target than robot's current position.

This may lead to the situation when robot stream loops between two closest roboports while trying to reach opposite side of a lake.

[BlueTemplar]

What kind of layout would that be ?

So we changed the selection logic, so that the robot tries to always charge at a roboport that is closer to the destination than the robot is. This means that even if the robot will potentially fly with low energy for longer, it will always be able to make some progress towards the target, and eventually complete their mission.

[MrNukealizer]

Lakes = any area which doesn't have roboport coverage. The internal rule is that a robot is not allowed to pick the same roboport for charging twice if it didn't complete any tasks during that time. If such roboport is still considered to be the best candidate, the robot will search the whole network and picks a roboport which is as close to it as possible while still being closer to target than robot's current position.

This may lead to the situation when robot stream loops between two closest roboports while trying to reach opposite side of a lake.

How so? In that situation, the first charging port could be anywhere, but every charging port after the first has to be closer to the destination than the bots are after moving from the previous one. Thus none of the already visited ports should be valid options since the bots move toward the destination from them and therefore they'll never be closer to the destination than the bots are.

The only way I can see that being a valid concern is if the bots can't get out of roboport coverage (I assume that's logistics range, not build range?) before needing to recharge. That seems like it's already a big problem, and very unlikely to happen without mods making roboport coverage too big without increasing bot range accordingly.

[Hares]

How so? In that situation, the first charging port could be anywhere, but every charging port after the first has to be closer to the destination than the bots are after moving from the previous one. Thus none of the already visited ports should be valid options since the bots move toward the destination from them and therefore they'll never be closer to the destination than the bots are.

The only way I can see that being a valid concern is if the bots can't get out of roboport coverage (I assume that's logistics range, not build range?) before needing to recharge. That seems like it's already a big problem, and very unlikely to happen without mods making roboport coverage too big without increasing bot range accordingly.

The thing is – with that fix the new logic "closer to destination" will be active if and only if a robot has selected the same roboport twice in a row. What's I'm proposing there could be a scenario where the charger target is oscillating between two distinct roboports. See the drawing attached; robot exits from the top-left roboport, wants to recharge, sees that bottom roboport has less wait time, goes there, recharges, then selects top roboport as it now has less charge time. I can't say the exact timings & number if robots required to replicate such behavior but I'm sure it's possible and it will be reported in the future.

Rotate this image counterclockwise

Please forgive me that this should be rotated.

20241120_161757.jpg (2.19 MiB) Viewed 392 times

[mrvn]

Lakes = any area which doesn't have roboport coverage. The internal rule is that a robot is not allowed to pick the same roboport for charging twice if it didn't complete any tasks during that time. If such roboport is still considered to be the best candidate, the robot will search the whole network and picks a roboport which is as close to it as possible while still being closer to target than robot's current position.

"As close to it as possible" is a bad idea. That causes all bots to pick the same roboport, AGAIN.

I imagine it also means the bot will pick the roboport right across the lake because the roboports going around the lake will at first be further away from the target than the bot (which is in the middle of the lake) and then not the closest to the bot. So instead of going around the lake hopping from roboport to roboport it will take forever on low charge to cross the lake

Why not just closer than the roboport it last charged from?

Why is there even a second search? The "find best candidate" search performed first should already include the last roboport as blacklist and only consider roboports nearer than it. That way the code that picks a roboport with a short queue would still apply and you neither need 2 search functions nor 2 searches. Saves both code and time.

From what you describe I already fear a bot getting stuck bouncing between 2 roboports next to each other. Because the "best candidate" search doesn't have the "closer to target" limit from what you said. The code to pick a roboport that isn't busy could mean it alternates recharging from the 2 roboports because every time the other roboport has the shortest queue and is therefore best. So the bot never hits the "it's a lake" exception to force using a closer to target roboport.

[AndrolGenhald]

Why is there even a second search? The "find best candidate" search performed first should already include the last roboport as blacklist and only consider roboports nearer than it. That way the code that picks a roboport with a short queue would still apply and you neither need 2 search functions nor 2 searches. Saves both code and time.

That sounds like it might be a good solution, every time the bot starts a new pickup/dropoff/go-home job clear the "last charged" pointer, but when it charges during a job set it to that roboport, then the next charge must always be closer to the destination than the previous charge. That sounds basically like the current logic before the fix, except it allows the first charge during a job to go to any roboport.

[BlueTemplar]

Just to be clear, the fix we're now talking about was already in 2.0.0(?), and was talked about in that FFF, while the one coming to 2.0.21 is a different one. So I'm skeptical that it hasn't been caught in ~15 months of closed beta testing, as well as a month of release...

The 'oscillating' bit was the 1.1 behaviour that it was designed to fix :

[AndrolGenhald]

The 'oscillating' bit was the 1.1 behaviour that it was designed to fix :

They're referring to a different oscillation that might happen with the 2.0.21 fix. If robots only blacklist the last roboport they charged at, and don't require charging at a roboport closer to their destination except when going over "lakes", then there might be situations where a robot keeps trying to reach its destination but oscillates charging between two roboports when neither gives it enough charge to reach its destination. This would likely be most prevalent with larger range roboports from mods and on Aquilo.

[BlueTemplar]

If a robot is going over a 'lake', then the exception of going over a 'lake' will apply.

[mrvn]

If a robot is going over a 'lake', then the exception of going over a 'lake' will apply.

Not the way it was described.

The detection for "over a lake" was that it wants to recharge at the same roboport as last time. If there are 2 roboports at nearly the same distance then the bot might oscilate between the two roboports and never trigger the "over a lake" detection.

Will it always happen like the 1.1 oscilation? No.
Will it happen? Probably.
Will it keep happening forever once it occurs? Possible but not that likely.

But why take the chance when the proposed fix improves the bots for lake crossings in general and would simplify the code?

[BlueTemplar]

Yes, maybe (though I doubt it), but nothing changes about that in 2.0.21, that's my point.
Only robots not going over a lake are affected by the 2.0 => 2.0.21 change.