[roeter]

The blueprint linked below describes the proposal to introduce user-defined signal function types :
Signal function types

The introduction of signal variables extends the use of signals in such a way that in many situations it may be much more usefull to use signals for a specific action or definition.
For instance, to set a signal to a specific aspect on approaching a junction is now often done using the signal 'link'.
But only one link is possible, and therefor only one additional aspect can be defined.
Using 'route' signals (dummy signals on the various routes defining route specific details) allows much more variation, e.g. different aspects, information on speed, 'calling on' settings etc. There are already a number of signal definitions using such 'route' signals, but the present restricted number of possible signal function types limits the use of such additional signals.
This proposal lifts that restriction and will allow a much more varies use of signals.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 07 March 2017 - 03:23 AM, said:

The blueprint linked below describes the proposal to introduce user-defined signal function types :
Signal function types

My only comment from reading the blueprint is that, inside SIMIS-style files like sigcfg.dat, all of our existing extensions have been named like "ORTSNameOfItem" and you should follow that here, if it is not already (they are case-insensitive, but for documentation purposes the case is useful).

[roeter]

OK - will check on that.

Regards,
Rob Roeterdink

[Szilard]

Merry Christmas!

I'm trying to use the normal subtypes (which I find very useful), but something is wrong, maybe the syntax. The log does not showing any error in the sigcfg.dat file (Openrails subfolder) only the function calls (find_req_normal_signal, this_sig_hasnormalsubtype, next_sig_hasnormalsubtype, id_sig_hasnormalsubtype) report some 'Warning: sigscr-file line xxxx : Unknown ORSUBTYPE : EXIT' warnings.

Definition in sigcfg.dat:

SIMISA@@@@@@@@@@JINX0G0t______

ENTRANCE : ORNORMALSUBTYPE
EXIT : ORNORMALSUBTYPE

LightTextures ( 5

Allocation to a specific signal type:

SignalType ( "4F_Max40Hi"	
	SignalFnType ( NORMAL )
	EXIT : OR_NORMALSUBTYPE
	SigFlashDuration ( 0.5 0.5 )
	SignalLightTex ( "ltex" )
	SignalLights ( 6
		SignalLight ( 0 "Voros"	Position ( 0 5.654 0.25 )	Radius ( 0.78 ) )
		SignalLight ( 1 "Sarga"	Position ( 0 5.35 0.25 )	Radius ( 0.78 ) )

And the function call in sigcfg.dat:

SCRIPT 3F_AT

	float			next_state;
	float			sigid;

	next_state = next_sig_lr (SIGFN_NORMAL);		// köv. NORMAL jelző állapota
	sigid = find_req_normal_signal( ORSUBTYPE_EXIT );	// következő kijárai jelző keresése

Could you help me, what could go wrong, or provide an example, how should I use it?

Best regards,
Szilárd

[roeter]

Example : definition in sigcfg.dat
At top (before defining signal_types) :

ORTSNormalSubtypes ( 2
         ORTSNormalSubtype ( "MAIN" )
         ORTSNormalSubtype ( "SHUNT" )
)

Withing signal_type definition :

	SignalType ( "pt_bsig"
		SignalFnType ( NORMAL )
                ORTSNormalSubtype ( MAIN )

Regards,
Rob Roeterdink

[eugenR]

roeter, on 26 December 2018 - 04:27 AM, said:

Example : definition in sigcfg.dat
At top (before defining signal_types) :

ORTSNormalSubtypes ( 2
         ORTSNormalSubtype ( "MAIN" )
         ORTSNormalSubtype ( "SHUNT" )
)

Withing signal_type definition :

	SignalType ( "pt_bsig"
		SignalFnType ( NORMAL )
                ORTSNormalSubtype ( MAIN )

Regards,
Rob Roeterdink

So I hope, this Block (placed before the ORTSNormalSubTypes) is o.k. to define additional ORTSSignalTypes:

ORTSSignalFunctions ( 2
	ORTSSignalFunctionType ( "TESTA" )
	ORTSSignalFunctionType ( "TESTB" )
)

best regards
EugenR

[roeter]

Yes, that's good.

Regards,
Rob Roeterdink

[Szilard]

Hi!

roeter, on 26 December 2018 - 04:27 AM, said:

Example : definition in sigcfg.dat
At top (before defining signal_types) :

ORTSNormalSubtypes ( 2
         ORTSNormalSubtype ( "MAIN" )
         ORTSNormalSubtype ( "SHUNT" )
)

Withing signal_type definition :

	SignalType ( "pt_bsig"
		SignalFnType ( NORMAL )
                ORTSNormalSubtype ( MAIN )

Regards,
Rob Roeterdink

Thank you for your answer, now the warning is gone, altough, the signal does not work as I expected. I tried to use debug_header and debug_out functions for clarifying the values of some local variables and enabled state of a signal, but I did it not successeded (Do they work in OR at all?) I'd like to bind the lit/unlit state of some 'interval' signal (since it does not work continously) to the following normal signal with a certain subtype.
OR clears the signals on the path ahead, but what happens with the 'enabled' property of the signal, when the train passes this signal? Does it change back to false?

Best Regards,
Szilárd

[eugenR]

Szilard, on 25 December 2018 - 01:41 PM, said:

SCRIPT 3F_AT

	float			next_state;
	float			sigid;

	next_state = next_sig_lr (SIGFN_NORMAL);		// köv. NORMAL jelző állapota
	sigid = find_req_normal_signal( ORSUBTYPE_EXIT );	// következő kijárai jelző keresése

Could you help me, what could go wrong, or provide an example, how should I use it?

Best regards,
Szilárd

I have tried the function:
sigid = find_req_normal_signal(ORTSSUBTYPE_type)
it is working correct.
Have You realized, that all this Functions also has changed here Names from OR..... to ORTS.... ?
As mentioned by JamesRoss in Post#2

regards
EugenR

[Szilard]

eugenR, on 28 December 2018 - 02:51 AM, said:

I have tried the function:
sigid = find_req_normal_signal(ORTSSUBTYPE_type)
it is working correct.
Have You realized, that all this Functions also has changed here Names from OR..... to ORTS.... ?
As mentioned by JamesRoss in Post#2

regards
EugenR

Hi!

I've tried with the ORTS prefix, but log file (X4331) says: 'Warning: sigscr-file line 4172 : Unknown parameter in statement : ORTSSUBTYPE_BEJARATI'. With ORSUBTYPE_ prefix, warning message disappeared, so probably that's the right syntax. Normal subtype definition and allocation to signaltypes are based on your previous post. I read James Ross' post about prefix change, but I didn't know is it whether a recommendation or a fact, so I used the information in the blueprint.
However, OR_SCRIPT and ORTSSCRIPT looks working both in Sigcfg.dat (no warning either way).

Thank you for all your help!

Best regards,
Szilárd