[1.1.104] Robot drone pathfinding: infinite loops
Posted: Thu Apr 04, 2024 1:09 am
[Running a long game with Space Exploration & Krastorio 2 mods ... but I don't think either of those change robot pathfinding]
I happen to build large bases with a single huge robotport network, following all train lines and to all remote mines. (I realize this may not be "best practice", but it allows for automatic repair everywhere when the meteors hit or cargo rockets go off course.)
Imagine a star-shaped or asterisk-shaped robo network. Long thin arms, only connected at the center. A bunch of robots decide to travel from the end of one spoke, to the end of an adjacent (but very far away) spoke. They run out of power (less than) halfway there. As far as I can tell, they seem to (very slowly) return to their origin to recharge ... and then try the journey one more time again. Which results in an infinite loop, where they NEVER make it to the destination. This means not only is that robot completely useless for the rest of the game, and not only is its cargo hostage and useless ... but also the robot request NEVER gets satisfied, because the game thinks that "some" robot has been assigned the task, so it never assigns the task to any other robot.
I suspect the logic is something as simple as, "Try to head in a straight line to your target. If you run out of power, then change subgoals to travel slowly to the nearest robotport for recharging". That's indeed simple logic, and usually "works" ... but it results in infinite loops and denial of service, if the "closest roboport" happens to be in the exact opposite direction of the current target destination.
Even if it takes a long long time (e.g. on low power) ... the robot logic SHOULD ensure that there is NEVER complete starvation. The automatic pathfinding should always make at least SOME progress. There should never be infinite loops.
But, from my experience ... I think that there are, right now. I've noticed what look like infinite loops in pathfinding, and I've noticed robot tasks (requester chests, repair to damaged bases) that seem never to get filled, even after hours of game time.
I happen to build large bases with a single huge robotport network, following all train lines and to all remote mines. (I realize this may not be "best practice", but it allows for automatic repair everywhere when the meteors hit or cargo rockets go off course.)
Imagine a star-shaped or asterisk-shaped robo network. Long thin arms, only connected at the center. A bunch of robots decide to travel from the end of one spoke, to the end of an adjacent (but very far away) spoke. They run out of power (less than) halfway there. As far as I can tell, they seem to (very slowly) return to their origin to recharge ... and then try the journey one more time again. Which results in an infinite loop, where they NEVER make it to the destination. This means not only is that robot completely useless for the rest of the game, and not only is its cargo hostage and useless ... but also the robot request NEVER gets satisfied, because the game thinks that "some" robot has been assigned the task, so it never assigns the task to any other robot.
I suspect the logic is something as simple as, "Try to head in a straight line to your target. If you run out of power, then change subgoals to travel slowly to the nearest robotport for recharging". That's indeed simple logic, and usually "works" ... but it results in infinite loops and denial of service, if the "closest roboport" happens to be in the exact opposite direction of the current target destination.
Even if it takes a long long time (e.g. on low power) ... the robot logic SHOULD ensure that there is NEVER complete starvation. The automatic pathfinding should always make at least SOME progress. There should never be infinite loops.
But, from my experience ... I think that there are, right now. I've noticed what look like infinite loops in pathfinding, and I've noticed robot tasks (requester chests, repair to damaged bases) that seem never to get filled, even after hours of game time.