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

Jump to bottom

Trains chosing an alternative path when encountering a 1-way presignal instead of waiting #50

Closed
DorpsGek opened this issue Feb 7, 2006 · 8 comments
Closed

Trains chosing an alternative path when encountering a 1-way presignal instead of waiting #50

DorpsGek opened this issue Feb 7, 2006 · 8 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Feb 7, 2006

StarLite opened the ticket and wrote:

If a way is blocked for a train, and it has to choose a way, it will CHOOSE the free way even it find 2 1-way signals, but ONLY in the direction of it's target. aka: it will never go to a north 1-way of the target is south of it.
This behaviour only accurs when there is a PRE-SIGNAL in front of it, in case of a normal signal it will behave as normal.
Attached are 5 screenshots of a test where the bug occured.

Attachments

Reported version: 0.4.5
Operating system: All

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

DorpsGek commented Feb 7, 2006

StarLite wrote:

This bug was encountered with NTP, no NPF.
Game settings below

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment103

@DorpsGek
Copy link
Member Author

DorpsGek commented Feb 7, 2006

StarLite wrote:

Same bug, but with a normal signal instead of a pre-signal.

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment104

@DorpsGek
Copy link
Member Author

Celestar wrote:

could you just provide a savegame?

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment226

@DorpsGek
Copy link
Member Author

StarLite wrote:

Here it is

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment231

@DorpsGek
Copy link
Member Author

DorpsGek commented May 4, 2006

KUDr wrote:

I guess we should rather call it feature than bug. Can't expect that all PFs will behave the same:

  1. NTP loops regardless of the signal type (one/two-way)
  2. NPF always goes straight (and train stops)
  3. YAPF chooses the straight when signal is one-way and loops on two-way signal

Can we tell which one works correctly?
And can we tell that the other two pathfinders are broken?

I guess the correct answers are "No" and "No".

Opinions?

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment256

@DorpsGek
Copy link
Member Author

Tekky wrote:

I disagree with the last post. Pathfinders in general should only select routes which take the vehicle to its target. They should never loop.

YAPF's behavior may be acceptable if you assume that two-way signals are supposed to explicitly instruct the train to "choose" a green signal. However, I believe that one-way and two-way signals should both be treated the same by the pathfinder, as is the case with NPF.

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment292

@DorpsGek
Copy link
Member Author

KUDr wrote:

Pathfinder should select the best route. The only thing we can discuss about is if it is better to stop the train or let it wait while it moves (loop). It depends on the situation and on your opinion. The statement "They should never loop." is totally invalid.

Only the valid statement would be "I would like to stop the train rather than to let it loop." or "It is better to don't stop the train and continue moving until the path is free.".

This comment was imported from FlySpray: https://bugs.openttd.org/task/50#comment293

@DorpsGek
Copy link
Member Author

DorpsGek commented Nov 2, 2006

Darkvater closed the ticket.

Reason for closing: Not a bug

Not a bug, (mis/dis)interpretation of pathfinder logics

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

@DorpsGek DorpsGek closed this as completed Nov 2, 2006
@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) Vehicles labels Apr 6, 2018
@andythenorth andythenorth mentioned this issue Jun 29, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek