YAPP - Yet Another PBS Patch (now in trunk!)

[paradigm]

My experience and experimenting tells me that a train prefers a one-way route over a two-way regardless of length of the two, if both lead to the desired destination.

Well I didn't thought about that...

I made a cleaner test setup and as far as I can tell, it doesn't really matter if a route has a one-way signal or not, but if there is a signal facing in the other direction. If there is an equal amount of signals facing the other direction on both routes, the train choses the shortest path. Otherwise the penalty for one such signal equals about 13 tiles of detour the train will take to avoid the signal.

As I said, this is generally a desired behaviour (feature) but it could be nice to have lower or no penalty in cases where trains would otherwiese take weird paths, just to avoid a single signal, just because it doesn't look at them

But this is more a nice-to-have feature than a real bug, so there is nothing to be "fixed".

[RMJ]

Ive been looking at found the signalw.grf and a ttdpbasew.grf and neither could i get working with openttd :/ how to you get the signal graphics for this patch ?

[T-Unit]

I suggest you run the game with "openttd.exe -d pbs=2" in order to see all reserved PBS paths. Also, I really recommend you don't mix the new PBS signals with the old traditional signals.

Thanks. But how do i run that? (sorry bit of a patch-testing noob)

[Vikthor]

You have to run it from command line. (Click on run in the start menu, type "cmd" (In Windows XP)). Other, and probably easier, option is to open console in openttd (press the key above Tab) and type "debug_level pbs=2".

[Eddi]

i have a reproduceable scenario of a PBS caused crash, that does not involve player interaction:

first picture, everything is in order, PBS junction is on the left of the picture, let's follow the Woods train coming from the left, driven by an E 94 (DB: BR 194), dragging 18 woods wagons.

Ravenswald Transport, 11. Mär 1975.png

(280.15 KiB) Downloaded 347 times

now a few ticks later, the E 94 waits in front of a red signal, the last wagon just exited the reserved signal block, the next woods train driven by a BR 150 on the left will now reserve a path through the PBS signal, because no tiles are reserved.

Ravenswald Transport, 12. Mär 1975.png

(275.19 KiB) Downloaded 336 times

BOOOOM!

Ravenswald Transport, 14. Mär 1975.png

(282.46 KiB) Downloaded 298 times

Solution: when reserving a path, reserve the target signal tile as well [the old PBS patch did that]

@T-Unit:
when you fetch r12079 (or the next nightly in 3 hours), you can create a file named 'autoexec.scr' in the scripts subdirectory, with the line "debug_level pbs=2" in it

[YukonRob]

Great work. One thing I would like to see tweaked; when I have it set to build advanced signals (vs one way advanced signals) could it cycle through the signals the same way as regular signals (ie. 2 way, 1 way, 1 way)? When I build under bridges or behind buildings I am always putting in the wrong signal because I can't see what I am doing and the click order has changed.

I also tend to get a lot more 'train x is lost' messages, is this do to your pathfinding? Or my poorly designed network?

Keep up the great work!
Rob

PS - I also love the (un?)intentional side effect of forcing trains into depots when the track does get backed up.

[Eddi]

My experience and experimenting tells me that a train prefers a one-way route over a two-way regardless of length of the two, if both lead to the desired destination.

Well I didn't thought about that...

I made a cleaner test setup and as far as I can tell, it doesn't really matter if a route has a one-way signal or not, but if there is a signal facing in the other direction. If there is an equal amount of signals facing the other direction on both routes, the train choses the shortest path. Otherwise the penalty for one such signal equals about 13 tiles of detour the train will take to avoid the signal.

As I said, this is generally a desired behaviour (feature) but it could be nice to have lower or no penalty in cases where trains would otherwiese take weird paths, just to avoid a single signal, just because it doesn't look at them

But this is more a nice-to-have feature than a real bug, so there is nothing to be "fixed".

use the patch setting "yapf.rail_pbs_signal_back_penalty" to change this, default appears to be 2500 (equals 25 tiles, but the length of acceptable detours are different, depending on other penalties like curves)

[Michi_cc]

use the patch setting "yapf.rail_pbs_signal_back_penalty" to change this, default appears to be 2500 (equals 25 tiles, but the length of acceptable detours are different, depending on other penalties like curves)

It's rather high currently, I think I will lower this penalty in the next version. I initially chose such a high value because the first patch didn't have one-way pbs signals, only extra no-entry signals. As this isn't the case anymore, a lower default is better I belive.

Great work. One thing I would like to see tweaked; when I have it set to build advanced signals (vs one way advanced signals) could it cycle through the signals the same way as regular signals (ie. 2 way, 1 way, 1 way)? When I build under bridges or behind buildings I am always putting in the wrong signal because I can't see what I am doing and the click order has changed.

The click order hasn't really changed, the signals starts as if you had clicked once already. Changing this to default two-sided signals means you will almost always have to click extra, as two-sided pbs signals are not very usefull.

I also tend to get a lot more 'train x is lost' messages, is this do to your pathfinding? Or my poorly designed network?

I didn't modify the core of the pathfinder, so if a path was found before, it should still be found. A factor might be that trains will follow their reservation, even if it is not the optimal route. Depending on your network, this might have a detrimental effect on the pathfinder.

PS - I also love the (un?)intentional side effect of forcing trains into depots when the track does get backed up.

It's a side-effect of how the pathfinder works. Each tile is assigned a cost for passing through, and the path with the least cost is selected. Each reserved track passed has a cost, and a path through a depot another. If the cost of the depot is less, it will be chosen. It's not really intended, it's just the way the pathfinder works.

Solution: when reserving a path, reserve the target signal tile as well [the old PBS patch did that]

Known problem with paths to non-pbs signals, will be fixed.

-- Michael Lutz

[Tekky]

Tbh, regardless of how TTDPatch handles mixed signals and PBS signals, i think OpenTTD should never allow crashes due to "incorrect signalling" as expressed before...

Depending on your defintion of incorrect signalling, OpenTTD does allow crashes right now. Is connecting two tracks that were unconnected before without placing signals on the connection incorrect signalling or user error? And if it's an user error, why is building the wrong signal type not an user error? Most people here expressed the opinion that crashes after modifying a junction with trains on it are generally a user error. If you remove a signal in plain OpenTTD, trains will crash. So why should removing a signal be a valid reason for crashes, but changing the signal type not? I'm not trying to discredit your opinion or anything, I just want to know why you think so. Of course, you could be of the opinion that the current behavior is broken as well.

The first problem is to define what incorrect signalling actually is. I think that if you ask five users, you will probably get five slightly different answers. Secondly, every solution for that problem has some kind of drawbacks. The real problem is not finding a solution, it is deciding which drawbacks are acceptable.

(...)

Please take this post as food for thought. Don't hesitate to post if you have a good idea for a solution.

-- Michael Lutz

I think that signals that a train has reserved a path to should not be changable/removable. It may be so that in traditonal OpenTTD signalling, removing a signal could cause a crash. However, with the new signalling system, it is impossible to tell what train has reserved a path to which location, unless you are using debugging functions (by setting debug_level pbs=2). Therefore, it is necessary to prevent the user from removing or changing of signals that are currently in use, at least in my opinion.

However, if the user does very stupid things, like for example connecting two pieces of track that were previously unconnected, with both tracks having a train on them, then the PBS system should not try to prevent a crash.

Also, I consider it important to change the current system of train reversal. A train should not reverse unless it can reserve a safe path. At least it should not start moving after reversing until it has made a safe path reservation.

[RMJ]

Can anyone link to the signal graphics plz ?

Thanks
/RMJ

[Maedhros]

Umm, if you have openttd{w,d}.grf, you already have them. If you don't, I have no idea how you're using this patch...

[RMJ]

never mind found out hehe thx

[parfittr]

Hi, I've been playtesting this outstanding patch - thanks very much for reviving PBS so well. I have noticed an apparent bug to do with dragging signals along diagonal track - it seems to place non-PBS ones. However, this is only intermittent (about 1 in 4 so far) and I have yet to detect a pattern! Sorry to be quite vague...

On the usage points mentioned earlier in this thread, I think that once you get used to this method of placing signals, it simplifies matters as well as producing the required PBS effects on junctions. The only feature problem I have is the reversing trains point made by Tekky which has caused some amusing crashes for me.

Again, thanks for the hard work.

[Spaz O Mataz]

hello I've been messing around and have came across something that i don't think should be happening. I made a 6 lane lane pbs system which makes building signals and junctions a breeze but it seems the routes they are choosing are not the best route.

quick version:

j---------1a-------S>j---------1b-------S>j
j<S------2a----------j<S-----2b-----------j
j---------3a-------S>j---------3b-------S>j
j<S------4a----------j<S------4b----------j
j---------5a-------S>j---------5b-------S>j
j<S------6a----------j<S------6b----------j

J is junction
S and arrow (< or >) pbs one way signal
this is just one of the parts.
there's 2 trains waiting on 3a and 4b at the signal because a train travelling through the junction from 2b and has chosen to go to 4a even though 2a is empty, Is the train meant to do that. I thought it would travel straight through to 2a.

I have included a pic of this happening and a save game of the line I have made for people to look at

[Tekky]

hello I've been messing around and have came across something that i don't think should be happening. I made a 6 lane lane pbs system which makes building signals and junctions a breeze but it seems the routes they are choosing are not the best route.

Since in your savegame the train you are talking about has already made its decision to take this strange route, I am unable to see the exact situation at the time of the decision, so I cannot say why it made this strange decision. However, after loading your savegame, train #26 decides to make a U-Turn into the wrong direction, despite a track in the correct direction being free. This is very strange! Maybe the train is trying to reach a depot because its servicing date is overdue? I have already noticed that trains are having trouble finding a depot in PBS areas.

EDIT: I just noticed that you had breakdowns disabled and you had activated the patch option to disable servicing when breakdowns are set to none. So this does not seem to be an issue with depot servicing. I also noticed that your savegame barely runs on my Pentium IV 2,8 GHz with 1 GB of RAM. At least the game does not speed up much when I press and hold TAB. Is this due to the map size of 2048*2048 or is the PBS patch causing the low performance?

[dihedral]

i just managed to hit an assert

src/yapf/yapf_node_rail.hpp:206: failed assertion `TrackdirToTrack(cur_td) == TrackdirToTrack(GetLastTrackdir())'
Abort trap

that line is added by your patch, hence i am posting it here

[Michi_cc]

i just managed to hit an assert

src/yapf/yapf_node_rail.hpp:206: failed assertion `TrackdirToTrack(cur_td) == TrackdirToTrack(GetLastTrackdir())'
Abort trap

that line is added by your patch, hence i am posting it here

Got a way to reproduce that? Asserts shouldn't happen, but YAPF is rather complex so I might have missed some corner case where this particular assertion doesn't hold.

I have already noticed that trains are having trouble finding a depot in PBS areas.

It's a side effect of how the system works. Without PBS, trains have the chance to find a depot at every junction tile. With PBS trains will unconditionally follow their reservation and in turn will only look for a depot if they have to reserve a further stretch. As only depots within a certain distance are considered, this makes finding a depot more difficult.

-- Michael Lutz

[dihedral]

the save game will help just let it run

i know it's an odd setup - it just came to me mind and i thought it could be fun to see what it does

Edit: just after 11th/12th August i think

Edit 2: it's the 14th

[Noldo]

Just in case you haven't seen this one yet. The trains just crash. It's basically Tekky's goodgame and enough time. The crash happens just when the year is changing.

[cal]

Hi

First of all: thanks for the great patch!

I think I found a bug (either in my track layout or in your patch ) : Altough it is still loading, the passenger train in the middle of Bülach station has reserved the track up to the junction and blocks the iron train on the right:

Neuhausen am Rheinfall Transport, 17. Apr 1953.png

Superfluous track reservation...

(233.6 KiB) Downloaded 206 times

However, when the freight train is unloading, it does not do so:

Neuhausen am Rheinfall Transport, 23. Mai 1953.png

(244.05 KiB) Downloaded 160 times

Are freight trains treated differently from passenger trains by this PBS implementation? Or what else might be the reason for the difference in behaviour?