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

[Hares]

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.

Incorrect. Currently, the "closer to destination" logic always applies, thus guaranteeing bot will always reach its target – however, it does not guarantee this will be done optimally. Particularly, that "not optimally" can result in hundreds of robots queuing on the same roboport. Proposed fix disables that logic and reverts behaviour back to 1.1 (with fix for respecting queue time), with the exception that robot can't select the sa recharging point twice in a row (enabling 2.0 behavior for one trip). We (me & mrvn) are worried that there might be the new case where a group if robots will never reach the target – neither optimally or not – resulting into looping dancing between two close roboports.

TL;DR: Marvin suggests to select recharger point before starting the move (on each step, not for the entire task); I suggest keeping 2.0 behavior while introducing a hard limit for the recharge time (equal to the travel time to the target).

[Genhis]

...

Logistic networks with gaps aren't very good for robot activity and should be avoided. Still, people make them, so we try to fix some of the issues at least, such as robots on Aquilo which prompted the "ignore last roboport" rule (118933).

When robots search for a roboport to charge in, they first search only a local area (9x9 chunks) - if no valid roboport is within the area, they perform a global search. In standard networks, the local search is enough and there is no need to waste performance on global search. In networks with gaps and robots with low energy storage to cross the gaps, the local search may not return any roboports closer to target, so we have to search all roboports for valid charging targets.

Although I didn't read your suggestion (to plan the next charging spot in advance) before I fixed the other issue, I think it would require a lot more changes. We'll see how this behaves and if it should be tweaked some more. Again, the best thing is to make networks with no gaps.

This is how it will behave on Aquilo in 2.0.21 (50 robots, 10x game speed, only normal quality) - it's not an optimal solution but robots will get to their target eventually.

[Hares]

@Genhis, have you considered my suggestion about introducing a limit for a roboport queue time during search while also keeping the older "closer to destination" logic? If yes, what are concern of such implantation? It looks simple enough, does not require (almost) any additional computational power, and is 100% safe against loops. Furthermore, it guarantees that the any selected path to the target would be at least as fast as slowmoving towards it.

[mrvn]

...

Logistic networks with gaps aren't very good for robot activity and should be avoided. Still, people make them, so we try to fix some of the issues at least, such as robots on Aquilo which prompted the "ignore last roboport" rule (118933).

When robots search for a roboport to charge in, they first search only a local area (9x9 chunks) - if no valid roboport is within the area, they perform a global search. In standard networks, the local search is enough and there is no need to waste performance on global search. In networks with gaps and robots with low energy storage to cross the gaps, the local search may not return any roboports closer to target, so we have to search all roboports for valid charging targets.

Although I didn't read your suggestion (to plan the next charging spot in advance) before I fixed the other issue, I think it would require a lot more changes. We'll see how this behaves and if it should be tweaked some more. Again, the best thing is to make networks with no gaps.

This is how it behaves now on Aquilo (50 robots, 10x game speed, only normal quality) - it's not an optimal solution but robots will get to their target eventually.

And this shows how bad the current solution and fix is.

Watch the roborts right at the start. Many of them return to the roboport they just left to recharge. When a bot leaves a roboport that should be recorded as having just charged there, because that is what they do. They recharge before entering a roboport. A bot should never go back to the roboport they left from. Did you forget to set the roboport as "last charged at" when a bot leaves a roboport?

Then look later on, when the bots recharge at the downward going roboports. Some bots go backwards, north, picking a roboport further away from the goal than their last recharge. That isn't helpful as the next recharge cycle will be further away from the target then this one as well. They will just ping-pong back to the roboport they last charged at.


What should happen is all the bots go down south till they run out of charge. Then they spread out to the west, to the downward going roboports, because they are closer to the target than the last roboport the bots recharged at (or started from). All the top row of roboports are farther away than the starting roboport so they should never be considered.

Note: Yes, I realize that that would have a longer initial hop on low charge in this case.

I wonder if you could run the same experiment with a much larger C shape. I bet the bots would spread around the top roboports and bounce around randomly till a bot picks the same roboport twice.

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.

Incorrect. Currently, the "closer to destination" logic always applies, thus guaranteeing bot will always reach its target – however, it does not guarantee this will be done optimally.

And you are just plain wrong there. Look at the animation. Bots are returning to roboports that are further away from the destination then both the last recharge and the bot itself. There seems to be no "closer to destination" check done at all.

[Hares]

A quick correction on @mrvn: currently = before the fix

[mrvn]

Can the animation be recreated with the fix then? And maybe a larger C so bots don't accidently enter the downward going arm and it works just by random chance? If a 9x9 area is searched then the arms of the C should be 18 chunks long to be reasonably sure.

PS: maybe instead of saying "current" the actual version of the game could be used. That avoids confusion now and and in the future.

[BlueTemplar]

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.

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.

Does 'coverage' here means logistic coverage, repair coverage, or the mentioned 9x9 chunks ?

[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.

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.

Does 'coverage' here means logistic coverage, repair coverage, or the mentioned 9x9 chunks ?

Technically – neither of these. Actually – smaller (yellow) zone. Roboports have a number of different ranges:

• Radar coverage range. Not relevant here
• Connection range (yellow dashed lines). Max distance between two roboports such that they are considered to ve neighbors within tge same network (50)
• Logistic range (yellow). Area where all kind of colored chests are part of the network. For our roboports – equals to the connection range (50)
• Construction range (green). Area where construction requests are handled (110)

[Genhis]

This will be my final post on this topic because I really should work on other bug reports. I appreciate the suggestions of everyone here but we have to find the right balance of game performance, developer time and player usability. At the moment, I decided to go with the behavior I described (although maybe in not enough detail and it certainly isn't perfect). If other issues arise, we will consider them on a case-by-case basis.

@Genhis, have you considered my suggestion about introducing a limit for a roboport queue time during search while also keeping the older "closer to destination" logic? If yes, what are concern of such implantation? It looks simple enough, does not require (almost) any additional computational power, and is 100% safe against loops. Furthermore, it guarantees that the any selected path to the target would be at least as fast as slowmoving towards it.

It wasn't considered at the time of implementation. Maybe it would work with some tweaks for Aquilo where the main problem was not switching to global search if the chosen roboport wasn't closer to target. The issue with "closer to destination" was that it split roboports to two groups and the closer group were always given priority if there were any. Within a group, the logic takes into account roboport distance and robots registered for charging and tries to pick the best candidate, so at the moment there is no hard limit for charging queue, only a "preference".

And this shows how bad the current solution and fix is.

Watch the roborts right at the start. Many of them return to the roboport they just left to recharge. When a bot leaves a roboport that should be recorded as having just charged there, because that is what they do. They recharge before entering a roboport. A bot should never go back to the roboport they left from. Did you forget to set the roboport as "last charged at" when a bot leaves a roboport?

I don't appreciate the tone of your post, you don't even know all details. Like I said, robots will clear the last roboport when they complete a task - they picked up items. Your suggestion would require a larger rework for something we consider "an edge case". We don't want to encourage this kind of networks because it would likely degrade performance for networks with no gaps and many logistic bots. I am not saying we won't reconsider it in the future, but it's not in the scope of a "bugfix".

PS: maybe instead of saying "current" the actual version of the game could be used. That avoids confusion now and and in the future.

I updated the post, the video is after the fix. Before the fix, robots would just go back and forth to the same roboport, which means it didn't behave as mentioned in the FFF.

Does 'coverage' here means logistic coverage, repair coverage, or the mentioned 9x9 chunks ?

Coverage was an oversimplification and the true rule cares about the "last charged in" roboport.

[mrvn]

This will be my final post on this topic because I really should work on other bug reports. I appreciate the suggestions of everyone here but we have to find the right balance of game performance, developer time and player usability. At the moment, I decided to go with the behavior I described (although maybe in not enough detail and it certainly isn't perfect). If other issues arise, we will consider them on a case-by-case basis.

And this shows how bad the current solution and fix is.

Watch the roborts right at the start. Many of them return to the roboport they just left to recharge. When a bot leaves a roboport that should be recorded as having just charged there, because that is what they do. They recharge before entering a roboport. A bot should never go back to the roboport they left from. Did you forget to set the roboport as "last charged at" when a bot leaves a roboport?

I don't appreciate the tone of your post, you don't even know all details. Like I said, robots will clear the last roboport when they complete a task - they picked up items. Your suggestion would require a larger rework for something we consider "an edge case". We don't want to encourage this kind of networks because it would likely degrade performance for networks with no gaps and many logistic bots. I am not saying we won't reconsider it in the future, but it's not in the scope of a "bugfix".

I didn't write that to offend anyone. I'm not sure what tone you are seeing in that text. I didn't blame anyone, didn't call you names, didn't use any profanity. I'm tried pointing out that the behavior of the bot is not as it should be from what was described. That might be because your description lacked details or it might be true bugs in the implementation of the design you described. In the animation bots return to the roboport they last charged at and go to roboports that are more distance than their last roboport. Both things that were described as now being impossible so I pointed it out. Maybe you are frustated with the bot code keeping you away from more interesting things that you project a bad tone into my words. No bad tone was intended.

Apparently bots returning to their first roboport is as intended. The second issue is still unexplained.

[BlueTemplar]

Sorry for being a bother.

I asked about the range because in the last animation I noticed that at the beginning of it, on «2nd try» the bots seem to have gone a little bit further before changing course.

For further testing (even if not shared with us), it might be clearer if relevant dimensions were also shown somewhere on the map, for instance a 9x9 chunk in the middle of the C (if not too big) made out of stone bricks or something... also maybe a bar with the length that a robot can go without recharging (though that's a bit trickier and only works with no upgrade changes) ?