[Jovet]

Very interesting. :D A few comments:

For the "Speed" type signal, would it be better to be able to allow the number of "covered" tracks of the existing speedpost interactives to be, somehow, manually adjusted?

I see the new functions the scripts are calling do not have to be declared:
extern float newfunction()
Does this also mean none of the other function calls need to be declared? (Does OR care about such things?)

What further plans for expansion are in the near future?
Additional user options? (USER5, USER6, etc)
Additional detecting functions? (for example, block_reverse_state() for detecting track state in front of the signal versus behind it, such as for approach lighting)
Additional indication states? (SIGASP_APPROACH_MEDIUM, SIGASP_CALL_ON, SIGASP_DIV_CLEAR etc)
Just curious. :)

[roeter]

jovet, on 10 June 2014 - 05:58 PM, said:

For the "Speed" type signal, would it be better to be able to allow the number of "covered" tracks of the existing speedpost interactives to be, somehow, manually adjusted?

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'.

Quote

I see the new functions the scripts are calling do not have to be declared:
extern float newfunction()
Does this also mean none of the other function calls need to be declared? (Does OR care about such things?)

That is indeed so - "extern float" is quietly ignored by the OR script parser. Local floats do, ofcourse, have to be declared - allthough the word 'float' is very misleading as in fact all variables are integers (many are enumerations, actually).

Quote

What further plans for expansion are in the near future?
Additional user options? (USER5, USER6, etc)

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.

Quote

Additional detecting functions? (for example, block_reverse_state() for detecting track state in front of the signal versus behind it, such as for approach lighting)

The 'internal' used blockstate already has many more states than the three basic states used in MSTS, so allowing the use of these additional states would be fairly easy.
As for approach lighting - could that not be set up already using the approach control function?

Quote

Additional indication states? (SIGASP_APPROACH_MEDIUM, SIGASP_CALL_ON, SIGASP_DIV_CLEAR etc)

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.

Regards,
Rob Roeterdink

[Tve4]

Great! The speed signal is what I've been waiting for.

Now could we have a trigger signal as well, one that I mentioned somewhere... Basically a dummy (INFO or similar) signal which has a fixed function to operate as a SignalNumClearAhead Zero. Would be useful for longer lines without intermediate block signals, and if it were a simple separate signaltype I wouldn't have to edit a wide array of scripts to include ApproachControl, but instead I could drop a separate signaltype onto a route.

Basically this signal would be a trigger for the signal system to keep signals at a station at stop until an approaching train has passed the trigger. After passing the trigger, the signal script would operate as any normal MSTS or OR signal script. It would make the meets a bit realistic, when the trains would not have signals cleared into the station too early, but instead the first to arrive would get the siding (if passing paths are set). It would also be realistic operation since automatic dispatching aids support the trigger-type route setting, usually triggered by a presence of a train in a track circuit.

A question:
Can a NORMAL signal (within openrails signal script) be set to perform a query of the least favourable speedsignalstate between it and the next NORMAL signal, so that there would be no need to create signal links for both the NORMAL and SPEED signal (to show correct aspects)? If it is not yet a supported feature, I suggest that you do some research if it can be made. I have a situation where the train negotiates through a series of switches at different speeds. ATC enforces the speeds per turnout, but the entry signal displays the most restricting speed limit)

[Howky]

I have question , how add into ORTS

APPROACH_2
APPROACH_3
CLEAR_1
CLEAR_2

and other?


you write : Signal function (reduced to show use of approach control only).
This function uses approach control for the 'lower' route.

[StevenMasters]

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

Quote

What further plans for expansion are in the near future?
Additional indication states? (SIGASP_APPROACH_MEDIUM, SIGASP_CALL_ON, SIGASP_DIV_CLEAR etc)

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.

Regards,
Rob Roeterdink

The problem we have here with GCOR and CROR signals is that many of the indications also tell you what the second signal is. In CROR, MED to CLR (R/G/R) is next signal is MED and the signal following that (2nd signal) is CLR. There are enough signal enumerations now if we had access to a two dimensional array. The enumerations we have are 0-7 which use 3 bits, so there are 5 wasted bits even if you are using an unsigned byte to represent each signal state. How about the following:

0xNS - signal state

N - is the next signal state as we use it now

S - next signal state beyond the 'N'

cab_signal = signal_state >> 4;

This would preserve the current list of signal enumerations and allow for expansion in the future (aspect values of 8-15). Would this approach work?

[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