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

[Zephyris]

... but its also a problem that could be fixed ...

[phil88]

2): increase chances to get in trunk?

I don't care if YAPP takes 1000% more CPU when you start actually using YAPP, i.e. building YAPP signals. My main problem is that the YAPP patch introduces 10% more CPU when the signals are not used.

It's like paying 10% more for cellular bill when the cellular company starts implementing a new network with more features (4G?), even when you do not intend to use the features. When someone else wants to use those new features and has to pay 50% more I don't care, as long as I don't have to pay 10% extra when I do not use it.

IMHO it would be somewhat short-sighted of the devs to deny a hugely significant feature like PBS just on a small detail like this. I always thought that the devs sought parity between the features in OpenTTD and TTDPatch, and the lack of PBS is a biggie!!

I think they'd be fine with it if it was made so that if the user chooses not to use any YAPP signals, the CPU usage won't go up. If the CPU usage goes up with YAPP, fair enough. But at the moment it goes up even when YAPP isn't being used.

[xxxvinniexxx]

[img]why.png[/img]

Can anyone tell me why train A doesnt use the empty platforms ?

What am I missing here ?

[edit] I'm using tib's patch pack. And there seems to be the problem.[edit]

[T-Unit]

Likely to be a bug with Tib's patch pack then. Its unlikely to be the same version as what has been released here.

[ostlandr]

Noticed this myself, along with an occasional deadlock (eternal "waiting for path") when there is no interfering traffic. Will blame the patchpack, then.

Likely to be a bug with Tib's patch pack then. Its unlikely to be the same version as what has been released here.

[Rainer]

Hi xxxvinniexxx,

Can anyone tell me why train A doesnt use the empty platforms ?

It is not visible in which direction the train faces. Perhaps it turned around while all platforms were occupied and now you need to wait until it turns back. Try turning it around manually.

cu
Rainer

[T-Unit]

@Rainer: It doesnt look like the train is the other way around as it isnt right up by the back of the previous one.

[Rainer]

Hi T-Unit,

@Rainer: It doesnt look like the train is the other way around as it isnt right up by the back of the previous one.

I'm not quite sure what you want to tell me, but, as one can see by the different positions of the Percentages in the station, the trains look the same from both directions.

Now speaking about train A:
With conservative signalling, when a train turns around after waiting too long it will drive to the next signal and then turn around again.
With YAPP a train turns around, finds no way to its target and stops immediately with its tail fixed to its signal.

Since TTD introduced one way signals, I never understood, why a waiting train should turn around from its signal, this behaviour makes only sense in TTO when there were only two way signals.

I read something in this thread about trains that turn around after a given time, but I could not stop them from doing so.
The worst are trains that leave a station, find their way out temporary blocked from a traffic congestion, then turn around, stopping immediately and thus blocking the complete station.

cu
Rainer

[Eddi]

there's a patch setting like "wait_for_pbs_path", set that to 255 to prevent trains from turning around [on the ingame console]

[T-Unit]

@Rainer: I hadnt realised that it stops as soon as it turns around. Having not noticed any jams like this i didnt know that the trains didnt continue onto the previous signal.

[Ammler]

Heya Michi

Just tested YAPP again, everything we found with 8.0 seems to be fixed and only one glitch seems still here:
http://www.tt-forums.net/viewtopic.php?p=702892#p702892

Greets
Ammler

[Michi_cc]

[...] and only one glitch seems still here:
http://www.tt-forums.net/viewtopic.php?p=702892#p702892

That's intended. The backside of such a signal is not a safe waiting position. (how should the train driver know where to stop?)
Special casing this would be a mess code-wise because several code parts rely on this. As nobody likes train crashes, stopping is the feasible solution. And if you don't disable automatic train reversal, it'll turn around on its own.

-- Michael Lutz

[ostlandr]

Have been playing around with the PBS patch, both v8 and the version in Tibb's PatchPack. Great work!

Interestingly, even though it's signal based, it works more like Track Warrant Control: http://en.wikipedia.org/wiki/Track_warrant_control

It really makes my favorite station design (see screenshot) flow like I always wished it could by eliminating the delay when non-conflicting moves went through the in-and-out crossovers. I have even used it for passing sidings on single track lines. I can even use single-track stations at resources, as the trains will wait at a "safe location" for a path to the platform.

Treedburg Bay Transport, 26th Apr 1952.png

This actually works with PBS!

(185.27 KiB) Downloaded 149 times

[Rainer]

Hi,

the issue "turning around on signals" is even more annoying when the other signal is no YAPP-signal but a normal one. The back of a normal or YAPP one way signal is a "mirror" and could be treated as such, that means YAPP can continue searching for a path in the opposite direction, one train length away from the signal.

This would lead to still unrealistic but more cooperative behaviour of a stuck train.

cu
Rainer

[Michi_cc]

The back of a normal or YAPP one way signal is a "mirror" and could be treated as such, that means YAPP can continue searching for a path in the opposite direction, one train length away from the signal.

It can't. YAPP doesn't search anything, that's solely the job of the pathfinder. These don't do any "reflection" or such at signals. And I'm certainly not going to add that, as it only increases code complexity even more and makes the whole thing slower, even without using YAPP signals.

-- Michael Lutz

[Ammler]

[...] and only one glitch seems still here:
http://www.tt-forums.net/viewtopic.php?p=702892#p702892

That's intended. The backside of such a signal is not a safe waiting position. (how should the train driver know where to stop?)
Special casing this would be a mess code-wise because several code parts rely on this. As nobody likes train crashes, stopping is the feasible solution. And if you don't disable automatic train reversal, it'll turn around on its own.

It shouldn't wait at all! (just turn it back)
(or did I get you wrong?)

Greets
Ammler

[Michi_cc]

It shouldn't wait at all! (just turn it back)
(or did I get you wrong?)

It does turn back around, that's what the pf.wait_for_pbs_path timeout is for.
The pathfinder only tells that the chosen path could not be reserved, not why. Maybe it failed simply because a train is passing and the path will be free again in a second. Or maybe the path will only be available much later or maybe never, but this is not known beforehand. Why should the train turn right back if it only did turn around because there wasn't a free path in the other direction either? And if you turned your train around manually, it doesn't make sense either, because turning around is exactly what you told the train to do. (And if you set pf.wait_for_pbs_path to 255, you should know what you're doing, as you clearly can't set that accidentally.)

-- Michael Lutz

[Progman]

But in non-yapp games there is a difference if the train waits on a red signal or try to pass a one-way signal in the wrong way (and turns). So the information if there is no way possible or if it just blocked is known, somehow...

[Ammler]

(And if you set pf.wait_for_pbs_path to 255, you should know what you're doing, as you clearly can't set that accidentally.)

It can also turn around from a non pbs signal, so the train is blocked. (if you have wait_for_pbs forever)

Greets
Ammler

[Brianetta]

My trains crash into each other with YAPP 8.2 patched against r13731.

The problem seems to be related to a single track, single platform, two directional station. A train will occasionally reserve a path onto the platform whilst it is occupied.

The attached saved game uses the grf files defined and available at http://ppcis.org/standard/ ; after loading this saved game, a pair of trains should collide with each other at Druningstone Station on the 5th of January 1934. The path is reserved on the 2nd/3rd of January.

Completely, 100% reproducible on my setup.