The International Simutrans Forum

Development => Patches & Projects => Incorporated Patches and Solved Bug Reports => Topic started by: gauthier on August 03, 2018, 07:21:30 PM

Title: Priority signals
Post by: gauthier on August 03, 2018, 07:21:30 PM
Code here: https://gitlab.com/empounet/simutrans/tree/priority_signal (https://gitlab.com/empounet/simutrans/tree/priority_signal)

(clone https://gitlab.com/empounet/simutrans.git  and checkout branch "priority_signal")


Linux x64 binary: http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:simlinux64.zip (http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:simlinux64.zip)

(if someone wants to make windows or mac binaries and share it: please do it ;) )
Pak128 test addon (same looking as presignal for now): http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:priority_signals.pak (http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:priority_signals.pak)
Pak128 test savegame: http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:priority_signal_tst.sve (http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:priority_signal_tst.sve)
@Simutrans team: I didn't touch version numbers of Simutrans or Makeobj as I don't know your prefered policy about them.


What the ... ?
Priority signals are basically presignals which let convoy pass as long as the first reservation is successful (or, if you prefer, even if the recursive reservation is unsuccessful).
Presignal:
_ Try to reserve until next signal
_ Try to reserve next signal whatever its type
_ If both are okay: let convoy pass

Priority signal:
_ Try to reserve until next signal
_ If only this first step is okay: let convoy pass
_ Immediately try to reserve next signal whatever its type

That means that a convoy arriving through priority signals can reserve blocks in advance but won't be stopped if it cannot reserve them whereas convoys arriving by another way without these signals cannot reserve a block in advance (normal signals) or will be stopped far before the critical area if they cannot (presignal). The first convoy has priority, hence this signal's name.




Why ?If you ever tried having omnibus and direct trains on a single way, having overtaking ways at stations so as direct trains could overtake omnibus ones stopped on the other way; you know it barely works one time on ten unless you got the very perfect layout in which case it works about half of the time. Using priority signals, direct trains have chance to overtake omnibus trains while they are stopped by reserving in advance the block juste after the station, and even if they fail to reserve this critical block they still have one more blocks to go on so they don't get brutally stopped and lose their speed.



How ?To make a priority signal, use makeobj compiled with the code I shared, use the dat parameter "is_prioritysignal=1".




Compatibility ?With older savegames, with older signal paks: no issue. That's thanks to good coding regarding pak format versions  :thumbsup:




(http://simutrans.fr/lib/exe/fetch.php?media=prioritysignal:priority_signal_screen.jpg)
Title: Re: Priority signals
Post by: prissi on August 04, 2018, 04:35:26 PM
This will lead to deadlocks if used as real pre-signals. Also Simutrans has quite many signal types and some user already complained on that. Thus I think those are rather better suited for extended.
Title: Re: Priority signals
Post by: gauthier on August 04, 2018, 07:06:28 PM
QuoteThis will lead to deadlocks if used as real pre-signals.
... yes ... that's why you don't use them as real presignals.
QuoteAlso Simutrans has quite many signal types and some user already complained on that.
What's the complain about ? Beginners don't have to use all the complicated signals to get into the game, normal signals are okay for basic networks.
QuoteThus I think those are rather better for extended.
What makes you decide what is for extended and what is for standard ? (No rhetorics here, this is a real question).
Title: Re: Priority signals
Post by: Ters on August 04, 2018, 09:05:03 PM
I don't see how this type of signal can cause any more deadlocks than the signals we already have. The regular signal placed with a single click is basically guaranteed to deadlock if there is more than one train running on that track, unless there are some other signals cleverly set up to tame it. (I've only ever found use for it as a substitute for the lacking single-sided signals.) Not to mention that pre-signals in Simutrans are not pre-signals, so using a Simutrans pre-signal as a pre-signal is not a good idea either. That a signal can cause deadlocks if used wrong is an argument that rules out all signals in Simutrans.

Although I have been toying with the idea of a signal like this, I am not entirely convinced about how useful it really is. That might have something to do with my way of playing not giving the slower train a reason to pull to to the side in the first place, except by excessive waypoint plotting that will cause the train to pull to the side when it doesn't have to. Going to the side when it wasn't a hindrance for any faster train causes it to slow down more, meaning that trains that otherwise would not, catch up to it.

Quote from: gauthier on August 04, 2018, 07:06:28 PM
What makes you decide what is for extended and what is for standard ? (No rhetorics here, this is a real question).
The use of "I think" indicates that prissi was simply stating his opinion on the matter, not making a verdict. Although prissi's opinions probably weighs a lot for standard, whether prissi likes it or not.
Title: Re: Priority signals
Post by: prissi on August 04, 2018, 10:18:34 PM
To this signal: In practice this will be almost equivalent to dense signals, only that the passing will be one station further (when the pasing train is right behind). This will in effect lead to a higher capacity of the whole track (the price is a sightly lower speed of your express convoi). Since the actual speed is not an issue in standard, this signal would not improve the transportation simulation part.

Moreover, such a slow convoi is probably not very profitable because of the speedbonus. (And for freight this is not an issue, since train tend to wait for full load for quite some time).

I have also the savegames of many networkgames. I exactly none I saw something like this used for passengers without waiting for loading. In none of these game such a signal would have been useful. (One can of course argue, that these thing would not have been built with such a signal, but siding stations have been built, just wil waiting for load.)

But of course I would like to hear more options. Indeed, this needs more discussion, i.e. the direction where standard is going. Imho Extended is heavily focussed on trains, with all its (sometimes very british only) signalling options. I personally would see standard as simple but complex in terms of avoiding overcrowding etc.

Extended is getting more like OpenTTD with all dignalling options and the strong focus on traisn (at least codewise).

And if you look in other transportation forums, you will often find that either Simutrans signals are to complicated (especially choose signals) or lacking. So it seems one can never satisfy both sides. But assuming that usually the disappointed player post less than the pros, I tend to be more worried about the ones which are turned away by whatever complexity.
Title: Re: Priority signals
Post by: Ters on August 04, 2018, 11:38:42 PM
Quote from: prissi on August 04, 2018, 10:18:34 PMMoreover, such a slow convoi is probably not very profitable because of the speedbonus.
In gauthier's example, the non-express is the same vehicle with the same speed and the same speed bonus. It just stops more often.
In my example, one is a freight train and the other is a passenger train, so the speed bonus affects them differently.

Quote from: prissi on August 04, 2018, 10:18:34 PMAnd if you look in other transportation forums, you will often find that either Simutrans signals are to complicated (especially choose signals) or lacking.
I think it is the same "problem" that causes both. Signals in Simutrans are complicated because they are very dumb. They do not coordinate or plan ahead like real life train control. So some players eventually try to make lots of complicated things to compensate, which requires a variety of different signal behaviors to get right.
Title: Re: Priority signals
Post by: gauthier on August 05, 2018, 10:44:00 AM
QuoteI exactly none I saw something like this used for passengers without waiting for loading. In none of these game such a signal would have been useful. (One can of course argue, that these thing would not have been built with such a signal, but siding stations have been built, just wil waiting for load.)
It's not useful in current savegames cause making express/omnibus lines fail most of the time without the priority signal, this signal is precisely here to allow for such layouts.

If I understood you well, your last point here is to use waiting times. Adding a waiting time to omnibus trains at each station is not equivalent to using priority signals, if the train is full it won't wait. Even if it waits, let's say the express train is at some distance behind. If the omnibus did not wait, it would have departed early enough not to make the express stop. Same with priority signals, the express train being distant enough not to reserve the tracks. But, since the omnibus waited, the express reduced its distance but not enough to overtake and had to stop just before the station.

QuoteBut of course I would like to hear more options. Indeed, this needs more discussion, i.e. the direction where standard is going. Imho Extended is heavily focussed on trains, with all its (sometimes very british only) signalling options. I personally would see standard as simple but complex in terms of avoiding overcrowding etc.
I agree with you that standard must not take the same direction as extended in terms of game complexity. In my opinion, a good game is a game able to create many different situations with a narrow set of simple rules.

Despite this point of view, I still feel the need for a mechanism allowing to mix high speed trains and slower trains without having to completely separate ways. Such situation is common in reality networks. The situations where it happens are express/omnibus mixes but also lettin a little slower train use part of a high speed line which is not too crowded already. This happens for instance in western France where a regional train partly uses TGV tracks.

Finally, as I still want to keep Standard's mechanisms simple, I though that derivating a signal from the already well known presignal would be a nice and elegant way of making a priority signal.

I'm not planning to propose other signals, the signals that we have already allow many possible layouts and I'm happy with them.

QuoteBut assuming that usually the disappointed player post less than the pros, I tend to be more worried about the ones which are turned away by whatever complexity.
You are right. It's partly a matter of how much complexity do we want in the game and, imho, mostly a matter of communication to beginners. This has always been a problem in Simutrans. I remember when I started playing the game, I sticked to it only because, by chance, the place where I downloaded the game also provided an example savegame I used to understand the game. That's why Yona is making an excellent tutorial scenario for pak128. I think tutorials are the key, at least to ensure that beginners really understand the game before deciding if they like it or not.

QuoteI think it is the same "problem" that causes both. Signals in Simutrans are complicated because they are very dumb. They do not coordinate or plan ahead like real life train control. So some players eventually try to make lots of complicated things to compensate, which requires a variety of different signal behaviors to get right.
I partly agree with this point. Back when I started playing, there was only one type of signal in pak128, which was placed not on tiles but between tiles (waaaaaaaaaaay more useful in complicated layouts, especially close to stations) and the logic was a strict block reservation, just like in reality, and that's still the most intuitive way of running that comes to a beginner mind. I get the impression that all our complicated signals, except for the choose signal, became necessary when strict block reservation disappeared.

After years of playing, I rather think it's a matter of choice. The current choice is nice too and I have no problem with it, except for the on-tile/between-tile thing that would help a lot in some situations.
Title: Re: Priority signals
Post by: Ters on August 05, 2018, 12:04:28 PM
I can't quite see how path reservation as opposed to block reservation dictates more signal types, except maybe the long-block signal, but I've never seen Simutrans' so called block system in action. The only difference should be that the block system reserves more tiles and keeps the reservation longer. The choose signal would be impossible with a block system the way I understand it. I guess this is why block reservation apparently was rarely used within stations in real life.

Signals in Simutrans are effectively between tiles, except that two-way signals are on either side of tile, rather than side-by-side. This avoids some deadlock situations, because otherwise, trains could end up front against front. The ribi-system is probably mostly to blame for how signals (and signs) can be positioned, not the signal logic itself.
Title: Re: Priority signals
Post by: Vladki on August 05, 2018, 04:57:03 PM
I would like to have such priority signal. I tried to do such layout using a mix of signals and presignals, and long and short distance between signals but it never worked perfectly.
Title: Re: Priority signals
Post by: gauthier on August 05, 2018, 07:00:48 PM
QuoteI can't quite see how path reservation as opposed to block reservation dictates more signal types, except maybe the long-block signal
Indeed, after more thinking, my point was far fetched.
QuoteI've never seen Simutrans' so called block system in action.
The first version of Simutrans I played was 84 I think. That's loooong ago  ;D
Title: Re: Priority signals
Post by: prissi on August 05, 2018, 10:47:56 PM
That block reservation was a nighmare (and a major eater of CPU power). Also it greatly reduced throughput, because things like simultaniously departueres from a station on different tracks were impossible.

Back to the overtake signal. If you have normal signals in 4 tile difference, the express trains could come until four tiles. Either then the slow train left and the express will take over at the next station, or the express trains reservers the the tile in front and the slow trains waits. The difference with the overtake signal is that it would delay the overtaking by one station, but the amount of slow trains would be higher. With the overtaking signals, the average waiting time would be higher. This means that throughput is lower. (Of course negleting acceleration; with either one or the other case could be better.)

Since the slow (more stops) trains have a higher chance at getting passengers/delivering passengers, these should make more money. So economically such an overtaking signal would not make sense, because it may even reduces throughput.

Also this signal goes a little at the idea of a mostly deterministic Simutrans, which both Hajo and me had. The choose signal was a deviation introduced by peer pressure.

Nevertheless, I am back from vacation after the 15th, and will test this one thoruroughly. I am pretty sure I will not add this signal to pak64, but may add it to the source.
Title: Re: Priority signals
Post by: Ters on August 06, 2018, 05:56:37 AM
Sometimes I wish I could take parts of Simutrans and put it through its paces in a controlled and monitored environment. (Strictly speaking, I can, but it is not easy.) In this case, just running the logic of some trains with explicitly given starting conditions on identical tracks and stations with identical passenger numbers, with and without this signal, and counting the throughput automatically. It wouldn't need a GUI and could run at unlimited speed.

I agree that overall throughput will possibly go down. This signal will however increase throughput on one line. Since Simutrans doesn't handle the difference between local and express routes very well, prioritizing the latter over the former probably doesn't make much sense logistically, but rather as something that looks and feels right. Prioritizing a fast passenger train over a slow freight train might make sense, but the problem there is that it is the train that is not stopping according to its schedule that should stop to let the other train pass. Certain fright trains can have more than enough capacity to maintain sufficient throughput even if it has to yield all the time.
Title: Re: Priority signals
Post by: THLeaderH on August 06, 2018, 09:51:59 AM
I think Japanese players loves this feature. Priority signal improves the possibility of overtaking while it does not sacrifice the railway capacity, that is different from a presignal. I agree that we should have more discussion to avoid making simutrans needlessly more complicated.

The priority signal is very similar to a presignal. In my opinion, priority signal should not be defined in a dat file, but in a GUI option window like the attached image. Players can immediately use this awesome feature without introducing any new add-on.

By the way, OTRP (https://github.com/teamhimeh/simutrans/blob/OTRP-distribute/documentation/OTRP_information_en.md) is ready to take this patch. I believe many Japanese players will be excited to use this priority signal. If it is difficult to incorporate this patch into the standard, and if you are willing to do so, please let me know.
Title: Re: Priority signals
Post by: Vladki on August 06, 2018, 05:55:33 PM
I do not like the idea of changing the behavior of signal in gui. Priority signals should be a new object.

What about making them as true distant signals. I mean that they would not be a block boundaries. The reservations would go through them, up to the next signal. They would just try to extend the reservation when the train is passing them. Thus they would behave more as a sign than signal.
Title: Re: Priority signals
Post by: gauthier on August 06, 2018, 07:57:38 PM
QuoteThe difference with the overtake signal is that it would delay the overtaking by one station, but the amount of slow trains would be higher. With the overtaking signals, the average waiting time would be higher.
What actually happens when an express train gets close to a slower one is that it stops or at least drastically looses speed. Then you are nearly always in this situation: as the express deccelerated a lot, or even stopped, it is now far away from the slower one. When the slower one stops on the side platform, the express cannot make the distance fast enough to overtake. As it arrives at the station, the slower one has already restarted.

The only situation where the express manages to overtake is when it came close to the slower one just before the station, not too close so it has not to stop or slow down to 50 kmph, not too far so it has time to enter the station before the slower one restarts. In fact, this happens about 10% of the time on average, at max half of the time if your layout and your train's performances are perfectly adjusted (by chance, not by yourself).

If it's not obvious to you, please take a little time to try a such layout by yourself.

QuoteThis means that throughput is lower. (Of course negleting acceleration; with either one or the other case could be better.)
When trains, at least a part of them, don't have to make 0 kmph to 200 kmph or more, several times per journey, the throughput is much higher. Even without the priority signals, I can significantly increase the throuput of my most busy lines by preventing some trains to stop at small stations even if they still share the tracks with local trains. The time taken to slow down, stop, restart and regain speed is significant.

QuoteSince the slow (more stops) trains have a higher chance at getting passengers/delivering passengers, these should make more money.
When you make an express/local layout, it's often to have the express serving the most crowded stations and skipping the small towns. When I make such a layout, I have about half trains being express, half trains begin local. Express having a slightly (greatly with priority signals) higher throughput, that means that they actually transport more than half of the passengers.

QuoteAlso this signal goes a little at the idea of a mostly deterministic Simutrans, which both Hajo and me had.
Could you develop what you mean by deterministic Simutrans ?

QuoteThe priority signal is very similar to a presignal. In my opinion, priority signal should not be defined in a dat file, but in a GUI option window like the attached image. Players can immediately use this awesome feature without introducing any new add-on.
From a player point of view, clicking once on a different icon in the toolbar is much friendlier than opening a dialog, probably with ctrl+click (that beginners don't even know about btw), and clicking on a tickbox. Moreover it's not natural for standard players to change the behaviour of an object according to a metadata setting of this object.
Adding one icon in a place where we expect it is, in my opinion, more appropriate. Signals are also one of the easiest object to draw and make, so making it as an addon shouldn't be so long for pak maintainers or addon makers.

QuoteWhat about making them as true distant signals. I mean that they would not be a block boundaries. The reservations would go through them, up to the next signal. They would just try to extend the reservation when the train is passing them. Thus they would behave more as a sign than signal.
If I'm understanding this well, that means that player would still have normal signals but also has to add priority "signs" between signals ? That doesn't sound player-friendly, and such a behaviour would break the recursion (the ability to have several consecutive priority signals).
Title: Re: Priority signals
Post by: Ters on August 07, 2018, 05:33:47 AM
Quote from: gauthier on August 06, 2018, 07:57:38 PMWhen you make an express/local layout, it's often to have the express serving the most crowded stations and skipping the small towns. When I make such a layout, I have about half trains being express, half trains begin local. Express having a slightly (greatly with priority signals) higher throughput, that means that they actually transport more than half of the passengers.
Whenever I try that, it always seems like the local trains get all the passengers, while the express trains run nearly empty (or at least not full enough to make a profit). That may be tied to my general inability to properly balance trains serving more than two stations, especially major ones, although others have reported similar problems.

Quote from: gauthier on August 06, 2018, 07:57:38 PMIf I'm understanding this well, that means that player would still have normal signals but also has to add priority "signs" between signals ? That doesn't sound player-friendly, and such a behaviour would break the recursion (the ability to have several consecutive priority signals).
It took my a while to try and wrap my head around this, but in the end, I could only find minor differences. (The following example is relative to the normal/home signal right before the station in the images from the first post.) Valdki's distant signals would let you fine tune when the upcoming block (through the station) should be reserved, from the tile just after the previous home signal until the tile just prior to the home signal (although at that point, Simutrans has already started attempting to reserve the next block). gauthier's priority signal is basically Vladki's distant signal on the same tile as the previous home signal. On the other hand, having to use two separate signals could be problem if there are lots of junctions, crossings and perhaps signs between the two stop/home signals (plus at least one more thing I have problems explaining).
Title: Re: Priority signals
Post by: Leartin on August 07, 2018, 12:35:13 PM
Quote from: prissi on August 05, 2018, 10:47:56 PMAlso this signal goes a little at the idea of a mostly deterministic Simutrans, which both Hajo and me had. The choose signal was a deviation introduced by peer pressure.

I'd like to talk about this idea of a deterministic Transportation Simulation, since I think that could be a neat game - but it's not what Simutrans is at the moment.
First, let's define what we are even talking about. Strictly speaking, both the choose signal and the priority signal would be deterministic, since the outcome is always the same if the starting condition is the same. Think of Amidakuji - completely deterministic, yet perceived random. So rather than deterministic, let's say (humanly) predictable.

Say we want a predictable game. That means we would not want too many features that influence the game outside of the players control. Instead, we would want to allow the player to build something, do a test run, and if it does not fail within ~10 cycles, the player would know it's a stable connection that won't fail them unless they mess it up themself. That could work if everything was based on schedules on the same cycle (eg. weekly or monthly), and wouldn't require advanced signals.
Why a common cycle with a schedule? In the current Simutrans environment, there are no schedules. The typical coal line with no other line intersecting it would still run on a cycle though, based on how long the track is. This one line will repeat exactly the same thing over and over. If another line would intersect with it, but be on the same cycle since the line is magically exactly the same length, trains would never meet at the intersection at all if they did not the first time. however, if their cycles have a different length, say, 50 and 51 units, they will inevitaby meet at some point, one of them has to wait and it offsets the whole cycle. It does not matter much in this scenario, but the very same principle leads to trains arriving at a station at the same time, potentially causing deadlocks. The more complex the map becomes, the more often those things happen. Resolving it when it happens is undesired micromanagement.
If you knew when which train arrives at which station, you could plan for which platform they should take, completely predictable behaviour. But since any train could arrive at any time in relation to each other train, you need a different solution. A Choose signal is not a deviation from the otherwise predictable game, rather, because there are some design flaws that make the game unpredictable, people needed a tool that mitigates the effect.
Likewise, if you knew which trains would meet at a certain switch, you could preemptively decide which should wait and which should go. But because it isn't predictable, there is a need for tools that help with it, like the proposed priority signal.
Trains are affected by other trains. Other trains can block the way, Other trains can block the platform, Other trains deliver whatever this train is supposed to carry on.
Unless you can control all trains in such a way that their interactions are predictable (as with a unified schedule) there need to be tools for responsive, conditional behaviour such that situations can be resolved locally. Or make all trains ghosts which can move through each other without interaction.
Title: Re: Priority signals
Post by: gauthier on August 07, 2018, 04:52:17 PM
QuoteWhenever I try that, it always seems like the local trains get all the passengers, while the express trains run nearly empty (or at least not full enough to make a profit). That may be tied to my general inability to properly balance trains serving more than two stations, especially major ones, although others have reported similar problems.
Use minimum load so the passengers going to the next express-served station will always go in the express, letting the local trains to "local" destinations.

Quotegauthier's priority signal is basically Vladki's distant signal on the same tile as the previous home signal.
I disagree, distant signal cannot have recursion. The signal after the distant sign could be a presignal of course, but we would get back all the disagreement of trying to use presignals instead of priority signals.
Title: Re: Priority signals
Post by: Ters on August 07, 2018, 07:44:56 PM
Quote from: gauthier on August 07, 2018, 04:52:17 PM
Use minimum load so the passengers going to the next express-served station will always go in the express, letting the local trains to "local" destinations.
There are no platforms to spare. I can't get the trains to leave the platform soon enough as it is.

Quote from: gauthier on August 07, 2018, 04:52:17 PM
I disagree, distant signal cannot have recursion. The signal after the distant sign could be a presignal of course, but we would get back all the disagreement of trying to use presignals instead of priority signals.
Recursion, unless I have no idea what you are talking about, is a side effect of putting the distant signal on the same tile as the previous normal signal. Of course, since two signals on the same tile is impossible in Simutrans today, their equality in this situation is just theoretical. One should however be able to mostly get the same effect with a distant signal immediately after the previous normal signal. It is an odd thing to do, though. Distant signals would in my opinion look best on the same post as the previous signal, as is how priority and arguably pre-signals work (Simutrans pre-signals just lack the ability to show the proceed & caution aspect, while the priority can), or when placed closer to the signal it is distant for than the preceding signal.
Title: Re: Priority signals
Post by: prissi on August 07, 2018, 08:33:00 PM
The "pre-singals" can show "caution/slow speed", when the next section is free but not the next next one. However, this really happens rarely. For showing such aspects more often, that passing signal woudl be nice.

However, one would need a visually very different signal to make sure the pre-signal and the distant signal are not confused. This becomes very challenging in pak64 ...
Title: Re: Priority signals
Post by: Ters on August 08, 2018, 05:58:17 AM
Quote from: prissi on August 07, 2018, 08:33:00 PM
The "pre-singals" can show "caution/slow speed", when the next section is free but not the next next one.

Yes they show it visually, but it doesn't mean anything to the trains. They stop just as if it showed "stop". In effect, they are similar to the Norwegian "repeater signal", a signal placed at the end of platforms when the station exit signal can not be seen from there, although they look almost nothing like them. However, the only use I have found for them in Simutrans is to mask the presence of the following signal for those trains passing through the pre-signal. I have only found that useful, but very useful, when I want a signal at the exit of a single-tracked siding (and a few similar situations), but not at the entrance. A concept of single-sided signals would completely remove the pre-signal's usefulness in Simutrans as far as I can tell.

The fact that the "priority" signals allow trains to proceed in two out of three aspects put it in a completely different niche. They are effectively the Hp/Vr combination the pak64 semaphore pre-signal looks like (difficult to find images of the semaphore combination), and the Ks signal I guess the electric one kind of looks like, except for the breaking distance thing. This of course means that artists will have a hard time making a visual distinction between pre-signals and priority signals, while also making them relatable to player who know something about railway signaling.
Title: Re: Priority signals
Post by: gauthier on August 08, 2018, 04:38:18 PM
QuoteRecursion, unless I have no idea what you are talking about, is a side effect of putting the distant signal on the same tile as the previous normal signal.
What I mean by "recursion" is when you place a presignal before a presignal, itself before a presignal, etc ... Of course this sounds stupid with presignals, with priority signals it's not that stupid: trains can reserve the critical pieces of tracks from far away while still being able to split this far away into several blocks which would be useful in other situations.
You can see this recursion in action in the screenshot of the first post.
Title: Re: Priority signals
Post by: Ters on August 08, 2018, 05:11:42 PM
In that case, Vladki's distant signals, as I understand them, will do the same. It just disconnects the how far away from the length of the block, at the cost of not letting it be equal to the length of the block (as long as Simutrans won't allow combination of signals on one tile).


Here is an attempt at illustrating:



>-P------1------P------2------P------3------S->
  ^             ^             ^
  |             |             Block 3'&4* reserved here
  |             Block 2'&3* reserved here
  Block 1'&2* reserved here



>-S--D---1------S--D---2------S--D---3------S->
  ^  ^          ^  ^          ^  ^
  |  |          |  |          |  Block 4 is attempted reserved here*
  |  |          |  |          Block 3 reserved here'
  |  |          |  Block 3 attempted reserved here*
  |  |          Block 2 reserved here'
  |  Block 2 attempted reserved here*
  Block 1 reserved here' 
P Priority signal
D Distant signal
S Normal signal
> Direction of travel (all signals face correspondingly)
' Train will stop if reservation fails
* Train will still continue if reservation fails
Title: Re: Priority signals
Post by: Vladki on August 08, 2018, 07:41:29 PM
Yep, the second diagram is exactly what I meant.
Title: Re: Priority signals
Post by: sebastien on August 09, 2018, 10:05:46 AM
Recursion was not applied on the priority signals. If you look at Gauthier's screenshot, it should work like this:



>-P------1------P------2------P------3------S->
  ^             ^             ^
  |             |             Block 3'&4* reserved here
  |             Block 2'&3*&4* reserved here
  Block 1'&2*&3*&4* reserved here

Title: Re: Priority signals
Post by: Ters on August 09, 2018, 04:41:44 PM
Quote from: sebastien on August 09, 2018, 10:05:46 AM
Recursion was not applied on the priority signals. If you look at Gauthier's screenshot, it should work like this:
If that is how it work, my enthusiasm drops, because you can easily create a massive chain by accident. It should only reserve up to two blocks at a time. That should be enough to solve the problem in the screenshot.
Title: Re: Priority signals
Post by: gauthier on August 09, 2018, 05:26:32 PM
Same "accident" can already happen with presignals and, unless you're incredibly clumsy, I doubt it ever happened to you. Imho it's necessary to adjust how early you want your express trains to try reserving the critical block. Anyway, nothing forces you to use more than one or two priority signals at a time, so this feature won't be a problem for you.
Title: Re: Priority signals
Post by: Ters on August 09, 2018, 06:26:19 PM
Well then pre-signals are even more confusing and idiotic than I thought! Just like the choose signal reserving all the way to the next stop even if there are umpteen other signals in between, which was confusing the **** out of players. That was changed, wasn't it, so that it stops at the next signal? I guess choose signals are more tempting to new users than pre-signals.

At least there is something to call the pre-signals that are less confusing: infinite block signals.
Title: Re: Priority signals
Post by: gauthier on August 09, 2018, 07:59:53 PM
Presignal are not often strictly necessary although when they are, they also are of a great help. However I have never had to use them in a recursive manner. I think they work this way mostly to have a simpler code. The reservation method for presignal (and the one of the priority signal too, as this latter is only a slight change from the former) basically reserves the block just after it and call the reservation method of the next signal. If the next signal is a presignal, then this one will call the method for its own next signal, and so on. This is useful because you can use presignal before a choose signal for instance (even if this seems not to work in every cases, probably a bug here).

I don't think this is a problem as it's still up to the player to use this feature or not. Regarding priority signals, this feature can be very useful. Without it, priority signals would be limited to one block in advance, that would be just not enough for high speed trains unless you have a very long block before the critical block. A very long block can cause systematic delays, thus reduce throughput.
Title: Re: Priority signals
Post by: prissi on August 09, 2018, 09:42:06 PM
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.)
Title: Re: Priority signals
Post by: Ters on August 10, 2018, 06:01:29 AM
Quote from: prissi on August 09, 2018, 09:42:06 PMA recursive reservation will have troubles if these signals are dragged. Then the entire stretch will be reserved.
That is my main concern. Now also with regards to pre-signals.

Quote from: prissi on August 09, 2018, 09:42:06 PMFor 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.)
They would likely go for an alternate approach because no one could guess that it was solvable using pre-signals. I don't think any real signal works that way, rail, road or otherwise. When merging two single-tracks, I usually do so at a passing loop anyway. That is still one of few (maybe it is just two) cases where I use pre-signals at all, but just one.


.┌S<───────┬S──
─┴───────>P┴S──
(the period is just because the space I wanted there gets eaten by the forum)


As for level crossings of single-tracked railways, I rule out pre-signals because I only want the one before the crossing to act as a pre-signal. The one facing the other direction should act like a normal one. So instead I instead place passing loops around such a crossing, which means normal signals will do. If passing loops are otherwise unnecessary, so is the complex signaling, because only one train runs on that track.

There seems to be some real-life signals that cover more than two blocks ahead, but they seem to stop at three. Strictly speaking, they are distant signals with aspects that allow them to also work as distant signal for the next distant signal. Being combinations of a regular signal and a extended distant signal on the same post, they work more similar to guthier's signal than Simutrans' pre-signals, and would be useless for prissi's example.
Title: Re: Priority signals
Post by: Leartin on August 10, 2018, 06:58:07 AM
Quote from: prissi on August 09, 2018, 09:42:06 PMA recursive reservation will have troubles if these signals are dragged. Then the entire stretch will be reserved.
Same troubles with pre-signals and choose signals. But couldn't that particular issue be solved by disabling dragging for those signals? Seems more sensible than not having a particular signal because it makes trouble if dragged.
Title: Re: Priority signals
Post by: prissi on August 11, 2018, 09:50:04 PM
But then again the capacity of a track will decrease, if there is just one signal prior to the station because at short distance the overtaking would not work (too short time) and at long distance following passing trains would need to keep a long distance. So one would need more of those signals, i.e. dragging. (I agree that dragging of the other dignal types IS useless.)

Title: Re: Priority signals
Post by: Leartin on August 13, 2018, 09:42:20 AM
Perhaps. It depends on how tight signals are laid out in the first place; if each "block" is longer than an average train, then it could work with just one priority signal.
But if you want to maximize throughput, chances are you play with signals every other tile with each train at each others tail, so you would need several recursive priority signals for the whole stretch parallel to the station, perhaps a few in front of it.

Which raises two questions:
1. Could it still be a "non-dragable" signal to avoid frustration in new players, even though those who know how to use it might want to use several in a row? In other words, if dragability prevents it from existing, would players prefer having a non-dragable priority signal over having no priority signal?

2. Can we prevent two-tile-blocks entirely? - Yes, this taps into a completely different area from what's previously discussed, but if there is a reasonable method to change this aspect of the game, perhaps the perspective on signals would change entirely, opening up the space for new signals?
What I'm thinking here is that those tight signals only make sense if trains are following each other on a 'monodirectional' track. What if we would allow each train on a monodirectional track to reserve all the track ahead of it until it hits another train, a signal, or a switch with more than one "incoming" tracks. (A non-monodirectional track would count as well, since trains could enter it on two sides). This could never cause a deadlock since all trains on that stretch would always go the same direction. Trains that go one after each other would have one tile distance, you could say they drive on sight. Once a train reaches a switch with more than one incoming track, that would act like a normal signal for reserving, so if a train reaches the switch it checks if the track ahead is already reserved, and if not, keep moving. If the new track is not monodirectional, it would reserve up to the next signal, but if it is, it will reserve as far as possible. If it reaches a signal, it will obey that signal, but it might act differently due to a monodirectional track. A normal signal would only act as a reservation stopper, but once the train reaches it it will not reserve to the next signal, but according to monotrack-rules. If it's a presignal, it would reserve up to the next signal, but not further if that signal is on a monotrack. If it's a choose signal, it would not take other trains on mono-track into consideration when choosing a platform, but reserve the platform. (since other trains on monodirectional track will have left by the time the choosing train will reach there, with no fear of a deadlock because of them. However, deadlocks are possible due to other reasons - only use it if you know what you do)

What would a system like this achieve? It would get rid of all signals that only exist to keep the distance between two trains, and make each system functional in avoiding deadlocks/guiding trains. "Normal" routes would work without signals at all, which could make the game much easier to understand for new players. Unless a pakset provides/a player builds such monodirectional tracks though, their mere existence in code does not alter old behaviour. The two methods (signaling and monodirectional tracks) can be mixed together, and using signals on monodirectional tracks as if it was a bidirectional track shouldn't cause issues either.

I know, it's a large scale solution that tackles more than the problem and probably won't be done, but it's how I would propose it if nothing would exist yet.
Title: Re: Priority signals
Post by: Ters on August 13, 2018, 01:07:58 PM
Quote from: Leartin on August 13, 2018, 09:42:20 AMWhat if we would allow each train on a monodirectional track to reserve all the track ahead of it until it hits another train, a signal, or a switch with more than one "incoming" tracks.
That first thing sounds almost like the virtual block system that exists in modern train control systems like ERTMS. 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.
Title: Re: Priority signals
Post by: Leartin on August 13, 2018, 02:55:45 PM
Quote from: Ters on August 13, 2018, 01:07:58 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...
Title: Re: Priority signals
Post by: Ters on August 13, 2018, 05:13:11 PM
Quote from: Leartin on August 13, 2018, 02:55:45 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.
Title: Re: Priority signals
Post by: gauthier on August 13, 2018, 07:42:55 PM
QuoteA 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.
Title: Re: Priority signals
Post by: Ters 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.
Title: Re: Priority signals
Post by: prissi 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.
Title: Re: Priority signals
Post by: Leartin on August 14, 2018, 04:26:27 AM
Quote from: prissi on August 14, 2018, 01:10:25 AMSince 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.
Title: Re: Priority signals
Post by: gauthier 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 ?
Title: Re: Priority signals
Post by: Ters 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 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.

Quote from: gauthier on August 14, 2018, 08:41:58 AMFor 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.)
Title: Re: Priority signals
Post by: gauthier 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.
Title: Re: Priority signals
Post by: prissi 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.
Title: Re: Priority signals
Post by: Ters on August 14, 2018, 08:46:45 PM
Quote from: gauthier on August 14, 2018, 10:49:13 AMI'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.

Quote from: gauthier on August 14, 2018, 10:49:13 AMIts 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.

Quote from: prissi on August 14, 2018, 03:28:02 PMThe 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?
Title: Re: Priority signals
Post by: ACarlotti on August 14, 2018, 09:18:13 PM
Quote from: Ters on August 14, 2018, 08:46:45 PMI 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.
Title: Re: Priority signals
Post by: sebastien on August 14, 2018, 09:30:41 PM
Quote from: Ters on August 14, 2018, 08:46:45 PMAt 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" ?

Quote from: Ters on August 13, 2018, 08:48:53 PMIt 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.
Title: Re: Priority signals
Post by: Ters on August 14, 2018, 09:55:04 PM
Quote from: ACarlotti on August 14, 2018, 09:18:13 PMThe 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.

Quote from: sebastien on August 14, 2018, 09:30:41 PMHow 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.
Title: Re: Priority signals
Post by: ACarlotti 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.).
Title: Re: Priority signals
Post by: gauthier on August 15, 2018, 07:45:28 AM
QuoteI 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.

QuoteAt 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.

QuoteI 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.
Title: Re: Priority signals
Post by: Ters on August 15, 2018, 08:51:21 AM
Quote from: gauthier on August 15, 2018, 07:45:28 AMBy 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".
Title: Re: Priority signals
Post by: sebastien on August 15, 2018, 09:04:49 AM
Quote from: Ters on August 14, 2018, 09:55:04 PM"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" ?
Title: Re: Priority signals
Post by: gauthier 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.
QuoteIn 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 ?
Title: Re: Priority signals
Post by: TurfIt 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.
Title: Re: Priority signals
Post by: ezosresyek 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!)
Title: Re: Priority signals
Post by: Ters on August 15, 2018, 10:39:01 PM
Quote from: TurfIt on August 15, 2018, 07:51:22 PMDo you really need more than 4 blocks under reservation?
If one has 8 tile long trains and signals every 2 tiles, one does.
Title: Re: Priority signals
Post by: gauthier 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 ?

QuoteMy 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.
Title: Priority signals
Post by: Ves 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.
Title: Re: Priority signals
Post by: TurfIt on August 16, 2018, 09:16:10 PM
Quote from: gauthier on August 16, 2018, 05:11:30 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.

Quote from: gauthier on August 16, 2018, 05:11:30 PM
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.
Title: Re: Priority signals
Post by: Ters 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.
Title: Re: Priority signals
Post by: ezosresyek 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:

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?
Title: Re: Priority signals
Post by: gauthier on August 17, 2018, 04:57:30 PM
@Turfit

Quoteyou 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.
QuoteAnd 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 ?

QuoteWhat 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.

Title: Re: Priority signals
Post by: Leartin on August 20, 2018, 06:25:14 AM
Quote from: gauthier on August 17, 2018, 04:57:30 PMTrain 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.
Title: Re: Priority signals
Post by: ezosresyek on August 20, 2018, 10:15:42 AM
Quote from: Leartin on August 20, 2018, 06:25:14 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.
Title: Re: Priority signals
Post by: Ters 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.
Title: Re: Priority signals
Post by: gauthier 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.
Title: Re: Priority signals
Post by: Leartin on August 21, 2018, 08:09:35 AM
Quote from: gauthier on August 20, 2018, 05:11:49 PMThe 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.
Quote from: gauthier on August 20, 2018, 05:11:49 PMIn 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)
Quote from: gauthier on August 20, 2018, 05:11:49 PMMoreover, 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.

Quote from: Ters on August 20, 2018, 02:03:47 PMVehicles 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.
Title: Re: Priority signals
Post by: Ters on August 21, 2018, 08:45:06 AM
Quote from: Leartin on August 21, 2018, 08:09:35 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.
Title: Re: Priority signals
Post by: Leartin on August 21, 2018, 10:54:08 AM
Quote from: Ters on August 21, 2018, 08:45:06 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)
Title: Re: Priority signals
Post by: prissi on August 21, 2018, 12:08:00 PM
Ok, "pre-signals" are three state signals in the graphics. So there is already a three state signal. The were preliminary names "double block signals" upon introduction but that was changed quickly by some translators to pre-signal and stuck. I think double clock (or two block signal) is much better.

In these terms the priority signal would be a greedy multi block signal.

It must be used with great care when merging lines. If two track with these greedy signals are merging (i.e. all these signals are dragged), then the track with less convois is more likely to be prioritiesed. In the end, the "read my mind" signal does not exist (until the mindreading API is released).

Also, please provide a patch file. The compare function of gitlab gives nothing.
Title: Re: Priority signals
Post by: Ters on August 21, 2018, 01:12:49 PM
I think the pre-signal is just as greedy as the priority signal. The priority signal is just less stubborn, and will accept less than it wants if it can't get it all. As I understand it, that is the only difference.
Title: Re: Priority signals
Post by: Spenk009 on August 21, 2018, 04:41:19 PM
Thinking outside the box here, this is my solution for a passing loop. It involves using a "End-Of-Signalling" signal to stop any reservation beyond the loop. Granted, this doesn't allow for trains to choose whether they wish to enter the loop, as I route the schedule through the loop.

(https://i.imgur.com/qMddtaI.png?1)

(https://i.imgur.com/Toz73iQ.png?1)

(https://i.imgur.com/4QXpca7.png?1)

(https://i.imgur.com/l9WaX0C.png?1)

The solutions offered here don't seem to address the issue that we don't want the slow trains in the slow loop unless there's a convoy "waiting" behind it.
Title: Re: Priority signals
Post by: gauthier on August 22, 2018, 05:50:50 PM
Quotewhich again is a reasonable result.
I don't think blocking or drastically reducing service on one line (and likely stations served only by this line) is more reasonable than slightly reducing service on all lines.

QuoteIf 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)
That's a good point. Then adding a priority system on signal reservation becomes necessary. It can be done in another patch, I'm having a look at this.

@Prissi: Patch file attached.
Title: Re: Priority signals
Post by: THLeaderH on August 25, 2018, 02:10:10 PM
Although there is a discussion about the naming, let me use the original names, presignal and priority signal for this time.

First, gauthier, thank you again for posting this wonderful patch. I'm so excited to see a simutrans world where overtaking of rail vehicles always happens so smoothly.
Though gauthier's patch is already an innovation for the railway system, I made a change on gauthier's patch to enable a local train to wait the departure of an express train at a station. The patch file is attached to this post.

When a train passes a pre-signal or gauthier's priority signal and there is no signal before the end of its route, the train reserves as far as the end of its route. In my modification, when a train passes the priority signal and there is no signal before the end of its route, the train reserves as far as the next signal, beyond the destination of the train. This enables an express train to pass a local train at the station where the express train stops. A demo video is attached to this tweet (https://twitter.com/himeshi_hob/status/1033333685217456128). My modification does not change the behavior of gauthier's priority signal when there is a signal before the end of its route.
Title: Re: Priority signals
Post by: Leartin on August 25, 2018, 02:54:36 PM
You described the behaviour of a longblocksignal. Giving gauthiers signal that behaviour would only be confusing, as it is not what you would expect from it at all.
Title: Re: Priority signals
Post by: TurfIt on August 25, 2018, 08:19:47 PM
Quote from: gauthier on August 17, 2018, 04:57:30 PM
@Turfit
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.
Missing might be that I was referring to loading time, not minimum load/waiting time. You're right in that none of these, or even all together when employed will guarantee an express passing a local, merely increases the probability of such. The proposed 'priority' signal also just increases that chance, but seemingly high enough to be of worth.


Quote from: gauthier on August 17, 2018, 04:57:30 PM
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.
There's no change to when blocks are checked. It's already possibly for a train to sit for a while while other passing trains grab the block. Not an issue.


Quote from: gauthier on August 17, 2018, 04:57:30 PM
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.
Not necessarily. You've brought up a possible use case for having multiple blocks ahead reserved. Flipping this around, is there a use case for only a single block ahead reserved?
i.e. How about replacing the 'normal' signal with one that can reserve multiple blocks.
Title: Re: Priority signals
Post by: Ters on August 25, 2018, 09:32:37 PM
Quote from: TurfIt on August 25, 2018, 08:19:47 PM
Not necessarily. You've brought up a possible use case for having multiple blocks ahead reserved. Flipping this around, is there a use case for only a single block ahead reserved?
i.e. How about replacing the 'normal' signal with one that can reserve multiple blocks.
One would need a way to say "do not reserve past this point until you get there", otherwise some trains will needlessly reserve blocks far up ahead that other trains could have used without the first train being bothered. Imagine for example the setup from the first post, but with the leftmost train being a less important, and slower, freight train. One wouldn't want that to reserve the track up past the station, holding up the passenger train, which otherwise might have been able to leave the station and speed away before the freight train gets there. One doesn't always want to prioritize moving trains over stopped trains.
Title: Re: Priority signals
Post by: THLeaderH on August 25, 2018, 11:10:08 PM
Quote from: Leartin on August 25, 2018, 02:54:36 PM
You described the behaviour of a longblocksignal. Giving gauthiers signal that behaviour would only be confusing, as it is not what you would expect from it at all.

My modification is different from a long-block-signal. A long-block-signal checks tiles beyond the end of the route, but reserves tiles only before the end of the route. In my modification, ALL tiles that are checked by a priority signal will be reserved, beyond the end of the route.

Even if we separate the signal of my modification from gauthier's priority signal, the signal of my modification needs the ability of gauthier's priority signal to make a local train wait for the departure of an express train. The signal should be cascaded and trains should be allowed to proceed as far as they can go, to increase possibility of overtaking and keep capacity of rail tracks. And, the signal need to reserve the tile behind the end of the route to prevent a local train to depart before the express train starts, that is my modification. Since gauthier's priority signal focuses on overtaking, my modification is quite a natural extension for players who want to make trains overtake others.
Title: Re: Priority signals
Post by: TurfIt on August 26, 2018, 01:28:25 AM
Quote from: Ters on August 25, 2018, 09:32:37 PM
Imagine for example the setup from the first post, but with the leftmost train being a less important, and slower, freight train. One wouldn't want that to reserve the track up past the station, holding up the passenger train, which otherwise might have been able to leave the station and speed away before the freight train gets there.
So if a slow freight is following the local passenger, you don't want the signals to reserve multiple blocks, but if a express passenger is following, they should? How are the signals to know this? What if it's a fast freight following the slow passenger?
The first post example wouldn't be setup that way if the following trains is to stay behind. With multiple block reserving signals, you could simply add more signals to eat up the extra blocks, but more sensibly, don't put the local on a side track if the following is not to pass. So, I don't see this as an example of where a signal only reserving a single block ahead is needed.
Title: Re: Priority signals
Post by: Leartin on August 26, 2018, 09:40:18 AM
Quote from: THLeaderH on August 25, 2018, 11:10:08 PMA long-block-signal checks tiles beyond the end of the route, but reserves tiles only before the end of the route.
You are right, I had it wrong.

Quote from: THLeaderH on August 25, 2018, 11:10:08 PMThe signal should be cascaded and trains should be allowed to proceed as far as they can go, to increase possibility of overtaking and keep capacity of rail tracks. And, the signal need to reserve the tile behind the end of the route to prevent a local train to depart before the express train starts, that is my modification.
The intention with the signal discussed here is not forced overtaking though. Even with your example video, the "slow" train has to wait with it's departure even before the "fast" train made it to the station, after which the "fast train" needs to speed up again - all taking so long the "slow" train could have reached the next station in the meantime.

But okay, consider someone actually wants to build this constellation, I'd still look at the long-block-signal. I don't know why the long-block-signal does not reserve as much as it checked, since you would never want another train to enter that area after the check - else, why check at all? I'd assume it has something to do with performance, but since you would create a signal that would reserve anyway, I can't think of a situation where that would break an existing long-block-signal in use.
That being established, you could place such a reserving long-block-signal in front of the switch, no other signal on the "fast lane", a normal signal at the end of the "slow lane" and any number of gauthiers recursive signals before the long-block-signal. Gauthiers signal, according to the description, "Immediately tries to reserve next signal whatever its type", hence if there was a long-block-signal after a recursive signal, the recursive signal should already reserve the long block even beyond the station, so any "fast" train would reserve up to the switch where both lanes merge again as soon as the first recursive signal is hit, forbidding a train in the "slow" station to exit, while still allowing it to move up to the signal before the switch.
I still fail to see WHY anyone would want to do it, but you could do it without adding functionality to a signal that does not need it.
Title: Re: Priority signals
Post by: THLeaderH on August 26, 2018, 12:56:46 PM
I agree with Leartin's statement that a long block signal should reserve all tiles before the next signal instead of a priority signal does so. Neither I can find any reason that a long block signal only reserves the tiles before the end of the route while it checks tiles behind the stop, and I think a long block signal should reserve all tiles that were checked. Is it possible just to change the behavior of a long block signal so that it reserves the tiles beyond the end of the route?

Quote from: Leartin on August 26, 2018, 09:40:18 AM
I still fail to see WHY anyone would want to do it
One of the motivations to do so is to reproduce the railway operation done in a real railway without using minimum load/waiting time. Another is to deal with the situation that we can build a passing lane only at the station where the express train stops.
Title: Re: Priority signals
Post by: prissi on August 26, 2018, 01:36:39 PM
The long block signal is for a single way terminus. It does not reserved tile, because when a game is reloaded, it does not know that is has to rereserve tiles which are not in its route. (Of course that could be saved). But, if you do contruction, then it cannot even find the same route anymore and hence it will never be able to unreserve these tracks unless also all reserved tiles are saved.

That was what we did with the old block system, and what reliably failed after adding a few hundred trains ...
Title: Re: Priority signals
Post by: Ters on August 26, 2018, 03:44:02 PM
Quote from: TurfIt on August 26, 2018, 01:28:25 AMSo if a slow freight is following the local passenger, you don't want the signals to reserve multiple blocks, but if a express passenger is following, they should? How are the signals to know this? What if it's a fast freight following the slow passenger?
Which is why Simutrans need two types of signals. Having both express passenger train, local passenger train and freight trains on the same track won't work with static signal behavior, but at least one can do the first two and the last two separately.
Title: Re: Priority signals
Post by: Leartin on August 26, 2018, 04:01:23 PM
Quote from: prissi on August 26, 2018, 01:36:39 PM
The long block signal is for a single way terminus. It does not reserved tile, because when a game is reloaded, it does not know that is has to rereserve tiles which are not in its route. (Of course that could be saved). But, if you do construction, then it cannot even find the same route anymore and hence it will never be able to unreserve these tracks unless also all reserved tiles are saved.

That was what we did with the old block system, and what reliably failed after adding a few hundred trains ...
So not quite performance, and more of game-breaking bugs. Chances are whatever THLeaderH created would suffer the same problems. If it does, it should not be in the game. If it does not, his method could replace the current check-but-do-not-reserve functionality, so either way there is no new signal required.
Title: Re: Priority signals
Post by: prissi on September 11, 2018, 01:48:44 AM
Ok, the greedy multi block signals (aka priority signals) are now incorporated in r8575. Btw. there were a lot of tab to space in your patch, and I am not sure, I caught them all.
Title: Re: Priority signals
Post by: gauthier on September 11, 2018, 06:49:35 PM
Thanks !
QuoteBtw. there were a lot of tab to space in your patch, and I am not sure, I caught them all.
Ooooops, sorry about that ! Indeed my vimrc is configured to use spaces for indentation.
Title: Re: Priority signals
Post by: ACarlotti on September 11, 2018, 07:10:14 PM
I currently have the following in my .vimrc:
au BufEnter ~/games/simutrans-extended/* setlocal noexpandtab shiftwidth=8 softtabstop=8

And now I realise that I should set that for my Standard working directory too.
Title: Re: Priority signals
Post by: Vladki on September 11, 2018, 08:59:21 PM
Quote from: prissi on September 11, 2018, 01:48:44 AM
Ok, the greedy multi block signals (aka priority signals) are now incorporated in r8575. Btw. there were a lot of tab to space in your patch, and I am not sure, I caught them all.

Wow nice, how do I code these in dat fiels?
Title: Re: Priority signals
Post by: prissi on September 12, 2018, 12:10:30 AM
just add is_prioritysignal=1 to the file.

In pak64, the will be called greedy multiblock signals and the presignals double block signals. These names are hopefully confusing enough to deter casual use without understanding.
Title: Re: Priority signals
Post by: Vladki on September 18, 2018, 08:21:31 PM
Thanks for this patch, it works nice. I was just wondering if I could make a priority and choose signal combo?

Also, if I drag several priority signals in row they show green only if the while stretch is clear. If not, they all show yellow which is quite unrealistic. Would it be possible to change the behavior so that only the signal that could reserve only one block would be yellow?
Title: Re: Priority signals
Post by: prissi on September 19, 2018, 02:07:11 PM
The choose signal cannot combined with any other signal, since it would reserve anyway until the destination or the next choose signal.

The choose signal should show the third aspect when the reservation of the next block fails and one cannot drive on; the greedy block signal is the reverse, you can drive one. Apparently gauthier missed this. (Also I have forgotten to submit the correct graphics for pak64, so you need to reinstall pak64 again.)

Anyway, fixed in r8595
Title: Re: Priority signals
Post by: gauthier on September 19, 2018, 06:54:38 PM
Quote from: Vladki on September 18, 2018, 08:21:31 PM
Also, if I drag several priority signals in row they show green only if the while stretch is clear. If not, they all show yellow which is quite unrealistic. Would it be possible to change the behavior so that only the signal that could reserve only one block would be yellow?
Indeed, I noticed that after drawing proper graphics to show three different aspects. However I'm not sure whether the current behaviour or the one you described is the right one. Players could as well think in terms of critical block "prioritized" (or "greedy multiblocked" as you like) so that all the signals in the row should tell wether the critical block could be successfully reserved (green) or not (yellow). I'm still undecided on this. I'm still going to take a look again to see if this can be changed easily.
Title: Re: Priority signals
Post by: gauthier on September 19, 2018, 08:21:15 PM
BUGFIX
There was this part of code regarding presignals which I did not understand: signal.cc line 73 . After trying to make a dual-version priority signal (with graphics depending on electrification), I suddenly understood what it was for.
Here is the patch.
Title: Re: Priority signals
Post by: prissi on September 20, 2018, 04:19:34 AM
Corected in r8597. That is hopefully all the cosmetics to have working three aspect greedy block signals ...
Title: Re: Priority signals
Post by: Leartin on September 20, 2018, 07:47:49 AM
Quote from: prissi on September 19, 2018, 02:07:11 PM
The choose signal cannot combined with any other signal, since it would reserve anyway until the destination or the next choose signal.

I suppose thats in regard to creating a signal that is both. But what actually happens if the next signal after this 'prioritysignal' is a choose signal? Would the prioritysignal trigger the platform-search of the choose signal (given the scheduled platform is occupied), and if so, in case that's not done in an instant - would the train wait for the platform search to finish? Would the choose signal trigger again when the train reaches it, and if so, just to check the scheduled platform or would it start the whole platform search again?
Title: Re: Priority signals
Post by: prissi on September 20, 2018, 11:31:41 AM
The choose signal would reserve the route, if the route of the concoi is totally free. It will not trigger a search, i.e. the reservation would only go through a choose signal, if everything is free. Otherwise it will be handled as a red signal.

(This is similar to the normal driving. If a route is not free, the train will brake until 100 km-h before triggering a new route search at one tile before the signsl.)

Any of the sepcial signals (logblock, twoblock, geedy block, choose) cannot be combined with another function.
Title: Re: Priority signals
Post by: Vladki on October 20, 2018, 06:24:48 PM
I just tried to make a combined priority + choose signal. It behaves as priority signal (no platform search happens).
Title: Re: Priority signals
Post by: gauthier on October 21, 2018, 01:26:05 PM
The same often happens when combining presignal and choose signal.
Title: Re: Priority signals
Post by: prissi on October 22, 2018, 03:28:37 AM
Signals cannot be combined.
Title: Re: Priority signals
Post by: Vladki on October 22, 2018, 07:00:27 AM
Yes I understand. I was just wondering what will happen and wanted to share the results.
Title: Re: Priority signals
Post by: Ters on October 22, 2018, 02:57:28 PM
single_way, free_route, is_private, is_signal, is_presignal, is_prioritysignal, no_foreground, is_longblocksignal and end_of_choose are a bit of a mess. They are implemented as flags, but most of them are mutually exclusive. The resulting behavior is probably dictated by whichever flag happens to be checked first, which may not even be the same in all cases.
Title: Re: Priority signals
Post by: prissi on October 23, 2018, 12:43:48 PM
At least for signals, not for roadsigns. Anyway, next makeobj will warn, if there are superflous combinations.
Title: Re: Priority signals
Post by: Vladki on November 07, 2018, 09:54:37 PM
Quote from: prissi on October 23, 2018, 12:43:48 PM
At least for signals, not for roadsigns. Anyway, next makeobj will warn, if there are superflous combinations.
I'm not sure if the way it works now is good. Makeobj warns about these combinations, as if they were unknown options:
Entry "is_longblocksignal=1" ignored (check spelling)
And makes the signal to behave as normal signal. This will break paksets/addons which have both is_signal and is_longsignal specified for one object.
Some backward compatibility would be nice.
Title: Re: Priority signals
Post by: prissi on November 08, 2018, 12:57:53 PM
There is no backway compatibilty (or just using old makeobj). Simutrans will use these signals most likely as signals, which may not be the intended way.