[Tve4]

Yes, CROR does have aspects and indications for Advance Clear to Limited/Medium/Diverging/Slow/Restricting, where the next signal is Clear to Limited/Medium/Diverging/Slow/Restricting and the 2nd signal indicates a turnout speed.

Using a combination of INFO and SPEED signaltypes together with NORMAL signaltypes those aspects could be replicated even in situations where you have routes of different speed accessible from a single signal. It would require extreme care with signal links, and I would not necessarily distribute such a system. Also there would be some limitations: I think MSTS only supports up to 32 signal subobjects.

Since the system does not have any sort of diverging advanced approach indications (only the state of next signal on the diverging path is signalled) it would make scripting easier.

In CROR, Diverging Speed is indicated by the presence of an additional marker/sign on the signal mast and by displaying the same aspects as for Slow speed turnout, so it is not actually a different combination of visible lights, only an upgraded one.

The system is a speed-signalling system. What I gather from the available examples, if you pass a Slow to Stop signal there's not necessarily even a turnout: it just might be a very short block and you need to be on your toes because the next signal is at stop and located very very damn close indeed. :) I don't know if it is actually used that way, but such applications are common in other countries using speed-signalling systems.

Transport Canada - CROR > General Description and Location of Fixed Signals

[Jovet]

A pre-note to my reply... I'm sorry to see you've stepped down off of the Signal Post Rob, but your contributes to OR are and will continue to be greatly valued!

roeter, on 11 June 2014 - 12:53 AM, said:

The problem is that each track 'affected' by a speedpost is a separate speedpost item in the *.tdb file.
So changing which tracks are covered would require somehow changing the .tdb file. But, this carries the risk that if you edit the route again in the MSTS Route Editor, these changes are again reverted.
To avoid these risks, it has been agreed that no changes will be made to files which are automatically generated by MSTS tools, as long as these tools are still in general use. So changes to the .tdb are 'off limit'.

Yes, that is a very good point: quite the can of worms. I suppose my suggestion would be more appropriate for an OR Route Editor down the road.

roeter, on 11 June 2014 - 12:53 AM, said:

Is on the list (somewhere) - could well be possible, depending on the use of the 'state word' : if there are any 'spare bits', these could be used. (To explain : all user options are collected as bits in a single word). One serious problem to overcome is, ofcourse, the limitation of the MSTS Route Editor to set additional fields.

Yes, I've thought about that a lot as well. I suspect it would be pretty simple to add a second dword that MSTS would ignore, but it would still fail to cope with the extra (>32) SubObj entries. I suspect the future inevitable divorce of OR from the MSTS Route Editor may be the happiest divorce ever granted.

roeter, on 11 June 2014 - 12:53 AM, said:

That's more complicated. It would be quite an extensive program change, replacing enumeration types by a list or dictionary or something like that.
Also, the definition would become quite complex as for each state, a 'translation' to one of the basic states would still be required for processing of the states in the Track Monitor, cabviews etc.
It's not impossible, but it's a bit further down the list.

Well, in MSTS they're simple constants. My suggestion would be to simply expand the enumeration, keeping the core initial 8 values intact. Now that I think about it, I don't think there's really anything preventing us from doing that now with distinct values. One can specify SIGASP_CLEAR_2 or 7 in a script and it works the same (in MSTS). One could probably specify 53 and it would work, though the MSTS Track Monitor wouldn't know what to make of it. Hmmmmmmmmmmm.

Tve4, on 04 July 2014 - 04:15 AM, said:

Yes, CROR does have aspects and indications for Advance Clear to Limited/Medium/Diverging/Slow/Restricting, where the next signal is Clear to Limited/Medium/Diverging/Slow/Restricting and the 2nd signal indicates a turnout speed.
Using a combination of INFO and SPEED signaltypes together with NORMAL signaltypes those aspects could be replicated even in situations where you have routes of different speed accessible from a single signal. It would require extreme care with signal links, and I would not necessarily distribute such a system. Also there would be some limitations: I think MSTS only supports up to 32 signal subobjects.Since the system does not have any sort of diverging advanced approach indications (only the state of next signal on the diverging path is signalled) it would make scripting easier.
In CROR, Diverging Speed is indicated by the presence of an additional marker/sign on the signal mast and by displaying the same aspects as for Slow speed turnout, so it is not actually a different combination of visible lights, only an upgraded one.
The system is a speed-signalling system. What I gather from the available examples, if you pass a Slow to Stop signal there's not necessarily even a turnout: it just might be a very short block and you need to be on your toes because the next signal is at stop and located very very damn close indeed. I don't know if it is actually used that way, but such applications are common in other countries using speed-signalling systems.

I've programmed a fully-functional Canadian signal system for MSTS. I never finished programing the dwarfs, but the rest works. It is pretty complicated, but in the context of MSTS's limitations I'm very happy with how robust it is. Like my other mainstream signal systems, it uses all NORMAL signal heads on the wayside signals, and non-NORMAL control signals to tailor the behavior of the individual wayside signals for different situations. So it can be done. While it would be nice to have a single aspect value such as SIGASP_MEDIUM_TO_LIMITED which is not ambiguous and is easy to understand, it would still require programming each of the one to three signal heads to recognize and generate all of those values.

I think limiting each numeric aspect value to an 8-bit byte and defining roles for each nibble would be too restricting. Somewhere I had a document where I outlined all of the signal aspects I could think of and there were more than 16 of them. Not every signal aspect defines speed roles for the current signal and/or the next signal so all of those combinations would have to be figured out with special values reserved as well. A word+word system would have enough bits... but if one is going to go that route you could start assigning specific bits to mean certain things. Such as bit 30 set means a divergence, bit 29 set means a stop is required before passing the signal, etc. Plus there needs to be a way for the speed limit past the signal to be set with each aspect, and a way to define how far that speed limit extends. So, all in all, it sounds like more of a task for a future date with a dedicated Route Editor. After all these years I'm still impressed with how open-ended MSTS's signaling framework is and how much can be done with it.

[Howky]

hi, You can add new features to the dispatching application? If so, how?
Now I only have 4 states (basic)

http://s29.postimg.org/qym3667f7/napoveda.jpg

[raster]

I (again;)) ask for the type of signal that can be somehow controlled from Activity Editor (when such a rise for OR). It could work like this: in path editor would function (point) "start shunting path." Colour of the path would change to some other such blue and if the train went by on the path, instead of NORMAL types of work that the new signal types such as SHU (shunting busy;)), and semaphores NORMAL would go off. Upon completion of this course ("end shuntng path" in AE) would start back to work NORMAL types, and SHU were excluded.

This would give an ability to create maneuvers that in Poland are not dependent on normal semaphores and are controlled manually.

sorry for english :dance3:

[roeter]

It has been pointed out to me that the present TrainHasCallOn() function does not always work correct for certain signals.
The problem is that signals with call-on aspects can be used as entrance signals for stations, but also on 'free line' sections, that is away from stations.
The present function always allows call-on if the signal is on a 'free-line' section. This is to allow proper working for USA-type permissive signals.
Some signal systems however use these signals on sections where call-on is not allowed.

To sort out this problem, an additional function has been introduced in version 2592 : TrainHasCallOn_Restricted().

When approaching a station, both functions behave the same.
But on 'free line' sections, the TrainHasCallOn_Restricted() will never allow call-on.

So, in a nutshell :

• Use on approach to stations :
  
  • TrainHasCallOn() and TrainHasCallOn_Restricted() :
    
    • Activity : call-on not allowed
      
    • Timetable : call-on allowed in specific situations (with $callon, $stable or $attach commands)
  
  
• Use on 'free line' :
  
  • TrainHasCallOn() :
    
    • Activity and Timetable : call-on always allowed
    
    
  • TrainsHasCallOn_Restricted() :
    
    • Activity and Timetable : call-on never allowed

Regards,
Rob Roeterdink

[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