chillcore wrote:

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.

Attachments

• Train_deadlock.png (12.29 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8204

SmatZ wrote:

Is there any other solution than breaking old savegames, or breaking #3803?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8205

chillcore wrote:

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.

Attachments

• possible_fix_FS3803_&_3430_after revert_r19896.png (33.18 KiB)
• current_trunk.png (33.13 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8211

Vitus wrote:

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 #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).

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8212

chillcore wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8215

Vitus wrote:

"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.

Attachments

• pbs4.sav (13.20 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8216

Vitus wrote:

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 #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.

Attachments

• pbs3.sav (11.63 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8217

michi_cc wrote:

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 #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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8218

V453000 wrote:

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

Attachments

• Haulin' ltd., 2049-07-19.sav (923.23 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8234

TomyLobo wrote:

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.

Attachments

• openttd-morepbs.png (47.09 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8257

chillcore wrote:

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 #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.

ps:
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 ...

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8261

chillcore wrote:

Sorry for double posting.
Nevermind my ps, typing correctly seems to have solved my problem.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3908#comment8262

Rubidium closed the ticket.

Reason for closing: Fixed

In r21815

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