[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

[eugenR]

Hi,
You are right also in my case only no warning in Logfile with ORSUBTYPE ( TEST )!! (Sigid will be set to > 0)
But also with ORTSSUBTYE( TEST ) the value Sigid is set to > 0 (plus warning), if the next Signal has ORTSSUBTYPE (TEST).
Surprizing I can write any Nonsens between the brackets instead of TEST,
the value sigId = find_req_normal_signal( XYZ ) will be set to true!!!

Sigcfg.dat:

ORTSNormalSubtypes ( 1
         ORTSNormalSubtype ( "TEST" )
)
SignalTypes ( 125

		SignalFnType ( NORMAL )
		ORTSNormalSubtype ( TEST )

Sigscr.dat:

Sig	sigid = -1;
	sigid = find_req_normal_signal( ORSUBTYPE_TEST );      
	if (!enabled ||								// Not enabled/cleared to show natural state?
		block_state() !=# BLOCK_CLEAR ||				// Block ahead not clear?
		!route_set() || sigid <=# -1 )							// Switch not set as per link?
	{
		state = SIGASP_STOP;
	}
	else
	{
		state = SIGASP_CLEAR_2;
	}
	draw_state = def_draw_state (state);scr.dat:

Edit:
SigId seems not to be equal to:

SignalItem (
		TrItemId ( 1 )

in the *.tit of the route, it seems to be a OR-internal ident, what should be retrived before by sigid = next_nsig_id(SIGFN_Type, <n>)

[Szilard]

Hi!

Thank you for your reply. Inspecting the source code of OR I realized, find_req_normal_signal is not the function, that I can achieve my goal with. It's only working along the path until the train passes the signal.
I'd like to accomplish, let the automatic block signals be lit only if the following entrance signal is enabled by the train (the last ABS is always lit):

..Train-->ABS(1)-->ABS(2)-->ABS(3)-->ABS(4)-->ABS(5)-->Entrance Signal-->switches-->Station-->...

ABS has SignalNumClearAhead=-1, so train always clear the route to at least the next non-ABS signal.
My problem is, when the train passes ABS1, find_req_normal_signal always give -1 back, thus the signal become unlit too early:

sigid = find_req_normal_signal ( ORSUBTYPE_BEJARATI );
nextnormsub_enabled = id_sig_enabled (sigid);
if ( !nextnormsub_enabled )
    { state = SIGASP_STOP; draw_state = 5; }

The solution is to add a custom typed signal head to the entrance signal to send back the enabled status. Unfortunately, in case of an existing route, every same kind of signal has to be deleted and placed again. Another solution is to implement a function, which seeks proper normal subtype signal in tdb, regarding the current position of switches and not the path...
Thank you for your help again, and Happy New Year to everyone!

Best regards,
Szilárd

[roeter]

Szilard, on 31 December 2018 - 08:00 AM, said:

Hi!

Thank you for your reply. Inspecting the source code of OR I realized, find_req_normal_signal is not the function, that I can achieve my goal with. It's only working along the path until the train passes the signal.
I'd like to accomplish, let the automatic block signals be lit only if the following entrance signal is enabled by the train (the last ABS is always lit):

..Train-->ABS(1)-->ABS(2)-->ABS(3)-->ABS(4)-->ABS(5)-->Entrance Signal-->switches-->Station-->...

ABS has SignalNumClearAhead=-1, so train always clear the route to at least the next non-ABS signal.
My problem is, when the train passes ABS1, find_req_normal_signal always give -1 back, thus the signal become unlit too early:

sigid = find_req_normal_signal ( ORSUBTYPE_BEJARATI );
nextnormsub_enabled = id_sig_enabled (sigid);
if ( !nextnormsub_enabled )
    { state = SIGASP_STOP; draw_state = 5; }

That is correct. The function find_req_normal_signal uses the train's path to check for the required signal. Once the train has passed the signal, that signal no longer has a path to check so it can never find the required signal.

Quote

The solution is to add a custom typed signal head to the entrance signal to send back the enabled status. Unfortunately, in case of an existing route, every same kind of signal has to be deleted and placed again. Another solution is to implement a function, which seeks proper normal subtype signal in tdb, regarding the current position of switches and not the path...

There is no need for additional heads if you want a signal to pass on additional information.
Signals can now also have variables - these variables can be set by the signal itself, and can be read by any other signal. There is no limit to the number of variables a signal can have. I'm sorry that this information has not yet found its way into the manual, so I have attached the blueprint information in which these functions are detailed.

I think your problem can be solved quite easy using these signal variables.
This could be done in the following way.

Entrance signal : sets variable (variable 1) as enabled state (1 = enabled, 0 = not enabled) :

store_lvar(1,0);
if (enabled)
{
   store_lvar(1,1);
}

ABS signal : get value of variable 1 from next signal and store it as variable 1, so it is also available for the preceeding signal :

store_lvar(1,0);
enabledvalue = next_sig_lvar(SIGFN_NORMAL,1);
store_lvar(1,enabledvalue);

The only disadvantage of this method is that on startup, the enabled state of the EntranceSignal is not yet available for all ABS signals.
Worst case, the signals are updated in the direction of travel so each update, one signal only is properly updated. Depending on the number of ABS signals, it could be a minute or so after starting or restarting before all ABS signals have obtained the correct enabled state.

 additionalsignalscriptfunctions.htm (50.7K)
Number of downloads: 571

Regards,
Rob Roeterdink

[James Ross]

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

That only applies to SIMIS files - the ones with parentheses around blocks (e.g. "Foo ( Bar ( ... ) )") like sigcfg.dat, and not sigscr.dat, which is in a weird simplistic dialect of C instead. In some ways it would make sense for everything OR-specific in sigscr.dat to also be prefixes ORTS (e.g. "orts_new_function()") but we missed any opportunity to do that ages ago.

[Szilard]

Hi!

roeter, on 03 January 2019 - 03:39 AM, said:

There is no need for additional heads if you want a signal to pass on additional information.

The only disadvantage of this method is that on startup, the enabled state of the EntranceSignal is not yet available for all ABS signals.
Worst case, the signals are updated in the direction of travel so each update, one signal only is properly updated. Depending on the number of ABS signals, it could be a minute or so after starting or restarting before all ABS signals have obtained the correct enabled state.

Thank you for your good idea, it seems working combined with your previous drawstate tip. I tried it with a bigger route and find no delaying. Even if this will happen, then AI trains going to start several seconds later.

Best regards,
Szilárd