OpenTTD

Tasklist

FS#1473 - Lost trains "ignoring" exit-signals (all PFs)

Attached to Project: OpenTTD
Opened by Gav Bainbridge (kalten) - Friday, 23 November 2007, 02:22 GMT
Last edited by andythenorth (andythenorth) - Friday, 18 August 2017, 20:17 GMT
Type Feature Request
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity Very Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I noticed this in r11487 and r11490 and tested in 0.6.0-beta1 but it may be an inherent problem with pathfinding.

If a train is trying to indirectly get to a station by going to another station first, the train will ignore the signalling and an available platform and try to go to the easiest platform even if another train is occupying it. It will then get stuck until that platform becomes free or the orders are changed.

I've attached a save where you can see this happening. Go to Drendbourne station. Train 41 is set with different orders to the others in this mini route. Train 36 has been stopped in the easy platform to force trains to use the available platform.
This task depends upon

Closed by  andythenorth (andythenorth)
Friday, 18 August 2017, 20:17 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Flyspray clean up: more than 5 years old, and not obvious what should be done with this next, so closing. If this offends, discuss with andythenorth in irc. Thanks.
Comment by Remko Bijker (Rubidium) - Friday, 23 November 2007, 05:30 GMT
Seems that only the YAPF pathfinder does something strange in this case. KUDr, can you take a look?
Comment by KUDr (KUDr) - Friday, 23 November 2007, 09:14 GMT
I am not sure what I can do with it. You are using unimplemented YAPF feature - 'bouncing at dead end' so the behavior is undefined in this case, which is correct. By my opinion it makes no sense to try to correct the behavior in case when train is lost. We can of course reconsider if we really need to support bouncing trains (and then implement it as a new feature - which would be very complex and would slow down pathfinding a lot) or let it unsupported (and then close it as it is not a bug).

I can't imagine (on PF level) how to tell which path is better if none of them leads to the destination. Simply in this case the wrong path (dead end on the red signal) ends earlier (closer to the destination) so it has better score than the proper path (free platform). Any ideas?

In the provided map the easiest solution I can see is to allow 90-deg turns. Then the Train 41 will turn 90-deg right before the station and will head to its destination. Otherwise please ensure that your paths don't require bouncing as YAPF was not designed to support them.


Comment by Remko Bijker (Rubidium) - Friday, 23 November 2007, 09:18 GMT
The 'problem' is that the train is not technically lost. If it turns at the given station, it can go to the correct station. In my opinion is should be able to find a path.
Comment by KUDr (KUDr) - Friday, 23 November 2007, 09:40 GMT
From PF view the train is lost (the same for all PFs). So technically i would tell it is lost. Maybe logically not, because there is a path in this particular case. But:
1. PF doesn't support such path so it can be only guessed
2. In any other case (i.e. train longer than the free platform) it would not work anyway.

Do we really need YAPF to support such situations? Then we would need to implement full bouncing (so that pathfinding continues after dead-end, reversing the train, check if the train can reverse there - if the dead end is long enough etc.). Then the number of possible paths will be significantly higher with performance impact, lot of new bugs and so on. I think it is not worth the effort needed.

And on the other side, any half way solution (i.e. system hammer: 'if (3+3 == 7) then 3+3 == 6') would not work in all cases anyway. From that perspective it is better as it is:
unsupported feature -> lost train -> undefined behavior.

Comment by Remko Bijker (Rubidium) - Saturday, 24 November 2007, 09:31 GMT
But why does it work for NPF and OPF? Must be something that causes this 'issue' only to happen with YAPF.

Anyway, I do not think it is good behaviour (when a train is lost) that when you passed a pre-combo signal you go to just 'any' exit, you should go to an exit that is green (if there is one).
Comment by Remko Bijker (Rubidium) - Sunday, 25 November 2007, 19:18 GMT
Another thing to 'note' is the fact that YAPF does not tell that it did not found a path; path_not_found is not set to true.

And as I said before, in my opinion it should not choose a 'red' signal track when it can get into a 'green' signal track.
Comment by Remko Bijker (Rubidium) - Sunday, 09 December 2007, 20:00 GMT
Even when we decide not to support bouncing in YAPF (even though NPF supports it), there is still the issue of the train going to a red signal when it can 'choose' a green one. As it is a 'lost' train you do not really matter where it goes, but 'deliberatly' chosing a red signal seems wrong to me.
Comment by KUDr (KUDr) - Monday, 10 December 2007, 02:13 GMT
ok, agree that it can behave better in that case. Leave it open for me. Since when NPF supports bouncing from dead end?
Comment by dasy2k1 (dasy2k1) - Monday, 05 May 2008, 07:42 GMT
It does seem odd that it deliberately breaks the Presignaling when this occurs,
if the preesignal block entry is green then regardless of all else the train should chose a green exit.
in all cases when entering a presignal block there must be at least 1 green exit otherwise the entry would be denied.
Comment by Michael Lutz (michi_cc) - Monday, 06 October 2008, 11:21 GMT
NPF and NTP are broken as well. The attached savegame demonstrates the problem. For NTP you have
to remove one of the tracks so the train can't do a 90-degree turn anymore.

This is because NPF and NTP choose a trackdir that leads to the tile nearest to the destination
in case no path is found, which in this case is the lower platform. YAPF always chooses the
first trackdir, which leads to the upper platform in this case.
Comment by Konstantin Pelepelin (checat) - Sunday, 10 January 2010, 12:16 GMT
  • Field changed: Percent Complete (100% → 0%)
Trains often get "lost" when network is good, but locally overloaded, they get "lost" at time of redesigning some parts of network, and this particular problem means player needs to stop a vehicle just a moment it becomes "lost" (is it reported in time?) before it makes all network stuck.

Is it so hard (as it said) to check the way up to nearest signals before making completely random selection of a way?

Cite: "in this case the wrong path (dead end on the red signal) ends earlier (closer to the destination) so it has better score". It looks reasonable for programmer, but not a good solution for player.
Comment by Remko Bijker (Rubidium) - Sunday, 10 January 2010, 12:18 GMT
Doubling the maintainance cost of OpenTTD and the general pathfinding for this corner case isn't likely to happen.
Comment by Ed Penwell (Lusankya) - Monday, 26 April 2010, 04:51 GMT
The issue doesn't appear with YAPF, which is the recommended train pathfinder. Yes, it's unfortunate that NPF and NTP mess this up, but there's something to be said for network design. No PF handles end bouncing very well, but in this case YAPF seems to take it pretty well.

Konstantin, can you provide a savefile showing YAPF bugging out in a similar way? I'm of the mind that the bug be ignored if we can't reproduce with the recommended PF.

Loading...