OpenTTD

Tasklist

FS#3430 - waiting for free path... why?

Attached to Project: OpenTTD
Opened by Ingo von Borstel (planetmaker) - Saturday, 26 December 2009, 11:58 GMT
Last edited by Michael Lutz (michi_cc) - Sunday, 27 December 2009, 14:39 GMT
Type Bug
Category Vehicles → PBS
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 1.0.0-beta1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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 :-)
This task depends upon

Closed by  Michael Lutz (michi_cc)
Sunday, 27 December 2009, 14:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  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.
Comment by Ingo von Borstel (planetmaker) - Saturday, 26 December 2009, 12:12 GMT
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.
Comment by Michael Lutz (michi_cc) - Saturday, 26 December 2009, 16:49 GMT
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.
Comment by Michael Lutz (michi_cc) - Sunday, 27 December 2009, 02:08 GMT
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.

Loading...