[ebnertra000]

Quote

According to this I have to apologize and correct myself in comparison to post # 1, because I have now seen that OR responds to at least all BLOCK_Values, while MSTS e.g. apparently not react to BLOCK_JN_OBSTRUCTED (!) at all, wow!

Not so fast... MSTS did respond to BLOCK_JN_OBSTRUCTED. I used it on a switch indicator (a DISTANCE-type signal) to force it to show red. You would probably never see it on a NORMAL-type, since there would likely be another reason the light would be red (another train, not enabled, etc.) The only way I could get JN_OBSTRUCTED to trigger is if a trailing-point switch was lined against the route the signal would use. NORMAL-type signals wouldn't let you do that (I think), but other types would allow it to happen

[jonas]

ebnertra000, on 17 December 2018 - 11:15 AM, said:

Not so fast... MSTS did respond to BLOCK_JN_OBSTRUCTED. I used it on a switch indicator (a DISTANCE-type signal) to force it to show red. You would probably never see it on a NORMAL-type, since there would likely be another reason the light would be red (another train, not enabled, etc.) The only way I could get JN_OBSTRUCTED to trigger is if a trailing-point switch was lined against the route the signal would use. NORMAL-type signals wouldn't let you do that (I think), but other types would allow it to happen

Ok, may be. I tested it with a trailing switch and a NORMAL-type signal. There was no change after the AI-train leave the switch and it was turned strait for the player train. But even after I changed the whole signal to DISTANCE - no reaction too (Maybe I'm missing something.)
In any case, according to MSTS manual, I would not have expected that there would be a difference between NORMAL and other signal types according to BLOCK_JN_OBSTRUCTED.

Qoute from MSTS "How_to_make_Signal_config_and_Script_files.doc":

[jonas]

In OR route_set() is always not set (false or 0) after passing a signal. Not so in MSTS.

I have the problem that after passing a signal I want to show different aspects on the signal screen, depending on what the switch position in the route after the signal is. In OR, only the signal aspect according for !route_set() is showed.

Is this seen as a bug and if so can this be changed?
If not, how can I determine the switch positions (route_set()) of a signal after a train has passed this signal in OR?

[roeter]

This is not a bug but quite deliberate. A (normal) signal which is not enabled does not check for route_set. The main reason is to avoid display of information which does not apply to the train which is approaching. A switch may be left 'hanging' in a specific position due to the passage of a previous train (which may not actually have passed this signal at all but approached from a different route). Showing such information could be confusing for an approaching train.
Personally, I do not know of any controlled signal covering a junction which shows information on the route setting when it is in 'stop' state.

This restriction only applies to normal signals. You can use other signaltypes to show such information as required.
Also, you could use a signal variable to store the last set route information :

• when enabled, store the value of route_set in the signal variable
  
• when not enabled, use the stored value as the state of route_set

Only problem with the use of such a variable is that on startup, the state is undefined. This also applies for restart after save as these signal variables are not saved.

Regards,
Rob Roeterdink

[VicenteIR]

If a signal has more than one signal head of SigFn_Type NORMAL, how it gets TRUE from enabled() function? I mean if all signal heads are "enabled" in this case or only the relevant signal head?
Thanks
Oleg

[ebnertra000]

I think it works like so: If a signal is enabled for a certain route, a head linked to said route (or not route-linked at all) would also be enabled. Other heads that were linked, but not to that route, would not enable.

Personally, I would avoid the issue entirely and just have one NORMAL-type signal hidden in the shape, with all displaying heads using some other type. I do this with US-type signals and it works brilliantly

[VicenteIR]

Thanks. And what about a signal heads with SignalNumClearAhead value of -1? Can I set enabled() as one of conditions at that signal head?
I am trying to implement
" opp_signal = opp_sig_id (SigFn_NORMAL);
opp_direction = id_sig_lvar (opp_signal, 2);"...
And then:
..." if (enabled && (opp_direction ==# 0) { store_lvar (2,1);}
else { store_lvar (2,0;}"...
It doesn't take effect. I tried to write this to the linked multi-head entrance signal (the signal is not protecting on a switch, I have another linked multi-head signal between the entrance signal and the switch) and at another case - on "a last" interval signal before the entrance signal whith SignalNumClearAhead = -1.
So, the question is if in a case of that parameter of SignalNumClearAhead it is correct to write expression "if (enabled) for this signal?

[roeter]

ebnertra000, on 08 May 2020 - 04:24 PM, said:

I think it works like so: If a signal is enabled for a certain route, a head linked to said route (or not route-linked at all) would also be enabled. Other heads that were linked, but not to that route, would not enable.

Sorry, but that's not the case.
The variables enabled and blockstate are signal variables, so by definition have the same value for all signalheads. Only routeset is a signalhead variable.

Quote

And what about a signal heads with SignalNumClearAhead value of -1? Can I set enabled() as one of conditions at that signal head?

The SignalNumClearAhead value has nothing whatsoever to do with the state enabled. It only indicates if the request to clear the signal must be propagated, that is if it must be extended to the next signal. It only has a meaning for NORMAL signal heads, and the value '-1' indicates that the request must always be propagated regardless of the SignalNumClearAhead value for the originating signal and the number of signals already propagated.
In other words, if a NORMAL signal with SignalNumClearAhead value of -1 is requested to clear, and the signal can indeed clear, then it will always extend that request to the next signal.
The state enabled means that a train is 'approaching' this signal, a valid route for this train has been set leading up to this signal and the train is requesting this signal to clear.

Regards,
Rob Roeterdink

[darwins]

Sorry, I am way behind the curve on signalling in OR.
In timetable mode I have seen call-on work with AI traffic where a loco is timetabled to couple to a stationary train call-on (or carre violet).
I have not yet seen how the call-on functionality deals with the "drive on sight", "permissive block" (or carre rouge).
Is it now possible for AI trains to enter a section at reduced speed and stop before colliding with a train ahead (As described in the Berlin S-Bahn case)?
What variations are possible with this?
In many cases permissive signals have a stop and proceed rule - is there a way to instruct AI traffic to do that?

[roeter]

darwins, on 09 May 2020 - 03:13 AM, said:

Is it now possible for AI trains to enter a section at reduced speed and stop before colliding with a train ahead (As described in the Berlin S-Bahn case)?

That's always been possible. All it takes is to allow a signal to clear on blockstate OCCUPIED. However, NEVER EVER allow a signal to clear on blockstate JN_OBSTRUCTED.
In timetable mode, it is possible to have this as a controlled option using the $callon parameter, e.g. to allow multiple trains into a platform or siding.

Quote

What variations are possible with this?

Whatever you like - special aspect (e.g. auxiliary aspect like a shunt signal), speed reduction - just set it as required aspect.

Quote

In many cases permissive signals have a stop and proceed rule - is there a way to instruct AI traffic to do that?

Yes - use APPROACH_CONTROL with required speed = 0. The signal will then only clear once the train has stopped in front of the signal.
You must, however, use two aspects to make this work. The signal must be kept at 'STOP' state until the approach control is cleared. Then you can switch the signal to a permissive aspect, e.g. 'RESTRICTED'. But, ofcourse, the aspect as shown can be the same, e.g. just red. Or, the signal can indeed clear to a different visible aspect.

Regards,
Rob Roeterdink