Priority for trains

[Batti5]

Hi, my suggestion is to have priority, like Has priority or give priority, and a type of signal that would let train that have priority first, others later as you an see in the pic:

snapshot4.png (30.63 KiB) Viewed 8521 times

if the priority train reserved the track to a signal before it, the other two train will wait, if but thay can pass to the next block before the priority train gets there the signal will let them go, if there is no priority train coming the signal is green for all.

[cmoiromain]

I use the following system.
A train coming from the green line will reserve the path first, so the one on the red will have to wait. However, if the train on the red arrives soon enough, the one on the green will take the track at the top with the signal, to make sure it does not have to completely stop long before the junction. The length of that piece of track depends on the length and speed of your trains.

[Batti5]

Good idea, it should be added to the OTTD Manual, Seriously speeking.

[Aali]

You can build this already with existing presignals.

If you've seen the right-of-way depot on the wiki, it's using the same concept.

Useful reading:
http://www.openttdcoop.org/wiki/Priorities

[HariSeldon]

However, if the train on the red arrives soon enough, the one on the green will take the track at the top with the signal, to make sure it does not have to completely stop long before the junction.

I'm not sure that I've understood how that works:

It "only" help, having the train on "green" track not to completely stop,
but it do not assure an actual priority to the tain on green track, doesn't it?

Good idea, it should be added to the OTTD Manual, Seriously speeking.

I've added some information there (It was not pointerd out that PBS was used. That may confuse not expert reader of the manual/wiki)

[el koeno]

I use the following system.
A train coming from the green line will reserve the path first, so the one on the red will have to wait. However, if the train on the red arrives soon enough, the one on the green will take the track at the top with the signal, to make sure it does not have to completely stop long before the junction. The length of that piece of track depends on the length and speed of your trains.

What happens to a train right coming in right behind the green one? It will go to the little by-pass thing you have, and I guess it will have lost its priority over the red line, right? If a third train comes along the green line, you're in an even worse position, as it'll have to wait at the back. So while I think it's an improvement over the regular situation, it's far from perfect. Having said that, I haven't managed to come up with a better solution my self.

A simple "transparent" sign might work. It would be transperant in that it allows trains on the green track to reserve the block behind it as well. The green trains would keep reserving the junction block, and the red train would only be allowed to move if there's no more green trains coming.

[cmoiromain]

Indeed my solution is far from perfect. But in most situations it works fine, when not so many trains use the track. The main advantage is that it is easy to build and doesn't take much place. On more important lanes, I use the presignal priority, which you linked to on the coop website, and which works better, but is longer to build.

[el koeno]

I don´t really like presignal priorities. I think they´re a pain to build, they look ugly, and they take up too much space; I build most of my railroad junctions near towns these days, so space is at a premium.

[PhilSophus]

I don´t really like presignal priorities. I think they´re a pain to build, they look ugly, and they take up too much space; I build most of my railroad junctions near towns these days, so space is at a premium.

I agree. I once wondered why I regularly got traffic jams at a certain place in my network. It turned out that the problem was a little track piece connecting the track with the opposite track (it was needed for a very specific case). I had just overlooked that piece when I added a pre-signal prioritizer to a YAPP-only track.

What I would like to have is kind of a priority path signal (PPS) that works as follows:

If a reservation reaches a PPS signal and the continuing path can be determined (i.e. the next order of the vehicle is not before that signal) the path to the next safe waiting point is reserved immediately if possible. If this reservation is not possible, the PPS will act like any other path signal.

So take the following example: M2 is that imagined priority path signal. M1, M3, S1, S2 are normal one-way path signals. If possible M2->M3 will be reserved as soon as a reservation reaches M2 (in this case M1->M2):

priority_active.png (8.07 KiB) Viewed 8211 times

If a train from the side line has already a reservation behind M2, it will fall back to a normal path signal:

non_prioritized.png (7.12 KiB) Viewed 8206 times

As long as the distance between M1 and M2 is long enough, trains on the main line will never have to stop as trains from the side line are either far enough ahead or will wait for access to the main line.


I don't know the YAPP part of the source code (otherwise I would already have implemented that feature ), but I have the feeling that implementing priorities in this limited way is not overly complicated (wellm there are still enough thinks to consider, like clearing reservation when turning around, etc.), while being a great improvement and all you need in most cases.

[Tekky]

In this context, I would like to point out my recommendation of having "weak" and "lookahead" reservations. Two years ago, at a time before YAPP PBS signals existed, I wrote a wiki article about how my suggestions could be applied to bi-directional double track. Bi-directional double track has some interesting problems, including train priority.

Also, in this post, I made some further comments about what types of additional reservation types would be appropriate in OpenTTD.

[Brianetta]

What I would like to have is kind of a priority path signal (PPS) that works as follows:

If a reservation reaches a PPS signal and the continuing path can be determined (i.e. the next order of the vehicle is not before that signal) the path to the next safe waiting point is reserved immediately if possible. If this reservation is not possible, the PPS will act like any other path signal.

This is good, but I'd much rather have a priority path order. It's the current order, not the current physical location, that determines whether a train should have priority. Empty trains can wait. Full trains shouldn't have to. Passenger trains should be given precedence over coal trains, etc, etc.

This should be fairly easy for anybody who's familiar with YAPP and the orders system to implement. An additional order flag, which could appear as "...with high priority" would cause YAPP to reserve two safe waiting places instead of one, if possible, as you describe. Perhaps we could really go overboard and allow arbitrarily high priorities, so your prestigious express train can reserve up to ten sequential paths and practically guarantee an uninterrupted journey...

It'd be nice to see those path signals light up green for longer than a split second. (-:

[el koeno]

What I would like to have is kind of a priority path signal (PPS) that works as follows:

If a reservation reaches a PPS signal and the continuing path can be determined (i.e. the next order of the vehicle is not before that signal) the path to the next safe waiting point is reserved immediately if possible. If this reservation is not possible, the PPS will act like any other path signal.

This is good, but I'd much rather have a priority path order. It's the current order, not the current physical location, that determines whether a train should have priority. Empty trains can wait. Full trains shouldn't have to. Passenger trains should be given precedence over coal trains, etc, etc.

This should be fairly easy for anybody who's familiar with YAPP and the orders system to implement. An additional order flag, which could appear as "...with high priority" would cause YAPP to reserve two safe waiting places instead of one, if possible, as you describe. Perhaps we could really go overboard and allow arbitrarily high priorities, so your prestigious express train can reserve up to ten sequential paths and practically guarantee an uninterrupted journey...

It'd be nice to see those path signals light up green for longer than a split second. (-:

I'd actually prefer the PPS approach (I'll just continue using the terms introduced here). Your PPO is nice, but what if a passenger train gets stuck behind an empty iron ore train? It would have to wait while the iron ore train yields to every full goods train it encounters. I just want trains on the main line to keep moving, I don't mind trains on sidelines waiting for a while, PPS seems nice for that purpose.

Having said that, PPO might be a nice addition where two lines of equal priority meet, or to make overtaking lines work better. Actually I think that last one is a definite reason to include a PPO system.

@Tekky: I don't quite understand: do you think we could use PPS to achieve your weak reservations?

[Tekky]

@Tekky: I don't quite understand: do you think we could use PPS to achieve your weak reservations?

No, the other way around.

My proposal includes different types of reservations, including "weak" and "lookahead" reservations. These "lookahead" reservations can be used to detect conflicts between trains in advance, so they can be resolved before the conflict actually takes place. In other words, it can be decided in advance which train should be given right of way, so the train which has to give way can stop in time to give way to the other train.

I think that such a system would be better than a train making an additional strong/exclusive reservation. Because if high-priority trains make additional strong/exclusive reservations, this would mean that high-priority trains will also hinder each other more, and not just hinder low-priority trains.

[PhilSophus]

This is good, but I'd much rather have a priority path order. [...]

I'd actually prefer the PPS approach (I'll just continue using the terms introduced here).

I also prefer the PPS variant over the PPO one for the following reason: A main line in my definition is one with very high traffic. You want to keep the traffic flowing by all means in this case. If an express coming from a side line causes an empty freight train on the main line to stop the whole flow on the main line will come to a stop.

In this context, I would like to point out my recommendation of having "weak" and "lookahead" reservations. Two years ago, at a time before YAPP PBS signals existed, I wrote a wiki article about how my suggestions could be applied to bi-directional double track. Bi-directional double track has some interesting problems, including train priority.

Also, in this post, I made some further comments about what types of additional reservation types would be appropriate in OpenTTD.

Tekky, I was aware of your suggestion, but it has been a while since I read it. IIRC, my impression was that while being a well thought out system, it was too complicated. You always have a trade-off between perfectionism and comprehensibility and my suggestion was aimed to be a bit less prefect than yours but easier to understand (and implement, I hope). But anyway, I have to reread your suggestion before I can be more specific.

[Batti5]

Nice, but also a suggest a signal, if thare is a line & a train get broken or in a jam, the yellow signal lights up at a beginning of a block will make the train choose
an alternative track to destination or else stop at a train shelter.

[PhilSophus]

Tekky, I know read your post in the YAPP topic, let me just cite a little part of it:

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.

That's just my point. It will not only be hard to understand for the average user what those five kinds of reservations do, it will also require a complete rewrite.

I hope, my suggestion is doable on the basis of the current YAPP code. Not that this is the most important point, but there are even two kinds of signal graphics unused which could be designated normal and one-way priority path signals.

[555gln22]

Tekky, I know read your post in the YAPP topic, let me just cite a little part of it:

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.

That's just my point. It will not only be hard to understand for the average user what those five kinds of reservations do, it will also require a complete rewrite.

I hope, my suggestion is doable on the basis of the current YAPP code. Not that this is the most important point, but there are even two kinds of signal graphics unused which could be designated normal and one-way priority path signals.

I would love to be able to set train priority quite simply, with a drop-down in the orders menu, that had, for example :

Express
Limited
Local

With Passenger trains always taking priority if a freight and passenger train of the same priority meet, and then by unit value of freight otherwise. If a an express train is travelling down a line and a local train has a reservation for the next section, it should be able to "grab" the reservation from it, assuming it is safe to do so. Would that be possible?

[Tekky]

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.

That's just my point. It will not only be hard to understand for the average user what those five kinds of reservations do, it will also require a complete rewrite.

The user will not have to understand these 5 reservation types. All the user has to do is mark the signals as "safe" or "unsafe" waiting locations, appropriately. The trains will then make the appropriate reservations automatically. As long as no signals were inappropriately marked as "safe" waiting locations, there should be no danger of a deadlock. For an explanation of what the difference between "safe" and "unsafe" waiting locations are, please see the wiki article that I mentioned in my previous post, which talks about "unsafe" waiting locations in the context of bi-directional double track. Please note that the current OpenTTD YAPP/PBS signalling system only supports signals that are "safe" waiting locations.

However, it certainly will be a lot of development work to implement everything in my concept. I think the best thing would be to make the current YAPF cache a persistent graph of the track layout, so that all reservation information can be applied to this graph instead of the map array. This has the advantage that the graph could store the reservation information per track segment* (see footnote) instead of individual track pieces, so it would be technically no problem to have many different types of reservations on the same track, because the reservations do not have to be stored in the map array. Also, it would be a lot more efficient to handle reservations, if not every individual track piece has to be updated. Only the track segment would have to be updated.

In this system, it would be no problem for all trains to have additional "lookahead" reservations, so that conflicts between trains can be detected and resolved in advance. When such a conflict is detected, it could be resolved for example by the train with the lower priority giving way to the train with the higher priority.

Footnote:
* A track segment is a length of track with no switches in-between, i.e. a length of track where a train has no choices to change track. The current YAPF cache considers such a length of track with signals in-between as one track segment. However, I would define a track segment so that the part before a signal is considered one track segment and the part after a signal is considered a different track segment. This definition of a track segment has the advantage that it is the smallest logical unit required for train reservations. If one piece of track in this segment is reserved, all others can be considered as reserved, without any disadvantages.

[el koeno]

Okay, I can see how Tekky's system can be used instead of the PPS system*. However, Tekky's system seems like a lot of work to implement. Some of that work -the "lookahead" reservation- is the same as the work that needs to be done for a functioning PPS system. In Tekky's system there will always be lookahead reservations, but in PPS they would only be necessary at special signals. The PPO system would change how OTTD resolves conflicts, so that would be a logical next step. In short: there doesn't seem to be a reason not to start work, so I'm off to learn to code! See you in three years with a functioning priority system!

* EDIT: I just realized it's unclear to me how Tekky's system will ensure flow on a mainline. This is the main thing PPS would do, and really all I need priorities for. But as I have to get to class (unfortunately not a coding class ), I don't have time to really think about it now.

[rbn2903]

This is the main thing PPS would do, and really all I need priorities for.

I'd like to mention, that I play with a lot of Passenger/Mail lately (Cargodest + ITIM) and for me there is no main line, just a bunch of junctions. In my case a system like PPO (or weak/lookahead reservations) would make much more sense, so that very fast trains would get priority. Although I can see the point in all three systems!
And maybe PPO and PPS don't exclude (?) each other?

Rainer