[roeter]

VicenteIR, on 25 April 2015 - 07:45 AM, said:

In OR it does not work due to the fact that the signals behave differently unlike MSTS (functions enabled() and opp_sig...()).

There is a slight difference in the use of 'enabled' between MSTS and OR.
In OR, if a signal has no 'fixed path' (that is, there is at least one switch or cross-over between this and the next NORMAL signal), it will not clear when not enabled by a train, even if the state of 'enabled' is not tested.
That is because as long as no path is cleared over that switch by a train, the position of the switch is 'unknown' and a signal can not be cleared over a switch in that state.

I do not think this affects your situation as in your case the signals will be cleared by a train. Perhaps the difference in SignalNumClearAhead is affecting your situation - you might want to have a look at that, and check that the value for SNCA for the preceding main signal is set at a high enough value to clear the path as far as required.

The function opp_sig has been tested and shown to be working correctly.

Regards,
Rob Roeterdink

[raster]

I meant something else, not always possible to use your method. I am writing a script, that for proper operation needs one variable which will be remembered, and its value will not be associated with a signal state. I think not only for me that such a thing was helpful.
These all my ideas for signaling, they are ideas that would allow the creation of a well-functioning signaling system on Polish railways, especially maneuvering signals that are handled manually, not automatically, so it's hard to automate. The best solution would be the use of special points in the patch, which would began or ended with a new type of patch, and his type could be read from a script signal-this would introduce some element of manual operation and would work best. I described it once already.
Are any of these possible?
Regards:)

[VicenteIR]

ApproachControlSettings (PositionM ( 50 )) does not work in x3725. A signal is at danger, but when AI train passes previous signal, it opens regardless of what value of "position" is set

[eugenR]

VicenteIR, on 28 January 2017 - 01:47 PM, said:

ApproachControlSettings (PositionM ( 50 )) does not work in x3725. A signal is at danger, but when AI train passes previous signal, it opens regardless of what value of "position" is set

I have tried this morning with X3757, it was o.k.
You need also in the sigscr.dat something like:
if (!enabled || block_state() !=# BLOCK_CLEAR || !APPROACH_CONTROL_POSITION(Approach_Control_Req_Position) )
{
state = SIGASP_STOP;
draw_state = 0;
}
else

[VicenteIR]

It is work at another station. Thank you

[eugenR]

VicenteIR, on 28 January 2017 - 03:57 PM, said:

It is work at another station. Thank you

The distance between both signals has to be greater the controlled-Distance (here 50m)!
If the first signal is standing in the controlled-Distance the second signal can switch only to clear after the train was closing the first signal.

Do you have a special track-situation between the two signals, if so please show a printscreen from the trackviewer for this situation.

regards
EugenR

[VicenteIR]

eugenR, on 28 January 2017 - 11:57 PM, said:

Do you have a special track-situation between the two signals, if so please show a printscreen from the trackviewer for this situation.

It is not a special track situation in this case. I think the problem was the starting point of the AI path (outside the station, and the signal has aт approach control is an output signal). The SNCA value is too large on the Entrance signal. Because of all this, at the next station it worked.
I tested already, and in my case, it did not help me. However, the function itself is working correctly, thank you

[vitro]

Hello everyone. When I was trying to implement some Moscow Metro signaling features, it becomes a problem. I can't change draw states of signal with approach_control_* functions when signal is not enabled (have a waiting point before it). So I think it will be nice solution to implement this ability. Thanks.

[roeter]

There is no interaction between waiting points and signals. There are various types of waiting points and do not know how exactly this affects the rest of the train's path. But if a signal is not enabled it means - to that signal - there is no train approaching that signal, and so it is not possible to clear the signal based on the approach control condition (the condition is checked by the signal, not by the train).
The signal should clear as soon as the waiting point condition is lifted.
But - why do you want a signal to clear if you're going to stop that train on a waiting point anyway? That makes no sense.

Regards,
Rob Roeterdink

[vitro]

I don't want use an approach control for clearing disabled signal. I need to change draw_state of this signal with the same aspect.

In my case there is a signal which shows "Yellow and Red" until the train arrived to the station. Once the train stops, this signal becomes "Red" only. Then after 20 secs signal is cleared. Here's the real video: https://www.youtube....XmqTZ7-VI&t=41s