[roeter]

There is another problem with the signals on this route and that is that the signalling system uses STOP_AND_PROCEED aspect to protect junctions.
That will not work in OR. The 'reservation' system will allow trains to clear track beyond a STOP_AND_PROCEED aspect and, as a result, this will block other routes in situations where the train is supposed to wait, thus creating deadlocks.
To protect junctions, the STOP aspect must be used if the track ahead is not clear.
I changed the sigscr.dat file in this respect and then things work correct.
To change this in the program is too complicated, and also contradicts the use of STOP_AND_PROCEED in other situations where it is used as it is intended.
I'm sorry, but this signalling system will not work in OR.

Regards,

Rob Roeterdink

[APK-LVDZ]

Hello!
It is unfortunate, but there are errors in the OpenRails. Compared to 1370 and 1764 version.
Signal did not watch junctions, witch stay FROM my or other paths. Signal always is opened.
We have a problem with STOP_AND_PROCEED and STOP aspects in OpenRails 1764. Yes, You said "use the STOP", but really all aspects are equal, and STOP or STOP_ANS_PROCEED can not be used by default for Red. In any country all signal systems are unique.
More one problem are in function next_sig_lg or next_sig_mr. The STOP value is the smallest (0), then STOP_AND_PROCEED (1), and others... If You change priority for signals (for use STOP, but not STOP_AND_PROCEED), then signal logic are broken, because I can not artificially lock the signal, if STOP is Red, and I do not have most restricted aspect. In USSR locos (1000 models!!!) used all 8 aspects. Very kindly return the support aspects.

Testing signal in 1764, and preview from 1370 (identical to MSTS):


In the extreme case, please make a separate version OpenRails, where the signals were working in version 1370.

[roeter]

I appreciate the problem, but I just don't have a simple solution that can be implemented in a few days or so.
The problem is very complex. If I can find a way to sort this properly - and it's still a big if - it will probably take weeks to implement and test. Extensive tests will be required to ensure the changes do not affect the working of signal on any other routes.

As for version 1370 - that was the 'old' signalling, version 1395 saw the introduction of the 'new' signalling. This was a complete rewrite of all and everything to do with signals, train control and track access logic. These versions are completely incompatible and there is no way any part of the logic or code from 1370 can be incorporated in the present version.

Regards,

Rob Roeterdink

[APK-LVDZ]

Thank You for answers!
We are ready to test the signal system working in multiplayer mode as long as you need. I have extensive experience writing scripts for MSTS. Please do not just postpone the problem. In MSTS was all thought out. We're glad you want to improve, but need the support of the original work.

About function block_state() !=# BLOCK_JN_OBSTRUCTED: you said it does not use, but there are situations when it is necessary to check: does my junctions in the path until next NORMAL signal, despite the fact that there may be a train.
About function enabled. By default this function return "true", if a train is located next to traffic light in SignalNumClearAhead ( ... ). This option can be used by scripts author for:
1. if enabled ==# false then signal is is extinguished (worked, but did not show any light) (SignalNumClearAhead(1))
2. if enabled ==# false then signal is closed (worked, but shows red) (for example SignalNumClearAhead(3))
As you can see, OpenRails not need to re-light the red light before junctions, because this can be programmed in signal script (if necessary).

http://www.imghost.in/thumbs/2013-09/22/w4b3bvntqsj7j6adpkxi4qc2t.jpg

[roeter]

There are still serious problems in signalling for MultiPlayer which we will be working on shortly.
Untill that is sorted, only problems in Single Player should be reported.

As for block_state() !=# BLOCK_JN_OBSTRUCTED, I did not say it should not be used - what I meant is that it should not be allowed for trains to pass a signal in that situation. But that is, presently, what happens if you use STOP_AND_PROCEED (or even less restrictive) aspects in that situation.

I do not know what you mean by 're-light red signal before junction'. In Single Player mode (without dispatcher), all aspects for signals are set through the signal scripting only.
Furthermore, the 'enabled' function has nothing to do with SigNumClearAhead.
The SigNumClearAhead only sets the number of signals which may be cleared, it does not in any way change how those signals react.

The problems with using STOP_AND_PROCEED or other aspects as 'virtual' STOP aspects (which is what happens in these scripts) are not in the signal scripting or signal logic as such. The problems have to the with the track-access logic.
If a train is to stop at a signal, which is therefor in STOP state, that train is not allowed to 'claim' access to track beyond that signal. But if a train is approaching a signal with any other state than STOP, it is allowed to claim access - and it may well therefor claim access to track sections which should have been left clear for other trains.
So, using STOP_AND_PROCEED in these situations causes the track access logic to fail. To resolve that problem, a major rework of the track access logic is required - and that is a very complex and extensive amount of work.

Regards,

Rob Roeterdink

[APK-LVDZ]

roeter, on 26 September 2013 - 03:32 AM, said:

I do not know what you mean by 're-light red signal before junction'.

Sorry, that is my bad English, this text copied from Google translate :rotfl: OpenRails not needed for signal closing by OpenRails, but only by script. Something like that :drinks: