Attached is a patch for revision 7002 to get closer to a break in a route. However, the heuristics of close are such that this fails way too often. Hence I did not commit it.
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)
Quote from: Dwachs on January 02, 2014, 08:50:54 AM
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.
I think the idea with high weights for non-existing tiles is a good one. I am just worrying that this may take quite a while (i.e. the whole map) when an unconnected tunnel comes into play ...
EDIT: I hope the attached patch works better.
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.
I was thinking to integrate this into the regular way search, i.e. return the tile for non-existing connections. For this the weight needs to be very height to find any existing connection first.
find_way_break2.patch isn't gcc friendly with what it does on route.h line 82. gcc doesn't like the part up to and including the first pair of colons.
Is this patch supposed to actually inform of which break position it found?
Quote from: prissi on January 03, 2014, 06:18:44 PM
I was thinking to integrate this into the regular way search, i.e. return the tile for non-existing connections. For this the weight needs to be very height to find any existing connection first.
Imho this addition should only be used when the user requests it. Otherwise there is always the risk of performance hits and false negative reports.
Quote from: Ters on January 03, 2014, 11:23:07 PM
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.