Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DorpsGek opened this issue Nov 23, 2007 · 14 comments
Closed

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

DorpsGek opened this issue Nov 23, 2007 · 14 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

kalten opened the ticket and wrote:

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.

Attachments

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/1473
@DorpsGek
Copy link
Member Author

Rubidium wrote:

Seems that only the YAPF pathfinder does something strange in this case. KUDr, can you take a look?


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2782

@DorpsGek
Copy link
Member Author

KUDr wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2786

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2787

@DorpsGek
Copy link
Member Author

KUDr wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2788

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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).


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2799

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2811

@DorpsGek
Copy link
Member Author

DorpsGek commented Dec 9, 2007

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2923

@DorpsGek
Copy link
Member Author

KUDr wrote:

ok, agree that it can behave better in that case. Leave it open for me. Since when NPF supports bouncing from dead end?


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment2928

@DorpsGek
Copy link
Member Author

DorpsGek commented May 5, 2008

dasy2k1 wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment4059

@DorpsGek
Copy link
Member Author

DorpsGek commented Oct 6, 2008

michi_cc wrote:

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.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment4827

@DorpsGek
Copy link
Member Author

checat wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment7324

@DorpsGek
Copy link
Member Author

Rubidium wrote:

Doubling the maintainance cost of OpenTTD and the general pathfinding for this corner case isn't likely to happen.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment7325

@DorpsGek
Copy link
Member Author

Lusankya wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473#comment7941

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/1473

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant