[2.0.20] Robots Stuck trying to build unsupported elaveted rail

[IsaacOscar]

Bassically, ghost build a section of elevated rail using the rail planner:

Screenshot 2024-11-25 155557.png (484.01 KiB) Viewed 626 times

Then delete one of the supports:

Screenshot 2024-11-25 155647.png (399.76 KiB) Viewed 626 times

Then, assuming you have enough bots, roboport coverage, and materials, wait a bit:

Screenshot 2024-11-25 155658.png (749.86 KiB) Viewed 626 times

As you can see the robots have built one of the rail supports and, parts of the rails.
The rails that are not close enough to a rail support however are not built, the robots are simply hanging around carrying the rails.

Now if you wait long enough, the robots will run out of battery and disappear. But then more robots come back!

My guess is that this behaviour is due to an optimisation: rather than have the bots wait for the rail support to be built, they get assigned straight away, so that as soon as the support is built, they can then add the rail segments. In this case however, they are waiting for something that never happens!

What I would expect to happen is that a piece of elevated rail is not assigned to a robot unless it is supported by a rail support (either real or ghost). Ideally, I'd also like a warning telling me that they can't be built.

[boskid]

This is a consequence of how construction prerequisites logic was done: when an entity declares it has construction prerequisites, then all those construction prerequisites must be constructed or at least scheduled for construction first. Issue is that since those rails are outside of support range, they simply do not have any construction prerequisites so the robots are simply allowed to go there and fly. Right now there is no way of declaring that an entity cannot be built right now without pointing at other entity that must be built first. I am not sure if i consider this a a bug, i would have to also consider all other cases where construction prerequisites logic is used. It is not crashing, not preventing you from playing, when you place a required support it starts working properly since those rails will declare as having a prerequisite now.

[IsaacOscar]

This is a consequence of how construction prerequisites logic was done: when an entity declares it has construction prerequisites, then all those construction prerequisites must be constructed or at least scheduled for construction first. Issue is that since those rails are outside of support range, they simply do not have any construction prerequisites so the robots are simply allowed to go there and fly. Right now there is no way of declaring that an entity cannot be built right now without pointing at other entity that must be built first. I am not sure if i consider this a a bug, i would have to also consider all other cases where construction prerequisites logic is used. It is not crashing, not preventing you from playing, when you place a required support it starts working properly since those rails will declare as having a prerequisite now.

Thanks for looking at it, but yes it's a very minor issue.

[Rseding91]

I'm going to put this into minor issues.