[APK-LVDZ]

Hello! We have a problem with signal working in OR_1615:

All signals before junctions from session starts are closed (red). This is good, but have a problem with opening its. Signal scripts are good (in OR_1370 works normally, because created signal scripts special for OR). I click in "System Control" in signal menu - and signal didn't opened. "System Control" not worked properly. This didn't open signals by sigscr.dat instructions.

Some peoples talks "use PROCEED" or "use APPROACH", but in my situation two choices are very small, because for all paths reserved her signal lights.

Will be good, if You created option in OR dispatcher view "signals always opened". Some users will use closed signals, but others - auto opened with sigscr.dat instructions.

Thank You, waiting for answer :ko2:

In attached screen You will see red and white signal ;) White is a permission for proceeding the red signal, this opened from next signals command if BLOCK_STATE !=# BLOCK_JN_OBSTRUCTED.

Attached thumbnail(s)

• 

[roeter]

Request to both : could you please try if signals work correctly when in Single Player mode with an activity?
It would help to know if it is a general signal problem or a Multiplayer problem.

Regards,

Rob Roeterdink

[APK-LVDZ]

Situation is this:

In multiplayer mode:
Signals before junctions can open only with PROCEED, APPROACH and STOP functions. Others signals maybe work normally. I tried to open white light ( permission for red proceeding, did not watching for BLOCK_STATE ==# BLOCK_OCCUPIED. Signal will be should opened, if I choised in next signal "PROCEED" function ), and signal NOT (!!!) opened. In first post has no junction, because signal are opened.
Conclusion: signals in multiplayer mode always closed if path have a junctions. With next signals this signal forcibly did not open. "System Controlled" not work.

In single mode:
Signals before junctions are closed. Can open only with PROCEED, APPROACH and STOP functions. Others signals maybe work normally. I again tried to open white light. Then something strange happened :) In my path signal are opened with white light, I can proceed. Then I closed this function, and open signal towards my train. Signal with forcibly command are opened, but others, which should react, stay closed.
Conclusion: signals in single mode always closed if path have a junctions. With next signals this signal forcibly can open, but if in my path, and only for exit from my occupied block. "System Controlled" not work.

[roeter]

APK-LVDZ, on 28 May 2013 - 03:15 AM, said:

Hello! We have a problem with signal working in OR_1615:

All signals before junctions from session starts are closed (red). This is good, but have a problem with opening its. Signal scripts are good (in OR_1370 works normally, because created signal scripts special for OR). I click in "System Control" in signal menu - and signal didn't opened. "System Control" not worked properly. This didn't open signals by sigscr.dat instructions.

The key to the problem could be in this line : in OR_1370 works normally, because created signal scripts special for OR.
In OR_1370, only very basic signalling was implemented, and many functions as used in sigscr.dat file were not processed correctly or even not processed at all.

Which route are you using, and if this is freeware, where is it available?
Perhaps you can attach the sigcfg.dat and related sigscr.dat files and the .s file(s) of the signal which you show?

Regards,

Rob Roeterdink

[APK-LVDZ]

Route installation:
1. Download from http://trainsim.ru/d...ad/get/?id=1949 route Zilupe 3.6 beta
2. Install this in MSTS with first two options.
This is a original route for MSTS, that script works in MSTS in one path lines (if not my direction signal didn't show lights between stations). In OR not work, and have a some errors.
3. Download from http://depositfiles....files/9pa47p3ss path from route.
4. Open it with WinRar, and copy and replace all to route directory.
This is a special Zilupe 3.6 OR version for OR-1370, that fully worked in OR. All distance not with signal, because now collocate requested signals. Signals has no opp_sig_xx functions, but its necessary for future.
All scripts are in archive.

But problem in "System Controlled" function. Example: if OR open signal, I close signal, and then click in "System Controlled" - this signal will be opened normally by scripts. But if this signal before junction, then from "System Controlled" signal will be closed.

In route very good test platform is station Krustpils (coordinates: 27.646 and 56.933). In route editor please find, for example, signal with name "P2". Did not open this with PROCEED or APPROACH functions, because in my signal this did not works properly, but find the next small with blue light signal named "M21"

http://ipicture.ru/uploads/20130614/2xelhmwX.jpg

In this signal system are two paths. First - if in "P2" two yellow or one green light - train can proceed "M21" or other "M***" with blue light until next signal with green, yellow or red lights. This is a trained path. Used for train going in the line.
Second path is this - please open the "M21" in OpenRails 1370 multiplayer mode with PROCEED function. "M21" will be blue, but "P2" will be opened with white light. This is a red, but with permission for proceeding until first blue or red signal. For example one locomotive go from one track to other track. The loco proceed white light, and will stops after counter blue or red light, and don't proceed the next blue or red signal. Then dispatcher change junction position and open white light in "M***" to other track. This track may contain a train. Green and yellow cannot open if path has a train or wrong junction, but white cannot open only if wrong junction. This is a shunting operations.

If You will open "M21" with APPROACH function, then this signal and "P2" will be white (don't blue (in "P2" red or other signal)) and your train has a permission for proceeding the "P2" and "M21" (for example - if small distance). All shunting signals will be opened with white signal until station track, if path has no any train. And here we have a problem. In OR-1370 some time path are blocked (function block_state return block_occupied). Then train proceed - signals will opens normally. In the last OR-1615 PROCEED or APPROACH functions open the "P2" with white signal. Then if my path until next station I choise "System Controlled" and signal again red. Then please watch: your train in track 2 in station Krustpils. All junctions with directions from session start. Please open a signal "M29" with PROCEED function. The signal "P3" cannot open with white signal, but in script signal are same. Then last bug: please set first junction from track "1" in side position. Then please open the "M21" signal. With a path should open the "P1" signal with white signal, but this is red, but "P2" are white, but in path not my junction! Function "block_jn_obstructed" not work.
Conclusion:
1. "System Controlled" did not open a signal before junctions ("P2" always red (train in track "2"))
2. Function "next_sig_xx" not worked if in a path has no my train ("M29" -> "P3", if my train in track "2")
3. Function "block_jn_obstructed" not work properly ("M21" -> "P1" "P2", train in track "2")

http://s2.ipicture.ru/uploads/20130614/ovgH0QFB.jpg

[roeter]

Hello,

had a little run on this route and immediately found some problems with the signaldata.
I created a simple activity, approaching Krustpils from Osolsala. On approach to Krustpils, the signal did not clear beyond stop-and-proceed even though the line is clear - see picture.


But with some investigation, the problem was easily located.
As mentioned before, in version 1370, which you used to test your signal scripting, only very basic signalling was implemented and lots of signalling functions did not work properly in that version.
One of these items was the 'SignalNumClearAhead' parameter in sigcfg.dat.

So, what is happening here?

The signal which does not clear properly has 4 heads :
Type name : apk_3ab_yg_ry_kr
Type : Distance
Type name : apk_info_poezdnoj
Type : Info
Type name : apk_3ab_ygr_yw_alsn
Type : Normal
Type name : apk_3ab_yg_ry_kr2
Type : Distance

The important one is the 'Normal' type : apk_3ab_ygr_yw_alsn

This is the definition is sigcfg.dat :

  SignalType ( "APK_3AB_YGR_YW_ALSN"
	SignalFnType ( NORMAL )
	SignalLightTex ( "APK_Linza" )
	SignalLights ( 1 
		SignalLight 	( 0 "No Light" Position 	( 0 0 0 ) Radius ( 0.01 ) )
	)
	SignalDrawStates ( 1
			SignalDrawState ( 0 "No" )
	)	 
	SignalAspects ( 8
		SignalAspect ( STOP "No" )
		SignalAspect ( STOP_AND_PROCEED "No" )
		SignalAspect ( RESTRICTING "No" )
		SignalAspect ( APPROACH_1 "No" )
		SignalAspect ( APPROACH_2 "No" )
		SignalAspect ( APPROACH_3 "No" )
		SignalAspect ( CLEAR_1 "No" )
		SignalAspect ( CLEAR_2 "No" )
	)
	SignalNumClearAhead ( 1 )
  )

The main item here is at the bottom : "SignalNumClearAhead ( 1 )".
This value defines the number of SIGNAL-HEADS to be enabled (type normal), INCLUDING this head itself. With value 1, only this signal itself will be enabled and cleared - the next signal(s) will not be enabled and therefor not clear.
So, the next signal will be at state STOP.

Now, let's look at the script for this signal to see what this means :

SCRIPT APK_3AB_YGR_YW_ALSN

	extern float	block_state ();
	extern float	def_draw_state ();
	extern float	state;
	extern float	draw_state;
	extern float	next_sig_lr ();
	extern float	sig_feature ();

	state = SIGASP_STOP_AND_PROCEED;
	if ( block_state() ==# BLOCK_CLEAR )
	{
	if ( next_sig_lr ( SIGFN_NORMAL ) !=# SIGASP_STOP && next_sig_lr ( SIGFN_INFO ) !=# SIGASP_RESTRICTING &&
	next_sig_lr ( SIGFN_NORMAL ) !=# SIGASP_APPROACH_1 && next_sig_lr ( SIGFN_NORMAL ) !=# SIGASP_APPROACH_3 &&
	next_sig_lr ( SIGFN_NORMAL ) !=# SIGASP_CLEAR_2 )
	{
		if ( next_sig_lr ( SIGFN_INFO ) ==# SIGASP_STOP || next_sig_lr ( SIGFN_INFO ) ==# SIGASP_APPROACH_1 ||
		next_sig_lr ( SIGFN_INFO ) ==# SIGASP_APPROACH_2 )
		{ state = SIGASP_APPROACH_2; }
		if ( next_sig_lr ( SIGFN_INFO ) ==# SIGASP_STOP_AND_PROCEED )
		{
		state = SIGASP_APPROACH_2;
		if ( next_sig_lr ( SIGFN_DISTANCE ) !=# SIGASP_STOP && next_sig_lr ( SIGFN_DISTANCE ) !=# SIGASP_STOP_AND_PROCEED &&
		next_sig_lr ( SIGFN_DISTANCE ) !=# SIGASP_RESTRICTING )
		{
		state = SIGASP_CLEAR_1;
		}
		}
	}
	}
	if ( sig_feature( SIGFEAT_USER2 ) )
	{ state = SIGASP_RESTRICTING; }
	draw_state = def_draw_state ( state );

The default state is STOP_AND_PROCEED.
Other states can only be set if all the condition in the IF statement are set, and the first condition is that the next signal must not be at state STOP.
But, as clearly stated above, that is exactly the state of the next signal.
So, the IF condition is not met, and the signal will not clear beyond STOP_AND_PROCEED.

So, in all, the problem is in the SignalNumClearAheas values. These values are not set correctly.
I changed the value for this particular signal to 3 (the signal seems to have 3 states).
The result is shown below.


It looks to me you need to look at the SignalNumClearAhead for all signals - make sure it all works correct in normal single player activities, before starting controlling the signals with the dispatcher window.

Regards,

Rob Roeterdink

[APK-LVDZ]

But "SignalNumClearAhead" shows for any signal how far away any train. Signal should not be closed. This can write with scripts, for example:
if ( !enabled )
{ state = SIGASP_STOP_AND_PROCEED; }
In this route ZilupeOR some paths contains different counts of signals, and for "SignalNumClearAhead" no specific value. Therein our problem.
More appears one problem: some signals did not show lights if block has no train. If train gone on the site before this signal - this show required signal. After proceeding this signal will be closed. This show red until train gone over block after this signal, and then did not shows any signals until the next train go into the block before signal. This options can be programmed only by enabled function, but problem is this - signals will be not green, because next signal will be red if "SignalNumClearAhead" = 1.
Then: little sense for signal closing by "SignalNumClearAhead", because any junction, any train will close signal automatically.
The suggestion is this: retrieve the working from MSTS for "SignalNumClearAhead" functions, but for all signals before junctions assign the block_state ==# block_jn_obstructed, which will be disappear if dispatcher choised "System Controlled" function in signal menu.

After testing:
Problems cannot be resolved :(
I set all SignalNumClearAhead ( 20 ) and smallest numbers, but from track "2" signal cannot be opened. From end of my train signal "N2" opened with two yellow lights, but path specify one green or one yellow light, because not side path.

Then one problem from previous my post:

Quote

Function "block_jn_obstructed" not work properly ("M21" -> "P1" "P2", train in track "2")

If my train in track "2", I open signal "M21" with APRROACH or PROCEED function, and I set junction after "P1" in side position - "P1" is closed, but in my track my signal "P2" are opened, but junction is in side position (signal not watched for block_jn_obstructed)

[roeter]

1) SignalNumClearAhead does work (approximately) as it does in MSTS. Also, SignalNumClearAhead does not 'close' any signals - it just does not clear the train route beyond that signal.

2) There is an OR 'experimental' use for SignalNumClearAhead which could help you.
To use this, you must define SignalNumClearAhead twice for the required signals, as shown :

		SignalNumClearAhead ( -1 )
		SignalNumClearAhead ( 5 )

The first value is used by OR, the second value is used by MSTS.

OR can take two additional values :

• 0 : no signal will be cleared beyond this signal until train passes this signal.
  
• -1: signal does not count when determining the number of signals to clear.

Perhaps that can be of help here.

3) You cannot determine if signalling works correct by using the dispatcher window.
The dispatcher window does not control the signals correctly - it overrules the various signal rules and scripting. So, if you set a signal to PROCEED or APPROACH in the dispatcher window it will do so - regardless of the actual conditions.
This is a known problem but will take some time to sort, especially in MultiPlayer mode.
You must first make sure the signals work correct WITHOUT USING THE DISPATCHER WINDOW, in a normal activity (NOT explorer mode - signals may work different in explorer mode).

4) It would help if you upload the path (as zip-file) which you use, so I can be sure I test the same situation.

Regards,

Rob Roeterdink

[roeter]

Just one more point : SignalNumClearAhead works more or less the same in OR as MSTS, but enable does work different - perhaps there lies the problem.
OR does not enable signals which are followed by a junction unless the section beyond the signal is 'reserved' by a train. This has to do with route setting.
So, even if the function "enabled" is not tested in the script, if the signal is beyond the path of the train it will not clear.

Regards,

Rob Roeterdink