OpenTTD

Tasklist

FS#2274 - (No) Reversed trains on one-way PBS tracks

Attached to Project: OpenTTD
Opened by Marcel Sondaar (Combuster) - Friday, 05 September 2008, 09:46 GMT
Last edited by andythenorth (andythenorth) - Friday, 18 August 2017, 19:26 GMT
Type Feature Request
Category Vehicles → PBS
Status Closed
Assigned To andythenorth (andythenorth)
Operating System All
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Trains that are reversed to face a one-way PBS signal will wait indefinately for a free path (which obviously never happens since you can't go past one), thus blocking the entire track for excessive periods of time.

One possible solution for this is to allow the pathfinder to plan toward one-way PBSes, after which they would be reversed again like with regular one way signals.

Example image made in nightly r14215 - effect seen in various versions
This task depends upon

Closed by  andythenorth (andythenorth)
Friday, 18 August 2017, 19:26 GMT
Reason for closing:  Won't implement
Additional comments about closing:  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.
Comment by Michael Lutz (michi_cc) - Friday, 05 September 2008, 11:52 GMT
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.
Comment by Marcel Sondaar (Combuster) - Sunday, 07 September 2008, 09:45 GMT
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 - https://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)
Comment by Michael Lutz (michi_cc) - Sunday, 07 September 2008, 11:39 GMT
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.
Comment by Marcel Sondaar (Combuster) - Tuesday, 09 September 2008, 21:23 GMT
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.
Comment by AnthonyVDG (avd) - Saturday, 01 November 2008, 20:45 GMT
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,...)

Loading...