FS#3908 - Another PBS problem

Attached to Project: OpenTTD
Opened by Vít Šefl (Vitus) - Sunday, 27 June 2010, 12:46 GMT
Last edited by Remko Bijker (Rubidium) - Saturday, 15 January 2011, 22:41 GMT
Type Bug
Category Vehicles → PBS
Status Closed
Assigned To No-one
Operating System All
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



consider the following savegame. As you can see, trains are running into back of PBS signal, even though they "should" continue.
I know, this is special case where trains cannot find way to its destination and don't obey "normal" rules. However, if you change the path signal to normal, block signal (as shown in the picture), this layout works correctly.

I tried to track down this bug and it got introduced in between r19894 and r19897, most likely in r19896.

Now, this wouldn't be that bad, as it can be fixed (see picture), but it breaks down MANY savegames (namely Public Server Games from openttdcoop; for example #172, #180, #185...).

Thanks for your time,
This task depends upon

Closed by  Remko Bijker (Rubidium)
Saturday, 15 January 2011, 22:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r21815
Comment by Daniel (chillcore) - Monday, 28 June 2010, 19:44 GMT
I have a problem too in one of my older savegames.
The indicate train in the attached screenshot has gotten itself stuck causing a deadlock. I can not get itself stuck without me taking action.
In the same savegame I have disabled trains reversing when waiting for signals to turn green by setting the needed parameters in the config file to 255. As trains now prefer the back of a one-way path signal over the front of a normal pbs signal this causes some more problems elsewhere in my savegame too.

Using the same setup, when you release a train with no orders the train will go back and forth between the two one way path signal although there are other paths available.
I have tested this with a new savegame in recent trunk (r20031), clean config and just 1 loc to make sure the train does not get stuck due to its lenght. (Like in the screenshot)

Also I have tested a few coopsavegames and can confirm the problems reported by Vitus.

Reverting r19896 in my source solved the issues.

ps: Just for information, I was not using my patchpack for testing but clean trunk.
Comment by Zdeněk Sojka (SmatZ) - Tuesday, 29 June 2010, 18:35 GMT
Is there any other solution than breaking old savegames, or breaking  FS#3803 ?
Comment by Daniel (chillcore) - Wednesday, 30 June 2010, 15:53 GMT
I have tried to solve the problem in current trunk by increasing "yapf.rail_pbs_signal_back_penalty" but even setting it t 2.000.000 did not solve the issue when a train with no orders leaves the depot it still goes for the back of the one way signal.
The train (1 loc) however did continue normally after having hit both one way signals' backside. (Depot setup as in previous posted screenshot.)

I see the problems with SF3430 & 3803.
I do not see how to solve those cases other then enclosing the station with normal pbs signals facing the station or making a dead end section as shown in the attached picture.
Only applying 1 solution is sufficient for letting the trains exit the depot.

Another solution would be to not let a train reserve a path past a station -> let a station be a safe waiting point.
But where or how to do that is out of my grasp for the moment.
Also would not reserving past a station cause other problems? -> Trains only passing through en route for the next station.

different issue same cause

I have seen another problem too with current trunk while testing.
See second picture.
When the train reserves its path up to the back of the one way signal the patch stays reserved until the train has finishes loading and turns around to continue to the next station, preventing trains coming from the correct direction to enter the station.

IMHO one way patch signals are for indicating that a specific track is meant to be one way direction only and allowing a train to go for the back of one is wrong and causes more problems then it solves.
Comment by Vít Šefl (Vitus) - Wednesday, 30 June 2010, 16:48 GMT
chillcore, yapf.rail_pbs_signal_back_penalty is setting for pathfinder penalty for reserving path through the back of normal (i.e. twoway) PBS. It has no influence on one-way PBS whatsoever, because pathfinder treats back of one-way PBS as end-of-line.

However, the problem indicated in second picture (current_trunk.png) might be the main problem of  FS#3803 . It kind of defeats the purpose of having safe waiting locations in first place - I mean, back of one-way PBS cannot be safe waiting location simply because it's part of entrance track for trains coming from other direction (as shown in the picture). As for trains, that want to enter the station from the other side, there already is perfectly acceptable solution - i.e. making the station truly two-way (enclosing it with two-way PBS).
Comment by Daniel (chillcore) - Wednesday, 30 June 2010, 19:44 GMT
Thank you vitus for pointing out my misstake with the pbs_signal_back penalty.
So to fix the "train_deadlock.png" problem and your initial problem in current trunk we would need an "rail.track_end" penalty. As far as I can see there is no such penalty for the moment or I have overlooked in the config file.

If we have to fix the "current_trunk.png" problem with having signals all around the station then I wonder what the point is of r19896 as that can be solved in the same way as shown in "possible_fix_..._png"

Not an easy matter it seems.
Comment by Vít Šefl (Vitus) - Wednesday, 30 June 2010, 20:49 GMT
"rail.track_end" penalty would be pointless. Pathfinder takes the penalties in account when searching route - and routes which do not lead to its destionation (i.e. track ends in most cases) are disregarded, if the pathfinder cannot find route, then it hardly obeys any penalties.

I've tried to create a savegame which illustrates this. It might not be fully accurate (it's just set of observations after all), but it should help you understand why this happens.
(application/octet-stream)    pbs4.sav (13.2 KiB)
Comment by Vít Šefl (Vitus) - Wednesday, 30 June 2010, 21:12 GMT
Also, in order to (somehow) further illustrate the impacts of r19896 I've created another savegame.

First two stations (1,2) are both terminus. The first one (1) is example of layout, which works thanks to r19896. However, if you wish to build this "filling" depot (call it whatever you like), you can also make the station truly twoway (2) and it should work, too.

The rest (3,4,5) are RoRos. Now, the third station (3) is also working thanks to r19896. If you remove the row of one-way PBS in front of the station, train are going to reserve path up to the one-way PBS at the station entrance - and thus blocking any incoming trains (even from depot side). If you do keep the row in front of station, none of these signals is safe waiting point and trains might end up blocking the junction - this station entrance layout it just not going to work.

Fourth station (4) fixes the safe waiting points by adding more waiting space. But then again, this is completly unnecessary. If you do want to keep the waiting space, it can also be built without any trains needing back-of-PBS safe point (5).

Sorry for double post, but I didn't want to mix up the attachments.

edit: (1) works thanks to  FS#3430 , so does (3) and (4). As long as the one-way PBS are directly in front of platforms, that's it. My mistake, sorry.
(application/octet-stream)    pbs3.sav (11.6 KiB)
Comment by Michael Lutz (michi_cc) - Wednesday, 30 June 2010, 21:33 GMT
As long as "lost" trains are concerned, no pathfinder penalty will make any kind of difference.

What needs to be modified is CYapfDestinationAnySafeTileRailT::PfDetectDestination (yapf_destrail.hpp)
to exclude unwanted safe positions. It would just break  FS#3430  and anything similar. And probably a
bit more as the safe tile search is also used to extend the path after a station when normal
pathfinding fails.
Comment by Vaclav Benc (V453000) - Friday, 02 July 2010, 23:00 GMT
Hmm ... speaking of "standard situations" I have found a completely ordinary issue that happens to anyone who uses "autoreplace vehicles" ... the issue is: if a train can no t find a path from the depot it autoreplaced in (and that is really not-so-predictable), it is possible that it will NEVER get out of the depot ... see savegame, pink company, train 8
Also, (I dont have a proof of that) it can cause issues whenever breakdowns are on ... when train services in a depot that is built with PBS (note that 90% of peole use ONLY, ONLY, and ONLY PBS! at the current time also because OpenGFX signals arent visible and PBS are the only "a bit visible") therefore, whenever people use PBS in such cases (a lot) then it could fail ... I have no clue what this caused but it is a very serious issue from my experienced point of view ... ;) Thanks, V453000
Comment by foo bar (TomyLobo) - Tuesday, 06 July 2010, 05:44 GMT
Daniel, if PBS doesn't work, you just use more :)
see the attached screenshot.
I added signals to the top end of the left station, to terminate the pathfinding of the train in the station.
The 2nd train can still find paths through the back of the signal.
just make sure you use them in all of the station tracks or you'll get odd prioritizations since passing through the back of a path signal has a huge penalty in the pathfinder.
Comment by Daniel (chillcore) - Wednesday, 07 July 2010, 15:31 GMT
Tomy, adding signals to enclose the station is my default way of doing things but thank you for the hint anyway. ;)
I was just reusing the setup from "Frunford Transport,... .sav" posted by Alberth in  FS#3803 .

As for train 8 in "Haulin'ltd., ... sav", it has orders and it is still running into the back of the signal.
I do not mean to sound like a mantra but reverting r19896 also solves that problem.
I had noticed the behaviour before but forgot about it until seeing the savegame.

Could someone please tell me how to make a "striked link" when posting a closed FS task number?
Feel free to PM me on the forum to not pollute this page ...
Comment by Daniel (chillcore) - Wednesday, 07 July 2010, 15:34 GMT
Sorry for double posting.
Nevermind my ps, typing correctly seems to have solved my problem.