Your routine searches the position that is as closest to the target as possible. Another possibility would be to treat all non-passable tiles as passable but with absurdly high weight. The weights could depend on the reason why no passage is possible (no electrification, wrong signal direction, ways not connected, no ways at all etc)

Your routine searches the position that is as closest to the target as possible. Another possibility would be to treat all non-passable tiles as passable but with absurdly high weight. The weights could depend on the reason why no passage is possible (no electrification, wrong signal direction, ways not connected, no ways at all etc)

Sounds like possibly a good idea, except maybe for when there are no ways at all. I would assume that most issues with breaks is simply from one tile to the next, so if the initial (current) way finder fails, then do another one that ignores signs/signals, electrification and to some extent ribis, but marks the tiles when it did this and use a higher cost. Once a route is found with these relaxed constrains, the marked tiles in it will be the likely problem points. If the marking also includes the type of cheat required, it will also help the player figure out what must be corrected.

It is possible that the weight doesn't need to be very high if one already knows that there is no functioning path, although the weight may have to be tuned based on how likely the type of break is. Two bridges meeting end-to-end, bridge meeting tunnel, or even bridge meeting some platforms, without being connected seems like something that can be given a low weight.

Is this patch supposed to actually inform of which break position it found?

I now see that it doesn't work if the first leg out of the depot is broken. If I put a waypoint between the depot and the break, I get a message with some coordinates. The coordinates are nowhere near the break, though. I get the last and second to last coordinate of the intended path, while the break is at the ninth last coordinate.

UPDATE:Seems like signals facing the wrong way don't trigger extra cost. It might be this that causes the observed behaviour.