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

[Tekky]

I like Brianetta's suggestion of "routing signals". However, this could maybe be confused with TTDPatch's programmable signals which offer conditional routing.... Therefore, I do still prefer the term "PBS signals" slightly.

It was said that OpenTTD's YAPP signals were different to TTDPatch's PBS signals. I disagree with this. They are nearly the same, especially since the introduction of TTDPatch through signals.

[AndersI]

SWP of course
For Safe Waiting Point.

[jaybud4]

Okay, I'm not looking thru 47 pages.
Anybody got any information on how to use these beasts successfully?
I've only managed to get gridlock after gridlock on my lines... :\
EDIT: Here's my best attempt so far.
It's kinda based off of an interstate/freeway.
The middle two lines are the fast lanes that go through the entire line. The outer two break off at each exit as shown.
Seems to work out okay so far.
Linked because the image is rather large.
http://img.photobucket.com/albums/v139/ ... 1975-1.png
Yes, I realize that station is only accessible/leaves from the one direction.
That was intended.

[Spingo]

You don't need to look through 47 pages - just look in the wiki - http://wiki.openttd.org/index.php/YAPP

The main problem that I see in your screenshot is the lack of a signal immediately before/after each platform on the station, and the placement of a signal at the exit of the merge. You need to place PBS signals at safe waiting locations.

[Brianetta]

Spingo is right. Every time you place a PBS signal, ask yourself, "Do I really want a train to wait here?" If you don't, don't place the signal. Remember, trains can go both ways through the signals, but won't ever wait at the back side of one.

[Tekky]

The main problem that I see in your screenshot is the lack of a signal immediately before/after each platform on the station, and the placement of a signal at the exit of the merge.

Signals in front of station platforms are no longer necessary. However, the signal at the exit of the merge should clearly be removed, as it is not a safe waiting location.

[Tekky]

I have started a new thread about renaming YAPP "advanced signals". Please post all further discussion about this topic in my new thread and not in this thread.

EDIT: I have just started a poll in the thread mentioned above about whether and how "advanced signals" should be renamed. Current poll results are 9 to 1 in favor of renaming the signals. Most votes have been cast for renaming them to "PBS signals" or "path signals", however the poll has only just started. You are welcome to also take part in the poll.

[tut]

Could someone make YAPP v9 patch for 0.6.2 openttd release if possible?

[Tekky]

YAPP 9 was made taking the current code structure of the latest nightly build into account. I guess it would be many hours of work to port it to 0.6.2. Why don't you just download the latest nightly build, in which YAPP is included?

[jaybud4]

Just download the latest nightly.
It's not like it's a noticeable stability difference.
In fact, the nightly is probably even MORE stable..

[tut]

I guess it would be many hours of work to port it to 0.6.2.

As I can see there was similar patch for openttd v0.6.0 and yapp v5.

[Tekky]

I certainly don't recommend using YAPP 5, as it is very buggy compared to the version of YAPP in the latest nightly.

If you want to stay with OpenTTD 0.6.2 for stability concerns, I can assure you that the latest nightly build is much more stable than any attempt to port YAPP to OpenTTD 0.6.2.

[tut]

If you want to stay with OpenTTD 0.6.2 for stability concerns, I can assure you that the latest nightly build is much more stable than any attempt to port YAPP to OpenTTD 0.6.2.

Actually I'd like to add the yapp patch as an option to FreeBSD port of openttd. Only official releases are used there usually.

[jaybud4]

If you want to stay with OpenTTD 0.6.2 for stability concerns, I can assure you that the latest nightly build is much more stable than any attempt to port YAPP to OpenTTD 0.6.2.

Actually I'd like to add the yapp patch as an option to FreeBSD port of openttd. Only official releases are used there usually.

The nightlies ARE official releases, for all intents and purposes.
They're releases by definition... And definitely official...
^Hahaa. Stupid pun.

[Rubidium]

Actually I'd like to add the yapp patch as an option to FreeBSD port of openttd. Only official releases are used there usually.

I hope you are aware of the fact that IF you backport the YAPP patch that it's pointless to call the OpenTTD in FreeBSD 0.6.2 because it is so network incompatible that I can guarantee network trouble and savegames that can't be loaded.

[tut]

Actually I'd like to add the yapp patch as an option to FreeBSD port of openttd. Only official releases are used there usually.

I hope you are aware of the fact that IF you backport the YAPP patch that it's pointless to call the OpenTTD in FreeBSD 0.6.2 because it is so network incompatible that I can guarantee network trouble and savegames that can't be loaded.

As I said the yapp patch will be a build option turned off by default.

[planetmaker]

Actually I'd like to add the yapp patch as an option to FreeBSD port of openttd. Only official releases are used there usually.

I hope you are aware of the fact that IF you backport the YAPP patch that it's pointless to call the OpenTTD in FreeBSD 0.6.2 because it is so network incompatible that I can guarantee network trouble and savegames that can't be loaded.

As I said the yapp patch will be a build option turned off by default.

Even then. It has (new) patch options, thus making it incompatible with any binary which does not have this patch. Better go for the clean solution, grab one of the latest nightlies and use that.

[tut]

As I said the yapp patch will be a build option turned off by default.

Even then. It has (new) patch options, thus making it incompatible with any binary which does not have this patch. Better go for the clean solution, grab one of the latest nightlies and use that.

It is much more worse for one who plays multiplayer game to build yapp with some nightly build. But if there will be openttd v.0.6.2 FreeBSD port with optional yapp, it is easy to find people with the same version to play multiplayer.

[planetmaker]

It is much more worse for one who plays multiplayer game to build yapp with some nightly build. But if there will be openttd v.0.6.2 FreeBSD port with optional yapp, it is easy to find people with the same version to play multiplayer.

YAPP is integrated in the nightly. Thus you just need a clean nightly and you're fine, no patching required. And a patched 0.6.2 is a different version than 0.6.2 no matter how you twist or call it.

Also, integrating YAPP into the source of 0.6.2 requires backporting yapp to that version, and either
- making available the binaries (for different platforms)
- making available the source and patch or both already integrated
- or (much worse and no fun) hacking the network code such that unmodified clients can join on the cost that they will desync within very short time as they run on a different source than the server. YAPP is not a client or server-only patch. Both server and client need it.

The FAR easier way is to supply the binaries for that nightly release you run - actually binaries are available from the OpenTTD website for download for the last few nightlies.

If you still believe it's a good idea to patch YAPP into 0.6.2 and call it (wrongly a clean) 0.6.2: go ahead - I'm sure your players are in for a lot of trouble - or you supply patched binaries in which case you could supply nightly binaries for far less work.

If, on the other hand, you play a game with YAPP switched off - fine, but why then patch in the first place?

[peter1138]

I just hope tut is not the FreeBSD port maintainer.