[markus_GE]

:bigboss: for the probably silly question, but what kind of functionare you talking about? Something that only concerns ORTS code, or something that goes into the sigscr.dat file, or...?

Cheers, Markus

[roeter]

TrainHasCallOn() is a function which can be used in the sigscr file to check if a train is allowed to 'call on' into a platform - that is it is allowed into a platform where there already is another train.
It is linked to the $CallOn command which can be used in timetables - this sets that a train is indeed allowed to 'call on'.

Regards,
Rob Roeterdink

[markus_GE]

:bigboss: for the explanation :)

Cheers, Markus

[roeter]

Two new signal-script functions have been introduced in version 2780, which can be used in the ORTS-version of sigscr.dat.

NEXT_NSIG_LR
This function is similar to NEXT_SIG_LR, except that it returns the state of the nth signal ahead.

Function call : state = NEXT_NSIG_LR(MstsSignalFunction fn_type, int n).
Returned value : state of nth signal ahead, except :

• When there are less than n signals ahead of the train.
  
• when any of the intermediate signals is at danger.

In those situations, the function will return SIGASP_STOP.

Usage : take, for instance, the sequence of signals as shown below.

The distance between signals B and C, as well as between C and D, is shorter than the required braking distance. Therefor, if D is at danger, both C and B must show yellow; similar, if C is at danger, both B and A must be yellow.
Problem now is what aspect should be shown at A : if B is yellow, is it because C is at red, so A must also be yellow, or is it because C is at yellow as D is at red - in which case A can show green. One could, ofcourse, use two different states for yellow at C, but that soon gets rather complicated, and also one might soon run out of available aspects.

With the new function, it becomes more easy : if B is at yellow, A can directly check the state of C, and so decide if it can clear to green or must show yellow.
Suppose state SIGASP_STOP shows red, SIGASP_APPROACH_1 shows yellow and SIGASP_CLEAR_1 shows green for all signals, the related part of the script could be as follows :

if (next_sig_lr(SIGFN_NORMAL) == SIGASP_APPROACH_1)
{
    if (next_nsig_lr(SIGFN_NORMAL, 2) == SIGASP_STOP)
    {
        state = SIGASP_APPROACH_1;
    }
    else
    {
        state = SIGASP_CLEAR_1;
    }
}

The function is also very usefull when a distant signal is to reflect the state of more than one home signal, but dist_multi_sig_mr cannot be used because there is no distant signal further on.

HASHEAD
This function can be used for any optional SIGNAL_HEAD as defined for the relevant signalshape in sigcfg.dat, to check if that had has been selected for this signal or not.
Using 'DECOR' dummy heads, this allows these heads to be used as additional user settings, and as such are kind of extention to the four available SIGFEAT_USER flags.
Please note that this function is still experimental.

Function call : state = HASHEAD(headname);
Function returns 1 if head is set, else 0.

Regards,
Rob Roeterdink

[mauried]

This is a really cool feature.
Is there an upper limit on Int N , ie how far ahead signal wise can be searched?
Thanks

[roeter]

No, there is no upper limit.
But, if you test beyond the number of signals cleared because of the value of SignalNumClearAhead, then clearly the result will always be that the signal is at danger - so there is a practical limit.

Regards,
Rob Roeterdink

[VicenteIR]

Hello

Can the signal to "know" aspect of the previous signal?
I mean ... I have a shunting signal located between the entrance signal and first switch. The shunter works at two modes: Shunting mode and Route Mode. The Route mode is set up when entrance signal is clear. In MSTS I did this by setting marker before the entrance signal turned at opposite direction and the marker caught an aspekt of entance by using function opp_sig...(). In his turn,the shunter worked according to the function opp_sig...() too about the marker. In OR it does not work due to the fact that the signals behave differently unlike MSTS (functions enabled() and opp_sig...().
Can you suggest any other way to implement this situation or it is not possible in OR "to see" previous signal.

Thank you and sorry for my english

[raster]

Is it possible, to add a new variable type, which at the end of script remembers own value and restores it at the new script processing (for each script separately)?
example:

SCRIPT TEST

extern float draw_state;
new float x;

x+=1;
if (x == 9)
{x=0;}
draw_state = x;

at each script processing signal change

And second question: what else not working properly in scripts?

Cheers

[eugenR]

VicenteIR, on 25 April 2015 - 07:45 AM, said:

Hello

In OR it does not work due to the fact that the signals behave differently unlike MSTS (functions enabled() and opp_sig...().

Enabled:
In OR this Function work for all type of Signals.

In MSTS the Function enabled works only for the SignalType NORMAL
For that reason, in the MSTS-Signal-Script for non-NORMAL Signals can't exist any Enabled-Function, so this modified function can't made a difference in the Functionality between MSTS an OR.

Opp_Sig...:
In my case Function opp_sig.. work in OR, so as in MSTS. A SignalType NORMAL ask a SignalType DISTANCE in the opposite direction.
But if I understand correct, Your Functionality is based on two sequentially Functions of opp_sig...
Perhaps OR has a difference with the sequential processing of this two functions.

[roeter]

raster, on 31 May 2015 - 08:20 AM, said:

Is it possible, to add a new variable type, which at the end of script remembers own value and restores it at the new script processing (for each script separately)?
example:

SCRIPT TEST

extern float draw_state;
new float x;

x+=1;
if (x == 9)
{x=0;}
draw_state = x;

at each script processing signal change

The values state and draw_state are stored with the signal.
So, in your example, you can start with : x = draw_state.
However, you must take care that a script is not just only run when the signal aspect changes - it is run continuously.
So if you want something specific happening when the aspect changes, you have to use a local variable which is set to a copy of the present state at the beginning of the script, then work out what the state is supposed to be at this moment, and then compare this to the said copy, e.g. :

prevstate = draw_state;

ownstate = SIGASP_STOP;  // new state
.
. logic for new state
.

if (prevstate != ownstate)
{
.
. state has changed
.
}

Quote

And second question: what else not working properly in scripts?

What do you mean by "what else"?

All functions work.
There are only some limitations on specific syntax (e.g. x+=1 in your example won't work - that needs to be x = x + 1).
That is due to the fact that for OR a parser had to be created from scratch, it was not possible to use some kind of compiler pre-processer or whatever as was used for MSTS. So the rules were simplified a bit. But that does not affect actual usage - as, clearly, for instance, the result of x+=1 and x = x + 1 is the same. That goes for all syntax limitations like the use of { } and ( ) in IF statements.
It's all just cosmetic, it does not change the functionality.

Regards,
Rob Roeterdink