michi_cc wrote:

The PBS implementation is based on the principle of finding paths to safe stopping locations.
At signals, only the side with the lights is considered a safe location.

If a train can't find a path, it will not wait indefinitely but for 'pf.wait_for_pbs_path' days.
Even though this setting has no GUI represenation, it can be changed with the in-game console.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2274#comment4693

Combuster wrote:

That patch option is flawed (assuming you set it to 'no' reversing for PBS), since you can no longer mix block and path signals properly.

Given a PBS area, after which you get a block-signalled area, trains will deadlock:
----> PBS -----> normal signal ---(block occupied)--->
A train enters from the left, finds a path from the PBS signal to the block signal. After a small delay it will reverse (since its not a pbs signal, hence the setting has no effect)
Now it will start looking for a path, but if something is blocking the path from behind the PBS (which it will have to plan beyond), it can never find a path, and is stuck forever since it will never reverse (since its waiting for a path)
And as of that point, a deadlock occurs.

The only way to cope is to use PBS exclusively, which isn't a viable option since that'd disallow the use of presignals for deadlock safety (and with presignals you can solve advanced problems not possible with PBS)

I've been discussing this with some of my fellow players, and there are several 'safe' solutions for these problems:
- As per my proposal above: allow PBS to plan paths to one-way signals as if they were dead ends (i.e. only when a path to the destination can not otherwise be found)
- Do not even reverse on PBS blocks if there is no way out (was posted on tt-forums.net by someone else before me - http://www.tt-forums.net/viewtopic.php?f=33&t=36107&p=702892&hilit=PBS# p702892)

And some less intelligent solutions:
- Do not reverse on PBS blocks (as opposed to not reversing in front of PBS signals)
- Disable reversing of trains altogether (except stations and all cases where reversing would be immediate, like end of line or wrong way block signal)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2274#comment4706

michi_cc wrote:

Did you actually try your scenario? Then you would find that on setting pf.wait_for_pbs_path
to 255 that the train will in fact not reverse in front of the normal signal.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2274#comment4708

Combuster wrote:

I have made a clean testcase and it seems to do as you described. However in a recent multiplayer game (where we put that patch setting on because it the issue causing no end of trouble), trains still did lock up in places where the normal signals weren't replaced by path signals, and then permanently.

It does conflicts with the defined behaviour of that setting.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2274#comment4725

avd wrote:

Isn't it possible to look at the block if there is any exit that is possible (behind the train) before the train is turning?
So YAPP will look at the signals at the exit so YAPP can know witch tracks he may not going out, if there is no exit, the train will stay waiting...

Im not C++ programmer, but I think that will be possible (but should it use much cpu, other bugs,...)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2274#comment4977

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/2274