The International Simutrans Forum

 

Author Topic: Priority signals  (Read 5685 times)

0 Members and 1 Guest are viewing this topic.

Offline Leartin

  • Devotee
  • *
  • Posts: 1108
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #35 on: August 13, 2018, 02:55:45 PM »
It would look completely out of place if trains enter a section between two traditional signals already occupied by a train, except in exceptional circumstances. I'd say the same about signal spacing shorter than normal train lengths. At least the latter is optional. One can chose not to build signals that close if it feels wrong.
Both would be a choice, though. If you want it to feel correct, you'd use normal, bi-directional tracks and signals in believable distances, as you can already do. But that hurts capacity of the track, and one of the arguements for whether or not a signal is useful seems to be whether throughput can be optimized, and if we go with that, any playstyle that does not optimize does not really matter.

Ideally, the game would make it so that the choice that feels correct IS the correct choice, by having some disadvantage with signals too close to each other. Then, you'd only have blocks longer than train length, stations are train length, so blocks and stations would have about the same length and one priority signal would be enough for a faster train to overtake a slower one in a station, even if it means that the slower one has to wait instead. But that would mean to intentionally reducing throughput, so I don't see it happen...

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #36 on: August 13, 2018, 05:13:11 PM »
Both would be a choice, though. If you want it to feel correct, you'd use normal, bi-directional tracks and signals in believable distances, as you can already do. But that hurts capacity of the track, and one of the arguements for whether or not a signal is useful seems to be whether throughput can be optimized, and if we go with that, any playstyle that does not optimize does not really matter.
I'm not so sure this would be a choice for the player, but a question of how Simutrans behaves in general.

Furthermore, I don't really believe in bi-directional signals. That these are the easiest to build in Simutrans is bad, because they are the surest way to get deadlocks. I only use them in very special circumstances due to lack of single-sided signals.

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #37 on: August 13, 2018, 07:42:55 PM »
Quote
A recursive reservation will have troubles if these signals are dragged. Then the entire stretch will be reserved.

For pre-signal the recursive reservation is needed. I magine a line merging in one block flowwed by two crossings of a second track, all single tracks both directions used. They would need recursive pre-signals. (Granted, most player use two tracks or bridges for such situations, if possible.)
These two points are valid for both presignals and priority signals, so there are not really good arguments.

And, once again: priority signals is thought as a signal that can be dragged over some blocks, this feature is intended ! The point is precisely to reserve enough space for a train so as to prevent other trains from passing.

Again: I'm against disabling features just because they can be misused. Players have to pay attention to what they do, and even if they do a such mistake (that's really unlikely to happen, did it even happened to you once ?) then it's a game, not the real life, it's made to try things and make mistakes unless these mistakes happen too often so that the gameplay is ruined.
If you go this way, there is already a tremendous amount of ways to break a train network.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #38 on: August 13, 2018, 08:48:53 PM »
It doesn't help to pay attention to what you do when you do not understand what you do. It took me 11 years to learn how pre-signals actually work! And it wasn't from not reading the manual. The English help text states that pre-signals reserve the track "either between three consecutive signals or to next destination". Although it doesn't say so, I assumed it meant "whichever is shortest", because that is how the normal signals work with similar phrasing. Not that the interpretation "whichever is longest" makes it correct either.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9353
  • Languages: De,EN,JP
Re: Priority signals
« Reply #39 on: August 14, 2018, 01:10:25 AM »
To Leartin idea:

Since Simutrans has no directional crossings, it cannot tell, if a branch is incoming or outcoming. Therefore, if stopping at crossings, it would need to stop reservation directly before any branch, including the one where the train branches to the station. (And thus never have priority function).

But if the train reserves the track always until the next train, I am not sure if this could lead to deadlocks. Additional logic on the direction of the train would be needed: Imagine one train reserves to the preceeding train in the same direction. That train exits that section and instead the train in the other direction goes in. But this can be solved checking the direction of the train. If it does not match, just reserved to the next signal.

I think some "do not block this crossing" pre-signal type like signal will be needed for a few special cases. But generally this looks is a great idea to increase throughput without putting so many signals. Also it makes the focus on transport and not micromanaging trains.

On penalty for too close signals: Signals too close limit the maximum speed. Signals every tile's max speed is 100, I think. (May have been rectified though). Also, in reality signals shorter than a train are not uncommon on high capacity track sections close to stations and urban rail systems. And of course signal cost and maintenace can be increase for higher penalty.

Offline Leartin

  • Devotee
  • *
  • Posts: 1108
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #40 on: August 14, 2018, 04:26:27 AM »
Since Simutrans has no directional crossings, it cannot tell, if a branch is incoming or outcoming.

Simutrans has no directional crossings because it has no directional ways. Maybe this was not clear enough, since I tried to shorten my post, but my intention was not to build tracks and make them monodirectional via signals, but to give the track itself that property. I guess the same way roads can get that property in the one-way-two-lane patch. Which means a normal track piece would have two incoming and two outgoing ribis. Only monodirectional tracks and dead ends would have the characteristic to have only one incoming ribi. Since deadends don't matter for routing, you only need to look for that characteristic, and any tile that does not have it marks a stop for a train on monodirectional tracks.

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #41 on: August 14, 2018, 08:41:58 AM »
@Ters: I see two ways of playing: either you do things knowing what you do, that's what all experimented players do and that's fine, so you don't make such mistakes, or you are experimenting things as a beginner so you know things can go wrong and it's okay, that's called learning. What you are saying is using a signal you don't know anything about though expecting a certain result. For instance, if I put a new signal called "foobar signal" with complicated graphics, are you going to use it instead of normal signals and expecting them to magically work the same way ?

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #42 on: August 14, 2018, 09:42:56 AM »
There is a third way: Rather than knowing or experimenting, you do things by the book. I learned to play Simutrans from a tutorial PDF that at least used to be available on the Simutrans site. Then I built upon the knowledge I learned from that to do more complex stuff. I never really experimented, at least with signals.

The pre-signal is particularly nasty, because:
  • The name and looks (in pak64 at least) indicates to someone familiar with German signals that it is a distant signal (Vorsignal), but it works nothing like them. The priority signal is in fact much more like a distant signal, except for this recursion thing.
  • It does not behave like the documentation says it does.
The behavior of the choose signal and long-block signals, which were completely alien signal types to me and for which I had no preconception of how they operated, was fortunately adequately documented. However, this forum has seen a fair share of beginners who were utterly confused as to the workings of the choose signal. They have pretty much disappeared, which I think was because choose signals were changed to act like a normal signal if it hit another signal before it reached the current destination station.

For instance, if I put a new signal called "foobar signal" with complicated graphics, are you going to use it instead of normal signals and expecting them to magically work the same way ?
No, but I did not expect priority signals to work like normal signals either. In fact, I got it backwards! I expected priority signals to be one-off signals, like choose signals (and how I use pre-signals), but they are actually meant to be used like normal signals in the sense that you put several in a row.

Furthermore, a "foobar" signal with complicated graphics carries no preconceptions of how they work (unless, perhaps, one is familiar with the MIT model railroad). Something called a priority signal does. The name alone suggest priority at the upcoming junction, which is a feature asked from from time to time. That the train waiting a the priority signal would always get green before trains waiting at other signals guarding the same block. The description quickly dispelled that misconception, for me, but I never expected that the priority signal, or the pre-signals, were hogging signals. That is an attribute I would rather have expected from the signal call long-block signal. (Which actually doesn't hog, but it only gives green if it could have. I can only assume that the reason this doesn't cause more confusion, is because most players don't even think of trying it without guidance.)
« Last Edit: August 14, 2018, 09:57:15 AM by Ters »

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #43 on: August 14, 2018, 10:49:13 AM »
I"m sorry, I did not consider about playing from books indeed. You're right that the help text is not very clear and even confusing about presignals. I'm not sure that expecting them to work like a particular signal from reality was a good thing in the first place.
If I understood you well, the main concern here is the risk of confusion between a signal in the game and a signal in reality, isn't it ? Its hard to get a name that fully describes the behaviour of a signal, and imho it's not here for that. The recursion is still a key feature of the priority signal and I (or you) may take care of writing its documentation so the same confusion as presignals would be avoided.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9353
  • Languages: De,EN,JP
Re: Priority signals
« Reply #44 on: August 14, 2018, 03:28:02 PM »
If one touches the signal system, I am getting warm to Leartins idea. However, to avoid trains stopping in the middle of nowhere, one just to make sure the next trains has a reservation through the next signal as long as its length in tiles, and only drive forward then. If there is not enough space for the first to reserve, or rather trigger a reservation attempt of the train ahead. (and recursively so). The downside is that trains may stop for a split second at full speed waiting for a logn cascade (or slow down, if they need to trigger a cascade). Also this szstem woudl require more resources the more trains are running without sginals, and some signals would be still required at some point.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #45 on: August 14, 2018, 08:46:45 PM »
I'm not sure that expecting them to work like a particular signal from reality was a good thing in the first place.
I don't see why I, as a beginner, should expect a game to require signals that never have been needed, or perhaps even imagined, in two centuries of railroad use in the real world. It is obvious now in hindsight that the realities in Simutrans is vastly different. Not so much then.

Its hard to get a name that fully describes the behaviour of a signal
At work we have a saying that naming things is the hardest and most time consuming part of software development.

The downside is that trains may stop for a split second at full speed waiting for a logn cascade
How is this different from pre-signals? The extra complexity of checking for branches?

Offline ACarlotti

  • *
  • Posts: 299
Re: Priority signals
« Reply #46 on: August 14, 2018, 09:18:13 PM »
I don't see why I, as a beginner, should expect a game to require signals that never have been needed, or perhaps even imagined, in two centuries of railroad use in the real world.

The difference is that in real life you can tell signallers how to regulate traffic, and often they are working to a carefully planned timetable. Simutrans doesn't have the benefit of a timetable, and doesn't have intelligent signallers to regulate traffic. Priority signals would be attempting to prioritise faster trains in the same way that signallers would have done (and still do) in real life. However, in Simutrans the only place we can put this functionality is in the signalling system itself.

Offline sebastien

  • *
  • Posts: 14
  • Languages: FR, EN
Re: Priority signals
« Reply #47 on: August 14, 2018, 09:30:41 PM »
At work we have a saying that naming things is the hardest and most time consuming part of software development.
I agree. How about naming it "early reserving signal" or "overtaking signal" ?

It took me 11 years to learn how pre-signals actually work! And it wasn't from not reading the manual. The English help text states that pre-signals reserve the track "either between three consecutive signals or to next destination".
What it really does, is to repeat the authorization to cross the next signal, whatever it is. If it repeats a choose signal, a train can cross a pre-signal if it can cross the choose signal. Same for the classic signal. If it repeats another pre-signal, it can cross the first if it can cross the second, which can only be crossed if the signal it repeats can be crossed subsequently.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #48 on: August 14, 2018, 09:55:04 PM »
The difference is that in real life you can tell signallers how to regulate traffic, and often they are working to a carefully planned timetable. Simutrans doesn't have the benefit of a timetable, and doesn't have intelligent signallers to regulate traffic.
I know that now. That does not mean it's obvious. Although one might deduce that Simutrans can not work as the real world in every aspect, it is not clear that what sounds like and looks like a distant signal is something completely different, because that happens to be what however Simutrans works needs in very specific circumstances.

How about naming it "early reserving signal" or "overtaking signal" ?
"Overtaking signal" is better than "priority signal" in that it doesn't steal the name from the alternate priority signal I described a few posts earlier, but there is no implicit overtaking involved. Signals in Simutrans seem to be named for what they do, not for what they can be used for. An alternate name for the pre-signal might be "multi-block signal". That is fitting for gauthier's signal as well, although they differ in the nature of "multi".

"Express signal" just popped into my head, although I'm not sure if it fits what I just wrote.

Offline ACarlotti

  • *
  • Posts: 299
Re: Priority signals
« Reply #49 on: August 14, 2018, 11:10:26 PM »
I see it as a variant on the presignal that will clear and permit a train to pass even if the next signal can't be cleared. So perhaps something like "permissive presignal"? Although "permissive" might be the wrong choice of word since it conveys the real-life meaning of permitting trains to pass on red. Alternatively something like "semipresignal" (I don't think that's a nice word, but it conveys the idea that it's behaviour is between that of a presignal and an ordinary signal).

I think the name "priority signal" would suit a signal that was guaranteed to clear first if trains on two different routes were wanting to reserve the same section of track. So if you put a priority signal on a congested mainline, then trains wouldn't be release from a siding until there was a gap in the traffic. This could be applied to any existing type of signal (so "priority presignal", "priority choose signal", etc.).

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #50 on: August 15, 2018, 07:45:28 AM »
Quote
I don't see why I, as a beginner, should expect a game to require signals that never have been needed, or perhaps even imagined, in two centuries of railroad use in the real world.

I don't see why I, as a beginner, should expect a game to exactly reproduce a real system that would be probably more complicated than needed, that would depend of the coutry where it works and that most players don't know about.

... I'm sure every people here would have even different answers of this kind to make. Everyone has different way of approching problems in this game. We cannot make things so that nobody get confused, only so that most people don't.

By the way, I have a question for you: if the name "priority signal" is so confusing, why didn't you report this confusion in your first answers ? Sounds like this confusion was not problematic until you knew about recursion and, obviously, didn't like it as the sarcastic alternate name for presignals, "infinite block signal", suggests.

Quote
At work we have a saying that naming things is the hardest and most time consuming part of software development.

We are not naming a variable for people reading code, we are naming an object for players to use regularly in the game. The point of this name is to be a compromise of shortness and ability to efficiently reference the actual object behind it. The point is not to explain newcomers what the object is, although it would be nice.

I've thought of semi-permissive presignal, semi-non-blocking presignal or even non-blocking presignal ... very long names which have the problem of referencing another type of signal. Priority signal was the best I found since it tells what the signal is used for. "Express signal" has almost the same sense, thus has the same risks of confusion.

Quote
I agree. How about naming it "early reserving signal" or "overtaking signal" ?
Imho the first one is too long and the second one restrains the signal to one of its uses. A use other than overtaking is prioritizing trains from one direction on a merging, for instance make a high speed train go first before a freight one that borrows high speed line on a short distance.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #51 on: August 15, 2018, 08:51:21 AM »
By the way, I have a question for you: if the name "priority signal" is so confusing, why didn't you report this confusion in your first answers ? Sounds like this confusion was not problematic until you knew about recursion and, obviously, didn't like it as the sarcastic alternate name for presignals, "infinite block signal", suggests.

It just took a while for me to realize/remember that "priority signal" was a fitting name for a different signal that has been requested in the past. In addition, confusing naming didn't become an issue until I realized that I had been confused.

And the name "infinite block signal" wasn't so much sarcastic as it was the limit of my imagination for something akin to "long block signal" before I came up with "multi-block signal".

Offline sebastien

  • *
  • Posts: 14
  • Languages: FR, EN
Re: Priority signals
« Reply #52 on: August 15, 2018, 09:04:49 AM »
"Overtaking signal" is better than "priority signal" in that it doesn't steal the name from the alternate priority signal I described a few posts earlier, but there is no implicit overtaking involved. Signals in Simutrans seem to be named for what they do, not for what they can be used for. An alternate name for the pre-signal might be "multi-block signal". That is fitting for gauthier's signal as well, although they differ in the nature of "multi".

"Express signal" just popped into my head, although I'm not sure if it fits what I just wrote.
Maybe "Priority-blocks signal" would be a better name ? Or "Express blocks signal" ?

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #53 on: August 15, 2018, 07:13:57 PM »
I'm aware that a name can always be confusing and I strived to find the one that would confuse the least people. These names need to be short to fit in a toolbar and be used by players when they talk about it. Considering a whole set of players who have different levels of experience with the game, different acquaintance of the trains'environment, etc... it would be unrealistic to hope to find a name that means the right thing in everyone's mind without further explanations. If you find the right name, I'm still opened to propositions.
Quote
In addition, confusing naming didn't become an issue until I realized that I had been confused.
It seems to me that you were confused by the explanations, not necessarily by the name itself as long as we don't expect it to be fully self-explanatory. If you can point out what confused you in the explanations of the first post, I would be happy to make it clearer.
besides this naming issue, are there still issues or suggestions regarding how the signal works ?

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1320
Re: Priority signals
« Reply #54 on: August 15, 2018, 07:51:22 PM »
I don't see the need for adding another specialty signal with a confusing name - presignals generate enough questions...

Isn't this really just a 3 aspect signal? And when chained 4, 5, 6...
Remove the chaining ability, create fixed 3 and 4 aspect objects, and you have something with a 'normal' name that matches reality. Do you really need more than 4 blocks under reservation?

Also, having an express overtake a local would work a lot easier if the local remained stopped for a while. i.e. Paks actually using the loading time feature.

Offline ezosresyek

  • *
  • Posts: 3
Re: Priority signals
« Reply #55 on: August 15, 2018, 08:33:15 PM »
I’ve been playing pak128 for the best part of three years, and have just created an account to say I would find the proposed priority signal very useful.

My stations tend to be build next to the mainline. This way, stopped trains don’t block trains that don’t call at the station. This means departing trains, once loaded to their target level, need to pull back onto the mainline, which can result in a train passing at speed needing to come to a full stop, while the departing train joins the mainline. In that case, it would be much better if the train already on the mainline could just power through, with the departing train waiting until the train at top speed has passed. It sounds like the proposed priority signal would help achieve that.

I don’t have a better name to offer, “priority signal” seems to cover the intended purpose.

(With thanks to everyone involved in maintaining this amazing game!)

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #56 on: August 15, 2018, 10:39:01 PM »
Do you really need more than 4 blocks under reservation?
If one has 8 tile long trains and signals every 2 tiles, one does.

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #57 on: August 16, 2018, 05:11:30 PM »
@Turfit: all that you said has already been discussed in this thread. The need was clearly exposed in the first post, and several players stated that they also feel this need. Presignals generate as many questions as many other features, the name on its own can hardly be self-explanatory and help texts (yet not always up to date or exact as Ters reported for the presignal) are here. A tutorial would be even greater. Loading time cannot achieve a good enough result, if it could I would not have made this signal. Feel free to test it by yourself.

It sounds like only people who already cannot understand the use of presignals are against the priority signal. Then should we leave a potentially useful signal because some players, unfortunately in the coding team, don't play in a way that would use it, using an excuse of confusion whereas players using presignals immediately understand how useful a semi-permissive presignal would be ?

Quote
My stations tend to be build next to the mainline. This way, stopped trains don’t block trains that don’t call at the station. This means departing trains, once loaded to their target level, need to pull back onto the mainline, which can result in a train passing at speed needing to come to a full stop, while the departing train joins the mainline. In that case, it would be much better if the train already on the mainline could just power through, with the departing train waiting until the train at top speed has passed. It sounds like the proposed priority signal would help achieve that.
Indeed, priority signal is designed for that.

Offline Ves

  • Devotee
  • *
  • Posts: 1555
  • Languages: EN, SV, DK
Priority signals
« Reply #58 on: August 16, 2018, 09:11:29 PM »
I know I usually never comes around this corner of the forum, but I wanted to add my thoughts to this mix 😊

I never understood what the presignal did until I realized it is a signal that reserves 2 blocks. Then I started wondering why it wasn’t just called a “2 block signal” or “double block signal” which I really think would be completely understandable and intuitive as soon as you understand the concept of a “block” in simutrans, which you usually do as soon as you start to place some signals.
I think it is wrong to call it something like a “presignal”, since that appeals to something that it isn’t is, just like you don’t call road vehicles “rail vehicles”. The player assumes that, whatever (s)he recognizes from the real world in simutrans, to work like (or sort of) in the real world.
What to call the “priority signal” I also have been thinking of since the start of this thread, and I again fall on the same doorstep as with the presignal: what is a priority signal? As I understood it it doesn’t really “prioritate” the booking of a block from that signal over a booking from another normal signal, but rather it attempts to book more blocks in advance, hindering other signals to book conflicting blocks. Even though I exclusively play extended, I support this new signals existence in standard, since I believe it only adds to the toolbox that the player have. As with the “presignal” (or imho, “two block signal”) I think that the focus should not be so much as to what it tries to solve as to how it does alter the signaling logic. Because of the similarities with the other signal (it at least tries to reserve two blocks) I would suggest a name that is also based on the other signal, and, as gauthier actually writes himself, it could actually be the solution to add the word “semi” or another similar word to the name.
Something like this: 
“2 block signal” / “double block signal”
“2 block signal (semi)” / “semi double block signal”

One could also call it “multiple block signal” with the reference that it might reserve multiple blocks ahead if they are placed after each other, but that is true also for the existing “presignal”? If so, that would render that name less suitable i think.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1320
Re: Priority signals
« Reply #59 on: August 16, 2018, 09:16:10 PM »
@Turfit: all that you said has already been discussed in this thread.
Where?  Ters briefly touched on use of real life signal at the end of post #30, but I don't see anything further.

The need was clearly exposed in the first post, and several players stated that they also feel this need.
No. The desire/need for a method to allow an express to pass a stopping train was exposed, not a need for *this* signal.


Let me remove the superfluous junk from my post that I always throw in to reveal my intended meaning since you apparently can't read my mind...  (and this sentence would be an example of that junk, so gotta keep it!)
"I don't see the need for adding another specialty signal..." when instead you could "...create fixed 3 and 4 aspect objects..." that "matches reality".


I'm not arguing against the functionality of multiple reserved blocks, but against adding another Simutrans specific invention (specialty signal I called it above) when applying a property from real life mainline signalling would have the same effect. IMO it's easier to understand multi-aspect signalling from real signals than a Simutrans invention of 'priority' signal.

Simutrans existing 'normal' signals have two aspects, red and green, proving two indications, stop - next block occupied, proceed - next block free.
If in a sequence of these signals you add the proposed priority signal, you've effectively created a 3 aspect signal - red, yellow, and green per typical color light signals, with indications of stop - next block occupied, proceed - next block free - expect stop at next signal, and proceed - next 2 blocks free.
Chain in one more priority signal and you're still in the realm of easily finding examples of this behaviour in real signalling - a 4 aspect signal. The added aspect is probably less universal between countries than the red/yellow/green, but flashing yellow is common. Continuing to spell it out - aspects of red, yellow, flashing yellow, and green indicating stop - next block occupied, proceed - next two blocks free - expect stop in 2 signals, proceed - next block free - expect stop at next signal, and proceed - next 3 blocks free.
Chain in one more - 5 aspects. Probably can't find this common from real life - I think the British had this for a while as a flashing green aspect for 4 block free indication. Not going to spell all these out as I hope the point is made...

Do you need to chain even more in Simutrans to achieve the ability of an express to pass the local? I'd say no, so why have a priority signal with infinite chaining and a name that will create confusion?
Instead implement multi aspect signalling taken from real life signalling examples.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #60 on: August 16, 2018, 09:17:34 PM »
To make it clear: Everything I have against this proposed signal is something I have against pre-signals. (Not that strange, since the signals are almost identical in operation.) I do use pre-signals, even if sparingly. And I might find use for this signal as well, although perhaps not in the way gauthier envisions it used. Of the proposals, I like gauthier's best. I would have preferred the distant signal solution for my style of play, if Simutrans supported combining signals, but it doesn't.

Offline ezosresyek

  • *
  • Posts: 3
Re: Priority signals
« Reply #61 on: August 17, 2018, 11:48:27 AM »
How would the priority signal handle the case where a number of trains travelling closely in the same direction on a mainline all require priority over a train attempting to join the mainline?

What I mean is the following sequence of events:
  • Train 1 travels on a mainline, passes the first of several priority signals and thus reserves a number of blocks. This prevents trains departing from a station next to the mainline from pulling out immediately in front of Train 1.
  • Train 2 has reached its loading target and leaves the station. On attempting to join the mainline it finds this blocked by Train 1’s reservation through the priority signals. Train 2 waits for Train 1 to pass.
  • On the mainline, Train 1 is followed closely by Train 3, close enough that Train 3 has passed the initial priority signal by the time Train 1 clears the station exit junction. If Train 3 was absent, Train 2 would now be able to join the mainline behind Train 1.

What happens next? Ideally Train 3 would also be allowed to continue before Train 2 joins the mainline. Does this happen? Or would Train 2 now get priority over Train 3 as it was the first of these two trains to attempt to enter the junction?

Also, perhaps “Reservation Signal” could be a naming option?

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #62 on: August 17, 2018, 04:57:30 PM »
@Turfit

Quote
you apparently can't read my mind...
In fact, I focused on the first and the last paragraphs of your answer and did not pay enough attention to what was in the middle. Sorry about that.

I'm opened to any nice and elegant solution for the express/local problem. Using minimum charge/waiting time is not a good solution as already explained in this thread. At this point, the game does not provide a good solution so we have to create it. Here is my way of approaching this problem. I don't pretend to be entirely right on this so, if I missed something, please tell me.

In reality, express trains overtake local trains using a timetable when everything goes well. Implementing timetables in Standard would be a far bigger work than this signal.

The core problem here is that a train that just stopped or is going to stop somewhere forces another train at full speed to stop at a place it should not. To avoid this, we can double the tracks on the whole length of the line: that is costly, there may be not enough space for it, and the service density may not justify to have a completely doubled way. For these reasons, we want to make overtaking ways only at stations.

At this point, the problem is now: prevent the local train to reserve the tracks merging if an express train is too close, so as not to make it stop. We can either act on the local train or on the express train.

Make the local train know about the upcoming express to prevent it from reserving the critical tracks ? There's currently no mechanism in the game to do that so you would end up with a heavy patch and a totaly new feature to explain to players.

Make the express train directly prevent the local one from reserving the critical tracks ? The only lightweight manner of doing this is to reserve the tracks sooner if possible. Otherwise the express train needs another mean of telling the local one "stoooooop !". Once again, there's nothing currently implemented to achieve that.

This leads us to a problem of allowing a train to reserve blocks in advance. The only current signal able to reserve more than one block is the presignal, but it doesn't work as expected in this situation. The most simple solution I came up with, regarding code complexity and usability, is the priority signal.

Quote
Simutrans existing 'normal' signals have two aspects, red and green, proving two indications, stop - next block occupied, proceed - next block free.
If in a sequence of these signals you add the proposed priority signal, you've effectively created a 3 aspect signal - red, yellow, and green per typical color light signals, with indications of stop - next block occupied, proceed - next block free - expect stop at next signal, and proceed - next 2 blocks free.
Chain in one more priority signal and you're still in the realm of easily finding examples of this behaviour in real signalling - a 4 aspect signal. The added aspect is probably less universal between countries than the red/yellow/green, but flashing yellow is common. Continuing to spell it out - aspects of red, yellow, flashing yellow, and green indicating stop - next block occupied, proceed - next two blocks free - expect stop in 2 signals, proceed - next block free - expect stop at next signal, and proceed - next 3 blocks free.
Chain in one more - 5 aspects. Probably can't find this common from real life - I think the British had this for a while as a flashing green aspect for 4 block free indication. Not going to spell all these out as I hope the point is made...

Do you need to chain even more in Simutrans to achieve the ability of an express to pass the local? I'd say no, so why have a priority signal with infinite chaining and a name that will create confusion?
Instead implement multi aspect signalling taken from real life signalling examples.
So, instead of implementing one signal with a simple behaviour that players can use in a wide set of manners, you suggest implementing two or three more signals, to use in a strict manner. Yet these signals would be individually a little easier to understand and more reality-like than the priority signal.

Between having one signal in my toolbar to make everything and three buttons to make three things, I prefer the one-button solution.
Quote
And I might find use for this signal as well, although perhaps not in the way gauthier envisions it used.
I'm curious about other uses priority signals could have, could you explain it ?

Quote
What happens next? Ideally Train 3 would also be allowed to continue before Train 2 joins the mainline. Does this happen? Or would Train 2 now get priority over Train 3 as it was the first of these two trains to attempt to enter the junction?
Train 2 is already waiting at its signal so it's likely to be allowed on the mainline unless Train 3 triggers the priority signal at the very precise game tick when Train 1 leaves the critical block.It would be very unlikely to have a local train stuck at its station in case of too dense service, if that's your concern.
"Reservation signal" may be even more confusing as most signals actually reserves tracks.


Offline Leartin

  • Devotee
  • *
  • Posts: 1108
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #63 on: August 20, 2018, 06:25:14 AM »
Train 2 is already waiting at its signal so it's likely to be allowed on the mainline unless Train 3 triggers the priority signal at the very precise game tick when Train 1 leaves the critical block.It would be very unlikely to have a local train stuck at its station in case of too dense service, if that's your concern.
But from a players perspective, wouldn't a different behaviour make more sense? You want fast trains to be able to pass slow trains. Train 3 is a fast train, Train 2 is a slow train. Expectation might be that Train 3 actually has priority. To do that, rather than just reserving if it's free, the priority signal would need to call dibs on a block. (I'll use "dibs" since I don't know a better word)
If a train called dibs on a block, after the train currently in it left, it will still appear to be reserved for all other trains, but free for a train that called dibs on it. So if a train reaches the signal or gets checked while standing there, it can enter, while others who did not have a priority signal can not. This way, there also is an actual priority, so you can call it priority signal.
In the backend, "is_priority" can be combined with either "is_signal" or "is_presignal". If combined with "is_signal", it will only attempt to reserve, and if it can't, call dibs on the next block. If combined with "is_presignal", it will attempt to reserve the next two or, if more identical signals are next, more blocks, and the next it can't reserve, it calls dibs on.
Note that multiple trains may call dibs on the same block, since they are not aware if another train called dibs.

Offline ezosresyek

  • *
  • Posts: 3
Re: Priority signals
« Reply #64 on: August 20, 2018, 10:15:42 AM »
But from a players perspective, wouldn't a different behaviour make more sense? You want fast trains to be able to pass slow trains. Train 3 is a fast train, Train 2 is a slow train. Expectation might be that Train 3 actually has priority. To do that, rather than just reserving if it's free, the priority signal would need to call dibs on a block. (I'll use "dibs" since I don't know a better word)
If a train called dibs on a block, after the train currently in it left, it will still appear to be reserved for all other trains, but free for a train that called dibs on it. So if a train reaches the signal or gets checked while standing there, it can enter, while others who did not have a priority signal can not. This way, there also is an actual priority, so you can call it priority signal.

This describes what I had in mind. For my personal playstyle it would be preferable to have a departing train 'stuck' on the side while anything approaching on the mainline is allowed to pass, until there is a sufficiently large gap between the passing trains. This should increase the capacity of the line, as there would only be one train waiting that hadn't even gained speed yet, as opposed to the current situation where several trains at speed my have to stop and wait for the departing train. I've never looked at Simutrans code so I have no idea if this would be challenging to implement in addition to the work gauthier has already done.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #65 on: August 20, 2018, 02:03:47 PM »
Both of the last two ideas seem much more complicated than gauthier's proposal, as they require changes to the data structures describing the game world state. Vehicles in Simutrans are generally oblivious to each other, beyond checking if the tile they want to enter is occupied or not. The sole exception is probably overtaking for road vehicles, although I do not know exactly how it works. They can always abort if the miscalculate.

Offline gauthier

  • Devotee
  • *
  • Posts: 3628
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #66 on: August 20, 2018, 05:11:49 PM »
Having sort of a queue on signal reservation allowing to order passage of trains attempting to reserve it would be a good idea but not necessarily bound to what I'm proposing here.
The behaviour described here could lead to a train completely stuck in its station in case of saturated line. In a such case, player should not use priority signal but simply double his tracks. Priority signal is designed for situations where traffic is not dense enough to justify doubling the tracks. Moreover, in the situation described with train 1, 2, 3, and in all too-dense traffic situations alike, train 3 is likely to have already stopped or slowed down after Train 1 as it is too close.

Offline Leartin

  • Devotee
  • *
  • Posts: 1108
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #67 on: August 21, 2018, 08:09:35 AM »
The behaviour described here could lead to a train completely stuck in its station in case of saturated line.
That would only be possible if it is the only train serving that particular station, otherwise it could at least exit as soon as the next train tries to enter that station. But even if it does indeed get stuck, that's perfectly fine. A stuck train would cause a notification to the player, and the situation is rather easy to understand. Until that is the case, instead of lowering the throughput of all faster lines, only that one slower line is affected, which again is a reasonable result.
On the other hand, if your signal is used, you are pretty much where you started, with a fast train bumping into the rear of a slow train, the very situation you intended to avoid - except since nothing is stuck, there will never be a notification, and the player would have to see the problem by chance.
In a such case, player should not use priority signal but simply double his tracks.
If the track is oversaturated, yes. If it just so happens that two fast trains are near each other through happenstance, no. (And if there are two fast trains that serve different lines, so they have two different cycles, they will inevitable be close to each other at some point, it does not matter how saturated the tracks are)
Moreover, in the situation described with train 1, 2, 3, and in all too-dense traffic situations alike, train 3 is likely to have already stopped or slowed down after Train 1 as it is too close.
Train 3 and Train 1 are of the same speed. The only reason Train 3 could ever get that close to Train 1 is if Train 1 was slowed down before, eg. because of the slower Train 2 - even more reason Train 3 should overtake as well.

Vehicles in Simutrans are generally oblivious to each other, beyond checking if the tile they want to enter is occupied or not.
My proposal does not touch that idea. Blocks/tiles can be reserved or not. Add an additional bit, they can be 'dibbed' or not. If they are neither, (00), they are free. If they are either reserved, dibbed or both (01,10,11) they are not free and can't be reserved at a normal signal.
At a normal signal, if the next block is free, it becomes reserved (00 -> 10).
At a priority signal, if the next block is reserved but not dibbed, it becomes dibbed (10 -> 11). If it is dibbed but not reserved, it becomes reserved but no longer dibbed. (01->10). If it's free, it becomes reserved without dibbing (00->10)
Hence once a train reaches a priority signal, until it actually reserves the next block, normal signals will always consider the block to be occupied.
This would be a slightly alteration to the previous version without dedicated priority-pre-signals. Instead, use gauthiers "recursion" signal: "Reserve the next block. Then, attempt to do the next signal." That next signal happens to be a priority signal, so the switch will be dibbed as soon as the recursion signal is reached. Unless there is another priority signal, it will stay that way until the train reaches that priority signal and changes the dibs into reservation.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5419
  • Languages: EN, NO
Re: Priority signals
« Reply #68 on: August 21, 2018, 08:45:06 AM »
Add an additional bit, they can be 'dibbed' or not.
I count that as an additional data structure. I haven't even checked if there is room for such a bit anywhere.

Offline Leartin

  • Devotee
  • *
  • Posts: 1108
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #69 on: August 21, 2018, 10:54:08 AM »
I count that as an additional data structure. I haven't even checked if there is room for such a bit anywhere.
I wouldn't even know enough about how it works internally to make any claim about that, even my example was only to show intention, not how it would actually work. But since you mentioned vehicles not keeping track of each other, I wanted to show that this part would not change, since I could think of other solutions where that would not be the case (eg. yield-sign logic)