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

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

tut
Engineer
Engineer
Posts: 9
Joined: 14 Aug 2008 01:29

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

Post by tut »

peter1138 wrote:I just hope tut is not the FreeBSD port maintainer. :)
Sure I'm not (I posted a link with the port details).
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

I did not read the all thread, so maybe someone already suggested this:

I'm often using prioritizers in openttdcoop style. When mainline is multitrack I would like to have oneway PBS signal at sideline entering the mainline, but I want the prioritizer to work. Thus I need 'unsafe PBS presignal', which acts as nonPBS presignal, but it is not safe place to wait. So when it is red, the train cannot reserve path going through this signal. When it is green, the train will be able to reserve path through this signal (and it should stay green as long as the path through it is reserved even if there are reds on POST-signals).

E.g.:

Code: Select all

=== mainline
--- sideline
+ junction

E exit two way signal, < one way ordinary signal
S one way PBS signal
PP ... the new "PBS one way PREsignal"
    2    1
=<=+==E====<====<====<====<=
    \
    PP
      \ 
       +--S----<----<----<-
      /
    PP
    /
=<=+==E====<====<====<====<=
Train going the mainline will treat the E signals as ordinary signal as it hits no presignal before. When the E signal is red because train is in block 1, or there is a train in block 2, the PP signal will go red (this behaviour of nonPBS presignal). Train going the sideline will wait at S when both PP signals are red (- this is the new behaviour), otherwise it will reserve the track through the PP signal to the ordinary signal in block 2.
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

Alternative approach would be "greedily reserve" PBS signal which will be on the mainline. The train will reserve the path to this signal as usual, but if it is possible, it will also reserve the path from this signal on to next signal. This will be the alternative way to PBS prioritizers. (Path-reserving from this signal should have priority before path-reserving from standard PBS signal.)
Noldo
Engineer
Engineer
Posts: 75
Joined: 16 Jun 2005 13:17
Location: Lappeenranta, Finland

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

Post by Noldo »

I like the greedy reservation. It's even quite simple consept, try to reserve more, but if it fails don't abandon the earlier reservation. This would make them chainable to make different levels of priority. Also it would look great deal better that the advanced block signal based solution currently used.
User avatar
Brianetta
Tycoon
Tycoon
Posts: 2567
Joined: 15 Oct 2003 22:00
Location: Jarrow, UK
Contact:

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

Post by Brianetta »

PBS is the solution to some other problem. This problem requires the old, regular signals (which, in fact, already do the job in the layout you describe). At no point on your diagram is there any signal block where two trains could enter and leave safely at the same time, so a reservation won't help you.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

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

Post by Zuu »

tut wrote: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.
As long as you use the latest nightly you usually find at least one server to play at. Another approach would be to write a script (or modify an existing one) that FreeBSD users can get via ports that auto-updates OpenTTD to last version. The OpenTTD installation would probably be a user-space installation so the logged in users have enough rights to auto-update it, plus the security benefit of not running the script as root.

Revision of last nightly you will find here: http://nightly.openttd.org/devs/rev
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

Brianetta wrote:PBS is the solution to some other problem. This problem requires the old, regular signals (which, in fact, already do the job in the layout you describe). At no point on your diagram is there any signal block where two trains could enter and leave safely at the same time, so a reservation won't help you.
Thats not true. Now. There is the race condition as the train in old nonPBS setting on mainline first passes the green on presignal, THEN it chooses track on the first junction (marked by '+') and THEN it approaches combo signal (now marked by PP), which may turn red when the train PASSED the junction but still NOT PASSED the signal. This can block the sideline as there may be more trains on one track of the mainline than on the other. This is race condition, which can be solved by nonPBS signaling, but it is huge construction depending on fact that all trains approaching by side line have same length, and all trains aproaching by mainline have same speed. With PBS once the train passes the 'S' signal, it has reserved track to the mainline, so it will not be stopped by the prioritizer.

Another benefit is that I can mix output of two sidelines that approach mainline at same place in natural way. (Just doubling the sideline in the diagram to first junction).

P.S.: I'm talking about heavily loaded mainlines. Now in my home game I have mainline with 4 tracks each direction, and there are places where train on sideline waits for a while because gaps between trains on mainline are rare. Here I benefit from not balancing the mainline, as there are longer gaps on the least loaded track.
User avatar
Brianetta
Tycoon
Tycoon
Posts: 2567
Joined: 15 Oct 2003 22:00
Location: Jarrow, UK
Contact:

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

Post by Brianetta »

What the heck do you want the train on the sideline to do? Enter traffic on the mainline, or wait forever? Seems to me, all you really need to do if you really want to use PBS is remove the signals marked "PP" entirely. If the train at S reserves a path onto either mainline, it'll go and not stop until it gets on there. If it can't, it will wait at S.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

Brianetta wrote:What the heck do you want the train on the sideline to do? Enter traffic on the mainline, or wait forever? Seems to me, all you really need to do if you really want to use PBS is remove the signals marked "PP" entirely. If the train at S reserves a path onto either mainline, it'll go and not stop until it gets on there. If it can't, it will wait at S.
No I want the trains on mainline to never stop. Even if the train from sideline is accelerating from zero and trains on mainline are at full speed. Thus I need long prioritizers, and having long prioritizers I need the sideline trains to try to enter mainline if either of the prioritizers is "green" (no train in the prioritized part of mainline track). If both are red, then the sideline train must wait in position to be able to enter both of the mainline tracks (at the "S" signal in my previous schema). And as soon as the sideline train passes the signal saying "at least one of the mainline tracks is free" ("S") I need the sideline train to enter that mainline track even if a train on mainline enters prioritized area one clock-tick after the sideline train passes this "S" signal.

If I remove the PP signals, then there should be PBS signals at 'E' sign, otherwise the mainline trains will block each other. But I want my prioritizer there, (yes the E signal may be oposite direction on can't be accesible track:

Code: Select all

        +->E-+ 2
===<==+==<PBS===<==
       \
        \
          +--<S----<---
        /
       /
===<==+==<PBS===<==
        +->E-+
But anyway this solution needs, that train at "S" would not choose upper track if the upper E is red (train in block 2). But this logic is too advanced for pathfinder (the "S" will be too clever to be implementable). So I proposed the PP signal, which makes this logic easy. But anyway I think the second solution to this looks more elegant (at least on the map):

Code: Select all

< normal PBS
<< greedy PBS
 1    2     3     4     5
===<==+==<<====<<====<====
       \
        \
          +--<----<----<---
        /
       /
===<==+==<<====<<====<====
        +->E-+
Train entering block 4 will reserve its track to greedy signal between 3 and 4. If it is possible it also reserves block 3 and if it does so it also tries to reserve path in block 2. Thus train comming from sideline cannot reserve path through block 2 as there is a train in block 4 or 3 or 2 on mainline. (Note that block 5 is ordinary and does not do this "far" reservation.). The only "advanced" thing that must be provided here is if train is leaving block 2 and another is in block 4 and there is a train waiting on sideline, then at the time when block 2 is freed then the train in block 4 (he has the engine in the middle of block, he is not waiting at signal) will reserve the track in block 2, while the train on sideline is still waiting. (For longer gap between trains on mainline. Note that this gap can occur on the other mainline track.)
Youri219
Traffic Manager
Traffic Manager
Posts: 191
Joined: 28 Apr 2007 11:53

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

Post by Youri219 »

ebik wrote:I did not read the all thread, so maybe someone already suggested this:

I'm often using prioritizers in openttdcoop style. When mainline is multitrack I would like to have oneway PBS signal at sideline entering the mainline, but I want the prioritizer to work. Thus I need 'unsafe PBS presignal', which acts as nonPBS presignal, but it is not safe place to wait. So when it is red, the train cannot reserve path going through this signal. When it is green, the train will be able to reserve path through this signal (and it should stay green as long as the path through it is reserved even if there are reds on POST-signals).

E.g.:

Code: Select all

=== mainline
--- sideline
+ junction

E exit two way signal, < one way ordinary signal
S one way PBS signal
PP ... the new "PBS one way PREsignal"
    2    1
=<=+==E====<====<====<====<=
    \
    PP
      \ 
       +--S----<----<----<-
      /
    PP
    /
=<=+==E====<====<====<====<=
Train going the mainline will treat the E signals as ordinary signal as it hits no presignal before. When the E signal is red because train is in block 1, or there is a train in block 2, the PP signal will go red (this behaviour of nonPBS presignal). Train going the sideline will wait at S when both PP signals are red (- this is the new behaviour), otherwise it will reserve the track through the PP signal to the ordinary signal in block 2.
You can eliminate the race condition already with normal presignals.

Code: Select all

---- signal 'cable' and sideline (the sideline enters from the centre). 
=== mainline
--- sideline
+ junction
< one way ordinary signal
E exit two way signal
S entrance
C combo two way
c combo one way

         /--c--/--c--/--c--/
<==+==C==+==<==+==<==+==<==+==E==+==E==
    \    \--c--\--c--\--c--\--c--+
    c      \
      \     c
       +--S-+-S-<----<----<-
      /     c
    c      /
    /    /--c--/--c--/--c--/--c--+
<==+==C==+==<==+==<==+==<==+==E==+==E==
          \--c--\--c--\--c--\
A trains comes from the right, over the 'side'line going left. The first entrance signal looks a bit further along the main line than the second entrance signal. After passing the first signal, you should build the track such that the train can only go to the second entrance signal. Since potential trains coming on the mainline have been seen by the first entry signal, you will not get a race condition after passing the second entry signal.
Noldo
Engineer
Engineer
Posts: 75
Joined: 16 Jun 2005 13:17
Location: Lappeenranta, Finland

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

Post by Noldo »

Youri219 wrote: You can eliminate the race condition already with normal presignals.
Sure you can, do you think anybody would even mind there is no yapp way to do priorities if presignal priorities wouldn't work.

Personally I think the presignal priorities are an ugly hack because it depends on presignals counting exit-signals that no train can reach. I feel this is more of an implementation specific accident than a feature that comes from the specification of presignals. Nevermind that there is no specification and only one kind of implementation.

Also they feature signals and tracks that no train is ever going to pass and take more space than the rather clean yapp based solution would.
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

Youri219 wrote: You can eliminate the race condition already with normal presignals.

Code: Select all

---- signal 'cable' and sideline (the sideline enters from the centre). 
=== mainline
--- sideline
+ junction
< one way ordinary signal
E exit two way signal
S entrance
C combo two way
c combo one way

         /--c--/--c--/--c--/
<==+==C==+==<==+==<==+==<==+==E==+==E==
    \    \--c--\--c--\--c--\--c--+
    c      \
      \     c
       +--S-+-S-<----<----<-
      /     c
    c      /
    /    /--c--/--c--/--c--/--c--+
<==+==C==+==<==+==<==+==<==+==E==+==E==
          \--c--\--c--\--c--\
A trains comes from the right, over the 'side'line going left. The first entrance signal looks a bit further along the main line than the second entrance signal. After passing the first signal, you should build the track such that the train can only go to the second entrance signal. Since potential trains coming on the mainline have been seen by the first entry signal, you will not get a race condition after passing the second entry signal.
Sure it can be solved with presignals. I have a solution depending on same length of trains that are aproaching by sideline.
I don't see how your solution works, the only method to prevent race is following:
imagine mainline train just entered the prioritized area (from the right). When sideline train is at first (right) 'S', this signal should be red (if other track is also busy) but if the sideline train is before the 'c' which is leftmost on your diagram, this signal should be green. I don't see how you achieve this in your diagram. But this is offtopic here.

I want to use PBS as they allow more complex junctions, have some nice features, but I want also the prioritizer behaviour. So I'm proposing some advanced signals. One of them is special presignal, which is unsafe waiting position, and the other is special PBS signal (which then allows to throw away all presignals and do all things with PBS).

In fact I think that very nice solution would be some signal editing tool which allows edit signals for each direction separately, allowing the signal to be safe/not-safe waiting position, normal signal, pbs signal or one of the three presignals or 'entry forbidden, turn away' sign. Thus all combinations would be available.
User avatar
Brianetta
Tycoon
Tycoon
Posts: 2567
Joined: 15 Oct 2003 22:00
Location: Jarrow, UK
Contact:

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

Post by Brianetta »

ebik wrote:I want to use PBS as they allow more complex junctions
You're getting it wrong. PBS allows less complex junctions. You're using the wrong tool.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

Brianetta wrote:
ebik wrote:I want to use PBS as they allow more complex junctions
You're getting it wrong. PBS allows less complex junctions. You're using the wrong tool.
:D :D

Yes, you are right that same junctions are less complicated. But also they allow more combinations of different tracks joining and that is what I had in mind.
User avatar
konakona
Engineer
Engineer
Posts: 3
Joined: 24 Aug 2008 13:57

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

Post by konakona »

It definitely goes both ways lol, I've just finished work on this junction. Because I can make it more compact, I've used the extra space =P.

http://www.tt-forums.net/viewtopic.php? ... 61#p721561

And I've used normal signals, pre-signals and pbs signals, the only problems it has are when trains wait and reverse into a block with pbs entrances, then they just stop and turn back round later but in the mean time, cause a jam. That feature should really be revised, the only time they'll ever need to turn round is if two trains meet at a two way signal, then one should turn round, otherwise I can't think why they would need to.
Cut myself a slice of sunshine pie.
Hirundo
Transport Coordinator
Transport Coordinator
Posts: 298
Joined: 27 Jan 2008 13:02

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

Post by Hirundo »

ebik wrote:Alternative approach would be "greedily reserve" PBS signal which will be on the mainline. The train will reserve the path to this signal as usual, but if it is possible, it will also reserve the path from this signal on to next signal. This will be the alternative way to PBS prioritizers. (Path-reserving from this signal should have priority before path-reserving from standard PBS signal.)
I really like this idea. It's simple, elegant, and makes those ugly presignal trees obsolete.

Vote count + 1
Create your own NewGRF? Check out this tutorial!
User avatar
Rainer
Traffic Manager
Traffic Manager
Posts: 240
Joined: 14 Nov 2007 10:01
Location: Wiesbaden, Germany

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

Post by Rainer »

Hi konakona,
konakona wrote: the only time they'll ever need to turn round is if two trains meet at a two way signal, then one should turn round, otherwise I can't think why they would need to.
You are absolutely right. And you don't need two way signals any longer with YAPP. Since TTD introduced one way signals the only place was in front of a terminal station and this necessity has gone now, too.

So there is NO need to turn around a train other than on the end of track.

cu
Rainer
ebik
Engineer
Engineer
Posts: 83
Joined: 19 Jul 2005 08:14
Location: Prague, Czech Republic

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

Post by ebik »

Yet another proposal to solve the train reversing. The "bad" situation is when train reverses at normal signal and it can't go back, as there is another train standing behind the PBS, even if the pbs CANNOT be passed in oposite direction! (which I consider a bug)

The simple solution to both passable and unpassable PBS signal is that train CAN reverse in PBS block as long as it is NOT waiting at the signal. (Moreover this may have smaller timeout than ordinary turn back at one-way single signal.)

P.S.: I also vote for option of not turning back at normal one way signals. Even with no PBS, this turning back leads to many false "train is lost" messages in my game.
Tekky
Route Supervisor
Route Supervisor
Posts: 420
Joined: 19 Dec 2006 04:24

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

Post by Tekky »

I have always been very critical of automatic train reversal, even before YAPP. Automatic train reversal was only necessary as a workaround for the problem that old OpenTTD signals often caused deadlocks, because in the old OpenTTD signalling system, it was not possible to prevent trains waiting inside junctions, thereby blocking the entire junction. Therefore, automatic train reversal was necessary in order to break these deadlocks. However, if you use YAPP (PBS) signals, there is no reason anymore for having automatic train reversal, as it causes a lot more problems than it helps.
Michi_cc
OpenTTD Developer
OpenTTD Developer
Posts: 619
Joined: 14 Jun 2004 23:27
Location: Berlin, Germany
Contact:

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

Post by Michi_cc »

Tekky wrote:I have always been very critical of automatic train reversal, even before YAPP.
Write a patch that allows it to be disabled then, it shouldn't be that hard.
But as train reversal at conventional signals is old behavior since about forever and nothing YAPP has introduced, you don't need to convince me but any of the devs with commit access that the exisiting behavior should actually be changed.

-- Michael Lutz
-- Michael Lutz
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Bing [Bot] and 3 guests