The International Simutrans Forum

 

Author Topic: Priority signals  (Read 6294 times)

0 Members and 1 Guest are viewing this topic.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Priority signals
« on: August 03, 2018, 07:21:30 PM »
Code here: 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

(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
Pak128 test savegame: 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:




« Last Edit: August 03, 2018, 08:12:56 PM by gauthier »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9418
  • Languages: De,EN,JP
Re: Priority signals
« Reply #1 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.
« Last Edit: August 04, 2018, 10:13:23 PM by prissi »

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #2 on: August 04, 2018, 07:06:28 PM »
Quote
This will lead to deadlocks if used as real pre-signals.
... yes ... that's why you don't use them as real presignals.
Quote
Also 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.
Quote
Thus 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).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #3 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.

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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9418
  • Languages: De,EN,JP
Re: Priority signals
« Reply #4 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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #5 on: August 04, 2018, 11:38:42 PM »
Moreover, 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.

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

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #6 on: August 05, 2018, 10:44:00 AM »
Quote
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.)
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.

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

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

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

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #7 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.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2559
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Priority signals
« Reply #8 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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #9 on: August 05, 2018, 07:00:48 PM »
Quote
I 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.
Quote
I'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

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9418
  • Languages: De,EN,JP
Re: Priority signals
« Reply #10 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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #11 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.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 288
  • Languages: JP,EN
Re: Priority signals
« Reply #12 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 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.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2559
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Priority signals
« Reply #13 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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #14 on: August 06, 2018, 07:57:38 PM »
Quote
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.
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.

Quote
This 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.

Quote
Since 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.

Quote
Also 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 ?

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

Quote
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.
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).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #15 on: August 07, 2018, 05:33:47 AM »
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.
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.

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

Offline Leartin at

  • Devotee
  • *
  • Posts: 1152
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #16 on: August 07, 2018, 12:35:13 PM »
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.

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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #17 on: August 07, 2018, 04:52:17 PM »
Quote
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.
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.

Quote
gauthier'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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #18 on: August 07, 2018, 07:44:56 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.

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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9418
  • Languages: De,EN,JP
Re: Priority signals
« Reply #19 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 ...

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #20 on: August 08, 2018, 05:58:17 AM »
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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #21 on: August 08, 2018, 04:38:18 PM »
Quote
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.
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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #22 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:

Code: [Select]

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

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2559
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Priority signals
« Reply #23 on: August 08, 2018, 07:41:29 PM »
Yep, the second diagram is exactly what I meant.

Offline sebastien

  • *
  • Posts: 14
  • Languages: FR, EN
Re: Priority signals
« Reply #24 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:

Code: [Select]

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


Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #25 on: August 09, 2018, 04:41:44 PM »
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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #26 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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #27 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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #28 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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9418
  • Languages: De,EN,JP
Re: Priority signals
« Reply #29 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.)

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #30 on: August 10, 2018, 06:01:29 AM »
A 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.

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

Code: [Select]
.┌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.

Offline Leartin at

  • Devotee
  • *
  • Posts: 1152
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #31 on: August 10, 2018, 06:58:07 AM »
A 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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9418
  • Languages: De,EN,JP
Re: Priority signals
« Reply #32 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.)


Offline Leartin at

  • Devotee
  • *
  • Posts: 1152
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #33 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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5447
  • Languages: EN, NO
Re: Priority signals
« Reply #34 on: August 13, 2018, 01:07:58 PM »
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.
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.