[jonas]

Hello!
Under certain conditions the semaphores are not moving at semaphore-signals in OR (version 0.9.0.1648) . Whereas the lights showing the correct aspects the semaphores keep "quiet". This is the more interesting and not expected because the lights are beeing set at the same passage in the code of the sigcfg.dat where the semaphores beeing set.
The picture below shows the same semaphore-signal in the same route with the same sig-Files in MSTS compared to OR (the upper row shows the proper function in MSTS):

http://www.p-circle.de/elvastower/sema.jpg

After some detailed tests it seems to me that it is about the order of executing the scripts in the sigscr.dat. This order again depents to the order how the SignalSubObj are sorted in the sigcfg.dat at the SignalShape-tag.

The following code-part of the SignalSubObjs-tag in the sigcfg.dat is that one of the not moving semaphores in OR in the picture above (lower row).

...
		SignalSubObjs ( 3
			SignalSubObj ( 0	"HEAD1"		"SEMAPHORE 1"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_F1" )
			)
			SignalSubObj ( 1	"HEAD2"		"SEMAPHORE 2"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_F2" )
			)
			SignalSubObj ( 2	"SIGNAL"		"Hp2 40 km/h"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK DEFAULT )
				SigSubSType ( "Sig25EHp_F2_40" )
			)
		)
...

If I change the order of the tags (and re-number it!) like the following code the semaphores will move correct. (After that change it is of course required to rebuild the signal in the RouteEditor.)

...
		SignalSubObjs ( 3
			SignalSubObj ( 0	"SIGNAL"		"Hp2 40 km/h"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK DEFAULT )
				SigSubSType ( "Sig25EHp_F2_40" )
			)
			SignalSubObj ( 1	"HEAD1"		"SEMAPHORE 1"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_F1" )
			)
			SignalSubObj ( 2	"HEAD2"		"SEMAPHORE 2"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_F2" )
			)
		)
...

But such changes in the sig-files of finished routes implicates other changes i.e. in the tdb.dat and will force you finally to rebuild all the signals with its links to the tracks again.
A compatibility to MSTS would therefor be desirable in view of this sorting-problem. Remember, the lights working fine by now in OR and are set by the same code-parts of the sigcfg.dat. The script-executing-order seems only important for the semaphores and keep them unmoved. Hopefully it is not that sophisticated to solve it.
A hint maybe that OR fires a warning when the order is another than the numbers: "...Invalid SignalSubObj index; expected 0, got 1..." (line 646 in ORs SIGCFGFiles.cs). In MSTS you can "shake" the tags to every order you want. It are only the numbers (indexes) which are important for MSTS.


Greetings

(Sorry for that white background color at the code snippets. I have not found how to change it.)

This post has been edited by jonas: 07 April 2014 - 05:52 PM

[gpz]

jonas, on 07 April 2014 - 05:43 PM, said:

Under certain conditions the semaphores are not moving at semaphore-signals in OR (version 0.9.0.1648)

Could you please download a more recent version of OpenRails from http://james-ross.co...jects/or/builds, and test if the problem still applies?

Thanks!

[jonas]

Ok. Now I tryed it with the version X2157, released yesterday. Unfortunatly I get still the same result.

Short quicktime video

[roeter]

A possible cause is a mismatch between the "SemaphorePos" setting in SignalType definition in sigcfg.dat, and the animation positions defined in the shape-file. I have had various signals which this problem, and changing the SemaphorePos setting sorted the problem.
Can you please provide details of these signals (route, freeware/payware and where available etc.).

Regards,
Rob Roeterdink

[jonas]

The route will be payware, if I'll get ready with it (some day). So I don't feel free to publish the complete sig-files etc. here, but I will post the concerning script-parts:

Scripts of the OpenRails-NOT-working version:


sigcfg.dat:

...	_( 1925 Einfahrtssignal 2-flüglig - V-Reduktion optional -------------------------------------------------------------------------------- Sig25EHp )
	SignalType ( "Sig25EHp_Sema1"
		SignalFnType ( INFO )
		SignalFlags ( SEMAPHORE )
		SignalLightTex ( "SigTex01" )
		SignalLights ( 2
			SignalLight ( 0	"ROT"	Position ( -0.272 -0.218 -0.092 )	Radius ( 0.30 )	SignalFlags ( SEMAPHORE_CHANGE )	)
			SignalLight ( 1	"GRUEN"	Position ( -0.352 -0.167 -0.092 )	Radius ( 0.30 )	SignalFlags ( SEMAPHORE_CHANGE )	)
		)
		SignalDrawStates ( 3
			SignalDrawState ( 0		"Hp0"
				DrawLights ( 1 DrawLight ( 0 ) )
				SemaphorePos ( 0 )
			)
			SignalDrawState ( 1		"Hp2"
				DrawLights ( 1 DrawLight ( 1 ) )
				SemaphorePos ( 1 )
			)
			SignalDrawState ( 2		"Hp1"
				DrawLights ( 1 DrawLight ( 1 ) )
				SemaphorePos ( 1 )
			)
		)
		SignalAspects ( 3
			SignalAspect ( STOP		"Hp0" )
			SignalAspect ( APPROACH_1	"Hp2" )
			SignalAspect ( CLEAR_2		"Hp1" )
		)
		SignalNumClearAhead ( 3 )
	)
	SignalType ( "Sig25EHp_Sema2"
		SignalFnType ( INFO )
		SignalFlags ( SEMAPHORE )
		SignalLightTex ( "SigTex01" )
		SignalLights ( 1
			SignalLight ( 0	"GRUEN"	Position ( -0.021 -0.353 -0.092 )	Radius ( 0.30 )	SignalFlags ( SEMAPHORE_CHANGE )	)
		)
		SignalDrawStates ( 3
			SignalDrawState ( 0		"Hp0"
				SemaphorePos ( 0 )
			)
			SignalDrawState ( 1		"Hp2"
				DrawLights ( 1 DrawLight ( 0 ) )
				SemaphorePos ( 1 )
			)
			SignalDrawState ( 2		"Hp1"
				SemaphorePos ( 0 )
			)
		)
		SignalAspects ( 3
			SignalAspect ( STOP		"Hp0" )
			SignalAspect ( APPROACH_1	"Hp2" )
			SignalAspect ( CLEAR_2		"Hp1" )
		)
		SignalNumClearAhead ( 3 )
	)
	SignalType ( "Sig25EHp_Sema2_40"
		SignalFnType ( NORMAL )
		SignalFlags ( SEMAPHORE ABS )
		SignalLightTex ( "SigTex01" )
		SignalDrawStates ( 3
			SignalDrawState ( 0		"Hp0"
			)
			SignalDrawState ( 1		"Hp2"
			)
			SignalDrawState ( 2		"Hp1"
			)
		)
		SignalAspects ( 3
			SignalAspect ( STOP		"Hp0" )
			SignalAspect ( APPROACH_1	"Hp2"	SpeedKPH ( 40 )	)
			SignalAspect ( CLEAR_2		"Hp1"				)
		)
		SignalNumClearAhead ( 3 )
	)
...

below in the sigcfg.dat:

...	SignalShape (
		"Sig25EHp.s"
		"1925 Formsignal 2 Flg Einfahrt"
		SignalSubObjs ( 10
			SignalSubObj ( 0	"HEAD1"		"FLUEGEL 1"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_Sema1" )
			)
			SignalSubObj ( 1	"HEAD2"		"FLUEGEL 2"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_Sema2" )
			)
			SignalSubObj ( 2	"SIGNAL"		"Hp2 40 km/h"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK DEFAULT )
				SigSubSType ( "Sig25EHp_Sema2_40" )
			)
		)
	)
...

sigscr.dat:

...
//------------------------- 1925 Einfahrtssignal first (upper) semaphore --------------------------------------------------
SCRIPT Sig25EHp_Sema1
	extern float	draw_state;
	extern float	def_draw_state();
	extern float	this_sig_lr();
	float 		state_lr;				//state for least-restricted state at the Signal-Position

	state_lr = this_sig_lr( SIGFN_NORMAL );		//find least-restricted state at the Signal-Position
	draw_state = def_draw_state( state_lr );		//set and draw light and semaphore to the found least-restricted state

//------------------------- 1925 Einfahrtssignal second (lower) semaphore --------------------------------------------------
SCRIPT Sig25EHp_Sema2
	extern float	draw_state;
	extern float	def_draw_state();
	extern float	this_sig_lr();
	float 		state_lr;				//state for least-restricted state at the Signal-Position

	state_lr = this_sig_lr( SIGFN_NORMAL );		//find least-restricted state at the Signal-Position
	draw_state = def_draw_state( state_lr );		//set and draw light and semaphore to the found least-restricted state

//------------------------- 1925 Einfahrtssignal Option 40 km/h --------------------------------------------------------------
SCRIPT Sig25EHp_Sema2_40
	extern float enabled;
	extern float block_state();
	extern float state;			
	extern float route_set();
	extern float draw_state;
	extern float def_draw_state();

	//  inactiv    or Block not free                               or Block obstructed by switch
	if ( !enabled || (block_state() !=# BLOCK_CLEAR) || (block_state() ==# BLOCK_JN_OBSTRUCTED) )
		state = SIGASP_STOP;			//state is STOP						(Hp0)
	else if (!route_set())				//straight track NOT reachable (semaphore 1 conected)
		state = SIGASP_APPROACH_1;	//state is APPROACH_1					(Hp2)
	else						//straight track reachable (semaphore 1 conected)
		state = SIGASP_CLEAR_2;		//state is CLEAR_2					(Hp1)
...

The two semaphores are separate INFO-signals which get its states by the function "this_sig_lr( SIGFN_NORMAL )".



And the animation-part in the signal-shape-file:

...	animations ( 1
		animation ( 2 30
			anim_nodes ( 3
				anim_node SIGNAL (
					controllers ( 0
					)
				)
				anim_node HEAD2 (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 -0.707107 0.707107 0 0 0 0 0 )
							tcb_key ( 1 0 0 -0.342336 0.939578 0 0 0 0 0 )
							tcb_key ( 2 0 0 -0.707107 0.707107 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0 8 -0.1 )
							linear_key ( 1 0 8 -0.1 )
							linear_key ( 2 0 8 -0.1 )
						)
					)
				)
				anim_node HEAD1 (
					controllers ( 2
						tcb_rot ( 3
							tcb_key ( 0 0 0 0 1 0 0 0 0 0 )
							tcb_key ( 1 0 0 -0.34202 0.939693 0 0 0 0 0 )
							tcb_key ( 2 0 0 0 1 0 0 0 0 0 )
						)
						linear_pos ( 3
							linear_key ( 0 0 10 -0.1 )
							linear_key ( 1 0 10 -0.1 )
							linear_key ( 2 0 10 -0.1 )
						)
					)
				)
			)
		)
	)

The animation-sequence is of 3 Frames whereby the third frame (2) is of the same values as the first frame (0). This is important for the using of SemaphorePos(0) and SemaphorePos(1) instead of SemaphorePos(1) and SemaphorePos(2). I know about the mismatch of the SemaphorePos settings in some routes. It is about the number of frames used here in the signal-shape. I'll can something say about it, but I'm afraid it takes a separat thread.


However, after I changed the order of the SignalSubObjs in the sigcfg.dat to the following the semaphores are working fine in OR (and still in MSTS):

...	SignalShape (
		"Sig25EHp.s"
		"1925 Formsignal 2 Flg Einfahrt"
		SignalSubObjs ( 10
			SignalSubObj ( 0	"SIGNAL"		"Hp2 40 km/h"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL JN_LINK DEFAULT )
				SigSubSType ( "Sig25EHp_Sema2_40" )
			)
			SignalSubObj ( 1	"HEAD1"		"FLUEGEL 1"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_Sema1" )
			)
			SignalSubObj ( 2	HEAD2"		"FLUEGEL 2"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Sig25EHp_Sema2" )
			)
		)
	)
...

Indeed, before I'll get fine working semaphores I have to rebuild the signals with the MSTS RouteEditor again, because the indexes in the tdb.dat have to be changed now too.
So I suppose it is all about the order (ranking) of how the scripts in the sigscr.dat are executed by OR. And this order seems to be depend on the order of the SignalSubObjs.

I have nothing against to share confidently the complete sig-files and signal-shape with some experts of the OR-project. But please bear with me that I won't publish it here at the forum.

Greetings!

[jonas]

What I know about the mismatch with the SemaphorePos-commands: SemaphorePos 0-and-1 or 1-and-2