Sure I'm not (I posted a link with the port details).peter1138 wrote:I just hope tut is not the FreeBSD port maintainer.
YAPP - Yet Another PBS Patch (now in trunk!)
Moderator: OpenTTD Developers
Re: YAPP - Yet Another PBS Patch (now in trunk!)
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.:
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.
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====<====<====<====<=
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.)
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.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.
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)
Junctioneer (a traffic intersection simulator)
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.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.
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.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.
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-+
Code: Select all
< normal PBS
<< greedy PBS
1 2 3 4 5
===<==+==<<====<<====<====
\
\
+--<----<----<---
/
/
===<==+==<<====<<====<====
+->E-+
Re: YAPP - Yet Another PBS Patch (now in trunk!)
You can eliminate the race condition already with normal presignals.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.: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.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====<====<====<====<=
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--\
Re: YAPP - Yet Another PBS Patch (now in trunk!)
Sure you can, do you think anybody would even mind there is no yapp way to do priorities if presignal priorities wouldn't work.Youri219 wrote: You can eliminate the race condition already with normal presignals.
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
Sure it can be solved with presignals. I have a solution depending on same length of trains that are aproaching by sideline.Youri219 wrote: You can eliminate the race condition already with normal presignals.
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.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--\
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
You're getting it wrong. PBS allows less complex junctions. You're using the wrong tool.ebik wrote:I want to use PBS as they allow more complex junctions
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
Re: YAPP - Yet Another PBS Patch (now in trunk!)
Brianetta wrote:You're getting it wrong. PBS allows less complex junctions. You're using the wrong tool.ebik wrote:I want to use PBS as they allow more complex junctions


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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
I really like this idea. It's simple, elegant, and makes those ugly presignal trees obsolete.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.)
Vote count + 1
Create your own NewGRF? Check out this tutorial!
Re: YAPP - Yet Another PBS Patch (now in trunk!)
Hi konakona,
So there is NO need to turn around a train other than on the end of track.
cu
Rainer
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.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.
So there is NO need to turn around a train other than on the end of track.
cu
Rainer
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
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.
Re: YAPP - Yet Another PBS Patch (now in trunk!)
Write a patch that allows it to be disabled then, it shouldn't be that hard.Tekky wrote:I have always been very critical of automatic train reversal, even before YAPP.
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
Who is online
Users browsing this forum: Bing [Bot] and 3 guests