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

[Timitry]

then get winrar... should be about 2mb size... or another program which can open rars, you will always have the need to open rar files as they are quite common...

[T-Unit]

Done. Testing can begin. I didnt start well by letting a couple of trains run into each other...

[Timitry]

Yeah, if editing any section with PBS, you should better first kill all tracks leading to that junction, edit like you want, then reconnect everything... Else there will always be crashes...

[Tekky]

Done. Testing can begin. I didnt start well by letting a couple of trains run into each other...

Hehe, that happened to me, too The most important rule is to put signals in front of all station platforms to prevent trains leaving a station platform without clearance, as that is the most frequent cause of a crash. Also, you should not change a signal that a train has reserved a path to, otherwise it will just continue driving on although it has no clearance to do so. 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.

[planetmaker]

Hi,

great patch as I've been playing around with today. Much to learn (new) wrt to signaling, but fine

Two bugs I found though, one minor, one major:
minor: with debug_level pbs=2 the reserved path is not shown on slopes (yapp_NoPathOnSlope.png).
major, leading to possible train crashes (see yapp_NoPathReservedWrongDirection.png): newly build trains, which have to reverse at a station don't reserve a path in the PBS signaled entrance. You can see this happen in the attached save in a few seconds. See sign !power station.

Good work though

EDIT: Just found on flyspray this bug report: http://bugs.openttd.org/task/1473
Maybe this is related...
EDIT2: fixed type; thanks to audigex.
EDIT3: the slope image actually isn't supposed to show a highlighted track tile. The bug nevertheless works for slope tiles w/o signals which should be highlightes. Thx Tim for pointing out.
(Obviously it's already too late for me... )

[Tekky]

Two bugs I found though, one minor, one major:
minor: with patch_level pbs=2 the reserved path is not shown on slopes (yapp_NoPathOnSlope.png).
major, leading to possible train crashes (see yapp_NoPathReservedWrongDirection.png): newly build trains, which have to reverse at a station don't reserve a path in the PBS signaled entrance. You can see this happen in the attached save in a few seconds. See sign !power station.

I guess it cannot mark track as reserved on slopes because there is no appropriate "dirty" track sprite defined yet for slopes. Therefore, I would rather call it an "unimplemented feature" and not a "bug".

I had a look at your savegame and I found that the train which causes the crash doesn't reserve its path properly because it cannot find a path to its destination, i.e. it is lost. The issue of lost trains making improper path reservations has already been reported and the patch author has already announced that he would fix this bug in the next release. Thanks for your bug report, anyway.

[Michi_cc]

Two bugs I found though, one minor, one major:
minor: with debug_level pbs=2 the reserved path is not shown on slopes (yapp_NoPathOnSlope.png).

This is because OpenTTD doesn't have the proper sprites to overlay in this case. Would need new sprites to work.

major, leading to possible train crashes (see yapp_NoPathReservedWrongDirection.png): newly build trains, which have to reverse at a station don't reserve a path in the PBS signaled entrance. You can see this happen in the attached save in a few seconds. See sign !power station.

The main problem causing the crash will be fixed in the next version. Regarding the bug report on Flyspray, I'll have to check if that is relevant.

Are any TTDPatch players here? I did take a look at mixing normal and PBS signals in Patch and was able to crash trains this way rather easily. (Having both PBS and plain signals as signals into a block.) I did use an older version as the current version wasn't working for me for some reason. So I would be grateful if somebody could clarify what the current Patch does in such a situation.

-- Michael Lutz

[Zephyris]

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

[Michi_cc]

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.

I can think of a few solutions that are intuitive and easy for the user, but they all either use map space, which is a scarce resource, or have the possibility to be computationally very expensive.

Another solution would be to automatically upgrade all signals in a block, but two-sided signals pose a problem then. If you convert them as well, conversion would have to cascade into the next block as well which could finally result in converting almost the whole network. And if you don't convert them, nothing is solved.

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

-- Michael Lutz

[Timitry]

Wow, we are just testing the pbs at the openttdcoop development server... although it's tricky, it's functionality is amazing... Just look at the picture below

in some coopetitive work, we found out that you should not use any entrance signals at all - just don't put any signals in front of the station
so just like the picture above just without the entry signals... works really amazing!

[e] even did a two-way roro... works amazing and is really simple - pictures tomorrow!

[Mchl]

Today I managed not to crash any trains... I guess I'm getting used to the new system

Screenshot shows 4 platform ro-ro station, with three entering lines and three leaving lines... The design itself is really simple and works really well.

No congestions so far. I am trying to put as much load on it as possible. There are several unconnected coal mines still available

[RMJ]

its alittle bit sad you have to be a damn guru to try out these nice patches, anyone that would be so kind to compile this

//Thanks

[Mchl]

Timitry has posted Win32 binary on page 5 of this topic.

[WWTBAM]

About how ttdpatch handles mixed signal types, ie non PBS and PBS it converts the non PBS signals to PBS once the last train has left the signal block. If the signal was presignal it keeps it as a prePBS.

[spaceman-spiff]

Here comes a compiled version, compiled and working under win xp... Install over a nightly around the patch version, e.g. 12069...
Hope that works...

We had one complaint about your file, it appears to have some ttd original files in it, is this allowed ? Can someone make this clearer ?

[DaleStan]

Distribution of TTD's original files is prohibited in the OpenTTD forums.

[Forked]

http://www.skagset.no/openttd/r12072_yapp_v3_win32.rar

took the svn-friendly filed and compiled with buildottd. It failed against latest rev (I'm a bit stressed before work, so didn't see against what file) but compiled fine against latest nightly rev.

This file does not contain the grfs from TTD.

Remember to never trust any executable file from people you don't know (and those you do know..), but I promise I didn't mess around with anything

edit: I didn't upload the source code to the same location .. I hope I'm not in some huge violation of licensing.

[Scay]

Thanks for the build! Don't need original newgrf-files since I got them myself, just have the problem of actually compiling it. I'm trusting NOD32 to keep everything really bad out of the way for me

[paradigm]

First, great patch, I really was waiting for someone to implement this after reading about it on the wiki. I played around a bit and it works pretty well so far. It feels very natural to use and looks and behaves just way more realistic. Thanks a lot!

Now, during testing I encountered some "weird" behaviour: I had a train going from one stating to another and there were two possible routes to it, one short and pretty straight and another significantly longer. The train, no matter how, always chose the longer route.

See the attached screenshot for an example (it isn't as clear a it could be, but I was just experimenting a lot ). The train always choses the red route, while the green route would be far better.

I couldn't explain why this was happening until I read about the fact, that trains will avoid driving through a signal from behind. This is probably desireable in some (or many?) cases, but on the other hand it should not force a train to use a significantly longer route. I think this could be easily "fixed" either by reducing the penalty for driving through a signal from the other direction or by introducing (yet) another signal which doesn't has a penalty at all (or really low penalty).

[planetmaker]

First, great patch, I really was waiting for someone to implement this after reading about it on the wiki. I played around a bit and it works pretty well so far. It feels very natural to use and looks and behaves just way more realistic. Thanks a lot!

Now, during testing I encountered some "weird" behaviour: I had a train going from one stating to another and there were two possible routes to it, one short and pretty straight and another significantly longer. The train, no matter how, always chose the longer route.

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.

Your long route uses a one-way signal as entrance, the short way doesn't and is omni-directional.

I wouldn't call this a bug, but a feature

EDIT: clearified a bit.