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

[Tekky]

But as train reversal at conventional signals is old behavior since about forever and nothing YAPP has introduced (...)

That is not quite correct. When using non-YAPP signals, when a train does automatic reversal, it notices nearly immediately if this was not appropriate and reverses back again. However, in a block with mixed YAPP and non-YAPP signals, when reversing while waiting in front of a non-YAPP signal, the train will wait for 30 days (default value for pf.wait_for_pbs_path) before noticing that reversing was inappropriate and reversing back again.

The above situation was the primary cause for traffic jams in my games. Therefore, I started to only use only YAPP signals and never mix in any non-YAPP signals anymore, because this allows me to disable automatic train reversal for YAPP signals, which is not for non-YAPP signals in mixed signal blocks.

[flake]

PBS is a revelation, watching several trains exiting stations in small areas gives me orgasms every time.
thank you to all involved *cheer*

i ran across a problem when building tracks and signals after a PBS and a train is right in front of the (one way)PBS. It turns around and stops somhow waiting for a path to clear... forever (and facing in the wrong direction).
i am sure it is reproducible and as soon as i have gathered more information i'll give a proper bug report.

[Tekky]

In order to deactivate automatic train reversal in front of PBS signals, you must set "pf.wait_for_pbs_path" to 255. See this wiki article for more information:

http://wiki.openttd.org/index.php/Yet_A ... ch_options

However, you will still experience exactly the same problem when waiting in front of a non-PBS signal in a block which contains PBS signals. For this reason, I exclusively use PBS signals on my train networks.

By the way, after reversing, it should not wait "forever" to reverse again. It should wait for "pf.wait_for_pbs_path" days (default value: 30 days) before reversing back again. If it indeed waits forever, you have encountered a bug. I have once reported exactly this kind of bug in terminal stations, but as far as I know, this bug has been fixed.

[flake]

right ! i'v seen that setting but did not think about it, thanks for the hint. I had in mind that there where also an setting how long trains wait before any signal...

And regarding the "maybe bug", i forgot to mention that the train continues to wait although the path would be clear (and i finished building it).

[nulio]

Hi!

I finally started using this, it's really awesome!

But I've noticed something. Don't know if it's been already talked about.

Frequently, trains that have multiple paths choice, choose paths that cuts off other trains.

It would be really great if a train that has multiples paths to choose, would compare them to the paths other trains that are waiting near them or coming. (These happen in situations where I can't discern if both trains are waiting for free path or just one of them is waiting and the other just stopped. Perhaps when multiple trains are waiting for free paths and more than one path is cleared at the exactly same time, they already compare and try not to cut off each other.)

One question. Would be very difficult to code and/or would be very hard for the cpu's to have each train comparing the next (or next two) choice of paths with the other trains to avoid the situations where they cut off each other?

Regards

[Tekky]

Currently, YAPP only supports one type of reservation, which I call a strong reservation. In this wiki article, which I wrote 18 months ago (before YAPP was released), I proposed two new reservation types, a "weak" reservation and a "lookahead" reservation. What you propose is what I would call a "lookahead" reservation.

[nulio]

If I understood your logic I think it's not quite the same thing (but it's late in the night, I could have misunderstood part of your article - quite good indeed ). I would call it a "lookahead" comparison.

Code: Select all

A1----
B1---x------- T1
B2---x------- T2
A2----

We have two trains, T1 and T2, heading to destination A and B, respectively. A1, A2, B1 and B2 are all clear.

In this example, I notice that often T1 chooses A2, cutting off T2.


- The comparison part

If both trains compare their path options (T1 -> A1/A2, T2 -> B1/B2) would detect which ones are incompatible (in this case T1->A2 is) and choose the compatible ones (T1->A1 and T2->B1/B2).

I don't know if this is already coded (perhaps when multiple trains are waiting for free paths and more than one path is cleared at the exactly same time, they already compare and try not to cut off each other.), I notice the need for this in situations that one train reaches the junction first reserving its path and only then the second train reaches the junction. So it comes the second part...

- The "lookahead" part (borrowing the term Tekky uses)

Trains would have to compare also their next path choices.

Code: Select all

A1----
B1---x---------------- T1
B2---x---------------- T2
A2----

|------|------|------|
   P2     P1      P0

| - represent PBS signals

When both trains were at paths P1 they would already comparing P2 paths. Perfect would be that when at paths P0 they were already comparing P2 paths (imagine that T1 is in the P1 area and T2 in P0, if they don't compare P2 paths T1 would choose A2 again and probably cutting off T2 when it reaches the end of P1).

[Tekky]

Unfortunately, as far as I know, trains currently do not detect if they are cutting another train off, even if there are multiple trains waiting. Such a detection would require track to have a "lookahead" reservation, so that a train that intends to reserve a track will notice if another train intends to use that track soon, so it can take the other train's "lookahead" reservation into account when deciding which track to take.

I'm afraid implementing "weak" and "lookahead" reservations will require a complete rewrite of the way reservations are stored, because a track segment would have to be able to contain several reservations from different trains, for example one "strong" reservation, two "weak" reservations and seven "lookahead" reservations.

Here is a short summary of the different types of reservations that I think must be implemented:


exclusive reservations:
A train making this type of reservation tells other trains:

"I currently need exclusive access to this track segment so no other trains may use it. Since I may be forced to wait in front of a red signal in this reserved segment, 'weak' reservations from other trains into this segment are currently not permitted."

This reservation type permits only additional "lookahead" reservations on this track segment. No other reservation types are permitted and only one such reservation may exist on a single track segment. An exception to this rule is that there may be two exclusive reservations on the same track segment if you explicitly force a train over a red signal (thereby risking a crash).


strong reservations:
A train making this type of reservation tells other trains:
"I am currently using this track segment, so no other trains may use it at the moment. However, I guarantee that I will be leaving this track segment soon and won't get stuck in it, so other trains may make 'weak' reservations on this segment."

This reservation type permits other trains to make a "waiting", "weak" and "lookahead" reservations on this track segment. No further "exclusive" or "strong" reservations are permitted, unless you explicitly force a train over a red signal (thereby risking a crash).


waiting reservations:
A train making this type of reservation tells other trains:
"Although I am currently not using this track, I plan to use this track segment as my next safe waiting location. Therefore, other trains may reserve this track, as long as they guarantee that they won't get stuck inside this segment, because that could cause me getting stuck in a non-safe waiting location, i.e. in front of a signal declared as an unsafe waiting location."

This reservation type permits other trains to make "strong" and "weak" reservations, but not "exclusive" reservations or further "waiting" reservations, because these reservations do not guarantee that the other train will be able to clear the segment without getting stuck.


weak reservations:
A train making this type of reservation tells other trains:
"Although I am currently not using this track, I plan to use this track segment as a route to my next safe waiting location. I do not intend to actually wait inside this track segment. Therefore, other trains may reserve this track, as long as they guarantee that they won't get stuck inside this segment, because that could cause me getting stuck in a non-safe waiting location, i.e. in front of a signal declared as an unsafe waiting location."

The difference between a "weak" reservation and a "waiting" reservation is that only one "waiting" reservation is allowed per track segment, because there is only room for one train in front of every safe waiting location (i.e. standard signal, station platform). Also, a train with a "waiting" reservation must first let all other trains with a "weak" reservation past this segment, otherwise it will be blocking all trains with a "weak" reservation if it gets stuck.


lookahead reservations:
A train making this type of reservation tells other trains:
"I plan to use this track segment soon. If other trains want to use it too and there is a conflict, a train prioritization system must decide which train should be given right of way."

There is no limit in the number of "lookahead" reservations a track segment may have and they can be combined with any other reservation type. These "lookahead" reservations are simply used to detect train conflicts in advance, so they can be resolved in advance by a train prioritization system. For example, trains with a higher priority will be given right of way and trains with lower priority will have to wait.

The problem is that 'implement weak reservations' sounds like a nice and simple addition to YAPP. Doing it right, i.e weak reservations that actually work in all cases, is many things, but certainly not nice and simple.

Proper weak reservations imply that trains influence each other's pathfinding decision, because otherwise it's not possible to optimally choose between using the weak reservation or making another. This is something the current pathfinder framework can not do. So implement weak reservations turns into someting like do a complete pathfinder rewrite, a much bigger task than YAPP was.

Strictly speaking, it is not necessary that trains influence each other's pathfinding decision in order to implement 'weak' reservations. However, it is correct that 'weak' reservations are useless with bi-directional double track without a good train prioritization system using 'lookahead' reservations.

[INP]

I try to report this as a bug but I did not receive registration e-mail so I am posting it here.
If one train is blocked for some time it reverses direction on a one way track. This starts an avalanche effect and all the trains behind are starting to reveres direction. This makes massive traffic jam that needs about 10 minutes to clear on its own and some trains never clearer at all.

[Tekky]

If one train is blocked for some time it reverses direction on a one way track. This starts an avalanche effect and all the trains behind are starting to reveres direction. This makes massive traffic jam that needs about 10 minutes to clear on its own and some trains never clearer at all.

This problem has been reported before. Please refer to this post for information about solving it.

[broodje]

No, that report is about reversing in front of PBS signals. The problem is that trains also reverse in front of one way signals. When trains reverse for normal signals they keep waiting for a path forever, causing the mess. In a way normal one way signals are made a bit un-usable because of that. As far as I know there is no setting to stop trains reversing in front of normal signals.

[peter1138]

Maybe it is possible to check if a reverse path can be reserved before actually reversing?

[broodje]

I think that would be the best solution. If no path can be reserved there is no good reason to reverse in the first place.

[Tekky]

Maybe it is possible to check if a reverse path can be reserved before actually reversing?

I would say, it should check before reversing whether a path can potentially be reserved, i.e. whether a reservation would be possible if there were no other trains in the way. However, this has the disadvantage that the train may reverse and then wait for a stuck train, i.e. it would be waiting in vain.

Therefore, there should be an option to disable automatic train reversal with legacy signals, as is already possible with PBS signals. I never was a fan of automatic train reversal anyway, as this was a workaround for trains waiting inside junctions, which can now be prevented by using YAPP PBS signals. So, I see no reason to use automatic train reversal anymore, unless you prefer to use the old non-YAPP signalling system.

[Youri219]

Maybe it is possible to check if a reverse path can be reserved before actually reversing?

I would say, it should check before reversing whether a path can potentially be reserved, i.e. whether a reservation would be possible if there were no other trains in the way. However, this has the disadvantage that the train may reserve and then wait for a stuck train, i.e. it would be waiting in vain.

There, there should be an option to disable automatic train reversal with legacy signals, as is already possible with PBS signals. I never was a fan of automatic train reversal anyway, as this was a workaround for trains waiting inside junctions, which can now be prevented by using YAPP PBS signals. So, I see no reason to use automatic train reversal anymore, unless you prefer to use the old non-YAPP signalling system.

I don't see a use of automatic train reversal at all on a well-built network, regardless of the type of signal you use.

It's a remainder of TTD where the pathfinder were too simple to get anything done right the first time.

[broodje]

I don't see a use of automatic train reversal at all on a well-built network, regardless of the type of signal you use.

I tend to build realistic looking networks, without junctions as they are modeled in the junctionary. As a result you sometimes have sub-optimal junctions where trains have to wait for their turn to cross it. (ever tried modeling Elly North Jn? waiting trains guaranteed ). In those circumstances I'd really love it if trains stopped reversing.
And youri219, really those kind of comments are not useful at all, there are more ways to play this game, don't think building trunk routes with clover leaves is the only way to play.

[arikover]

I would like to thank you Michi_cc for that amazing work. I know it is quite late, but I had to wait for this feature to be in trunk.

Thank you again!

[Wolf01]

ehm... it is in trunk, maybe you mean stable like 0.7.x, since in 0.6.x it won't be included
You can always download the nightly, if devs don't make significant changes like the inclusion of a new feature split in various pieces they should be stable enough as the stables themselves

[MJS]

I think he has the nightly, and that is why he has now discovered PBS, and is grateful for it .

[Wolf01]

Oh now I see he said "I had to wait" and not "I have to wait", English is a so nice language