This is currently a draft. Feel free to discuss the implementation here.

In this proposal, error situations do not need to be detected unless it is explicitly stated that the error is signaled.

• Each TCB side can have one distant signal and multiple distant signal repeaters assigned to it.
• The main signal can also be assigned as a distant signal, but it is an error if the main signal is a distant signal repeater.
• Distant signals should be able to operate as a regular distant signal or as a repeater. It is an error if this condition is not satisfied.
• It is an error if there is no regular distant signal between a distant signal repeater and a main signal.

Edit: I think I should allow having only one distant signal assigned to a TCB side at a time. This is likely easier to implement; alternatively, it should be possible to assign a distant signal to reflect the signal aspect of a main signal or a distant signal (e.g. for a distant signal repeater). — ywang 2022-01-01 03:00

The distant signals of a main signal is only set when the route to the main signal is set and goes through the distant signals. The interlocking system can do so by traversing through the route to the main signal and setting the distant signals on its way. The first distant signal is treated as a regular distant signal, and the rest are treated as distant signal repeaters. A list of distant signals assigned to the main signal should be kept to make sure that the distant signals are updated as the aspect of the main signal changes.

It should be selectable whether a signal on the route should be treated as distant signal and which not. At least the user shoud be able to set which is the first intermediate signal on the route that should serve as distant signal. The reason for this is that there may be a very long block (the route start signal should not pre-display any distant aspect here) and there is a dedicated distant-only signal before the next main signal. — orwell 2021-12-31 17:22

What I thought about was that you need to explicitly set a signal as a distant signal by assigning it to a TCB (separately from the main signal - if you have e.g. a Ks signal you need to assign it twice) or by assigning it to an existing signal. — ywang 2022-01-01 03:00

I thought about this again: the main and distant aspects, when both assigned, should be assigned to the same TCB. It does not make much sense otherwise. — ywang 2022-02-10 17:49

— orwell 2021-12-31 17:22 The above approach requires that each distant signal (even if it is a pure distant signal without main signal function) is assigned to a TCB (correct?).

I propose a separate mode where the distant signal is not assigned to a TCB, but instead shows the distant aspect of one (user-selected) main signal at all times, irregardless of route settings. Of course this only makes sense for pure-distant signals.

We can use this for simple distant signals before mainline main signals when we don't want to add another TCB (and thus make the block section 2 track sections instead of just one).

Makes sense. I have appended it to the previous section. — ywang 2022-01-01 03:00

The procedure of setting the aspect of distant signals must be done in a way that the distant signal(s) showing the aspect of the main signal can be found. Distant signals are unset (i.e. set to nil) when the main signal and/or the distant signal becomes irrelevant for any train, such as when the distant signal is a combined signal showing the Hp 0 aspect.

In the following case:

^
|
+---- Main signal H1
|
|  ^
|  |
|  +- Main signal H2
|  |
|\/|
|/\|
|  |
|  +- Combined signal H4 (main)/V2 (distant)
|  |
|  V
|
+---- Combined signal H3 (main)/V1 (distant)
|
V

If both routes H4→H2 and H3→H1 are set, then

• V1 is set to reflect the main aspect of H1. It is unset when the train passes H1.
• V2 is set to reflect the main aspect of H2. It is unset when the train passes H2.

If the route H3→H2 is set, then

• V1 is set to reflect the main aspect of H2. It is unset when the train passes H2.
• V2 remains unset as it is not relevant for the train using the route.

— orwell 2021-12-31 17:22 IMO the easiest way to provide clean distant signal support is via extending the “Signal Aspect” table. Proposal:

asp = {
  ... other fields as usual ...
  dst_pos = <position vector>,
  dst = nil, -- 'dst' field is not provided directly

Then, within advtrains.interlocking.signal_set_aspect(pos, asp), the dst_pos field is looked up and the dst field is set accordingly before the set_aspect() of the node definition is called.

2 things need to be taken care of:

1. the signal API somehow needs to keep track of the aspects the signals are supposed show - not only for the TCB-assigned signals but for all signals
2. the signal API needs to remember a reverse lookup of signals that have dst_pos set on a signal, to trigger aspect updates accordingly.

With this implementation, the distant signals feature can also easily be used from LuaATC-controlled signals. The route mechanism can just plug into that and set the position of the route end signal as dst_pos.

Whether signal is a distant signal repeater would then be another field in the aspect definition (dst_repeater = <boolean>)

Also, there is this “Verkürzter Bremswegabstand” light in Ks signals - dst_short = <boolean>?

In an earlier implementation I simply put the distant signal information (position of the main signal or the distant signal) in the signal table itself instead of the aspect table. That made it possible to keep track of what is assigned to what. I would prefer having the signal aspect table as a fallback when the source of the train is unknown. The “verkürzter Bemswegabstand” feature might be a bit complicated when you have a distant signal that can be assigned to multiple main signals (e.g. at a turnout), and I would prefer a method that computationally figures out whether the braking distance is reduced, which is beyond my abilities at the moment. — ywang 2022-01-01 03:00