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

waiting for free path... why? #3430

Closed
DorpsGek opened this issue Dec 26, 2009 · 4 comments
Closed

waiting for free path... why? #3430

DorpsGek opened this issue Dec 26, 2009 · 4 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

planetmaker opened the ticket and wrote:

see the attached savegame, planetmaker transport, train # 23. It's waiting for a free path and I don't understand why.

It will leave the depot and enter the station as expected, if another fuel oil train arrives (will in a couple of days).

Dunno, if it's a bug or I'm missing or not seeing something... But better post it here than forget :-)

Attachments

Reported version: 1.0.0-beta1
Operating system: All


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

planetmaker wrote:

The other train will arrive approx. 16th July, so a bit of fast-forward is needed.

It might also be an issue with the penalties to the PF... though I don't understand it then either.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3430#comment7132

@DorpsGek
Copy link
Member Author

michi_cc wrote:

The train wants to go to the top platform as it's the shortest way, but there's
a blocking block signal at the end. The back of a signal is not considered as a
safe waiting point.

This can be easily changed, but there's a big drawback in doing that, as seen in
the attached screenshot. The block signal is not red because the train is not
in the signal block. Letting trains propagate through path signals could be done,
but for somebody predominately using path signals, that would could mean every
signal update might have to search the whole rail network. Not nice from a perfor-
mance point.
There are safeguards against entering a PBS block through a block
signal, but they can't catch every possible situation (as seen in the second
screenshot). That could be solved by checking every path tile for a train, but
that gets expensive very fast.

Making only the back of a one-way path signal a safe position is possible as
path signals don't depend on signal blocks.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3430#comment7134

@DorpsGek
Copy link
Member Author

michi_cc wrote:

Proposed patch for the one-way path signal case:
http://www.icosahedron.de/cgi-bin/gitweb.cgi?p=openttd.git;a=commitdiff;h=97bf9ac8e423cec89dd9ce3cc35ac49251f70bf1

Replacing those block signals at the platform end with one-way patch signals
will make the example then work as intended.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3430#comment7136

@DorpsGek
Copy link
Member Author

michi_cc closed the ticket.

Reason for closing: Fixed

In r18648, at least for the one-way path signal case. Doing the same for block signals causes too many problems in other code parts and won't be implemented.


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

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) bug labels Apr 7, 2018
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