The International Simutrans Forum

 

Author Topic: Priority signals  (Read 4618 times)

0 Members and 1 Guest are viewing this topic.

Offline prissi

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

Offline Ters

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

Offline Spenk009

  • *
  • Posts: 187
Re: Priority signals
« Reply #72 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.









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.

Offline gauthier

  • Devotee
  • *
  • Posts: 3616
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #73 on: August 22, 2018, 05:50:50 PM »
Quote
which 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.

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

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 268
  • Languages: JP,EN
Re: Priority signals
« Reply #74 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. My modification does not change the behavior of gauthier's priority signal when there is a signal before the end of its route.

Offline Leartin

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

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1306
Re: Priority signals
« Reply #76 on: August 25, 2018, 08:19:47 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.


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.


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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5340
  • Languages: EN, NO
Re: Priority signals
« Reply #77 on: August 25, 2018, 09:32:37 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.

Offline THLeaderH jp

  • Coder/patcher
  • Devotee
  • *
  • Posts: 268
  • Languages: JP,EN
Re: Priority signals
« Reply #78 on: August 25, 2018, 11:10:08 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.

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1306
Re: Priority signals
« Reply #79 on: August 26, 2018, 01:28:25 AM »
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.

Offline Leartin

  • Devotee
  • *
  • Posts: 1063
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #80 on: August 26, 2018, 09:40:18 AM »
A 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.

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

Offline THLeaderH jp

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

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.

Offline prissi

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

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5340
  • Languages: EN, NO
Re: Priority signals
« Reply #83 on: August 26, 2018, 03:44:02 PM »
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?
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.

Offline Leartin

  • Devotee
  • *
  • Posts: 1063
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #84 on: August 26, 2018, 04:01:23 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.

Offline prissi

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

Offline gauthier

  • Devotee
  • *
  • Posts: 3616
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #86 on: September 11, 2018, 06:49:35 PM »
Thanks !
Quote
Btw. 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.

Offline ACarlotti

  • *
  • Posts: 240
Re: Priority signals
« Reply #87 on: September 11, 2018, 07:10:14 PM »
I currently have the following in my .vimrc:
Code: [Select]
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.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2339
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Priority signals
« Reply #88 on: September 11, 2018, 08:59:21 PM »
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?

Offline prissi

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

Offline Vladki cz

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

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9282
  • Languages: De,EN,JP
Re: Priority signals
« Reply #91 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
« Last Edit: September 19, 2018, 02:26:46 PM by prissi »

Offline gauthier

  • Devotee
  • *
  • Posts: 3616
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #92 on: September 19, 2018, 06:54:38 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.

Offline gauthier

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

Offline prissi

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

Offline Leartin

  • Devotee
  • *
  • Posts: 1063
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Priority signals
« Reply #95 on: September 20, 2018, 07:47:49 AM »
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?

Offline prissi

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

Offline Vladki cz

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

Offline gauthier

  • Devotee
  • *
  • Posts: 3616
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: Priority signals
« Reply #98 on: October 21, 2018, 01:26:05 PM »
The same often happens when combining presignal and choose signal.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9282
  • Languages: De,EN,JP
Re: Priority signals
« Reply #99 on: October 22, 2018, 03:28:37 AM »
Signals cannot be combined.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2339
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Priority signals
« Reply #100 on: October 22, 2018, 07:00:27 AM »
Yes I understand. I was just wondering what will happen and wanted to share the results.

Offline Ters

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

Offline prissi

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

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2339
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Priority signals
« Reply #103 on: November 07, 2018, 09:54:37 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.

Offline prissi

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