[gpz]

 Csantucci, on 24 October 2013 - 05:41 AM, said:

I have already mentioned the RESET_TWO_STATE keyword in .cvf files as something still missing in ORTS.

Carlo, it already works for a long time, doesn't it?

[Csantucci]

The attached small activity with standard Acelas on route USA1 shows what MSTS does and ORTS does not do referring to signal state monitoring. The player train has in front of itself a signal with a restrictive aspect and speed set to 45 MPH. After passing this first signal, next signal has a more restrictive aspect and speed is set to 30 MPH. In both MSTS and ORTS I have selected the alerter in the options. MSTS triggers the alerter after passing the first signal, and if it is not acknowledged the train gets a stop. ORTS does not trigger the alerter. It is the VigilanceMonitor that activates this job.
 aftstrm_test6.zip (4.23K)
Number of downloads: 441

P.S. Peter, I admit that I looked in the .cs files for RESET_TWO_STATE instead of RESET TWO_STATE ;) however I ask you if RESET TWO_STATE is recognized by ORTS also in a block like this one:

Lever (
Type ( RESET TWO_STATE )
Type ( TRAIN_BRAKE LEVER )
Position ( 438 345 56 67 )
Graphic ( automaticbrake.ace )
Style ( NONE )
MouseControl ( 1 )
NumFrames ( 12 4 3 )
NumPositions ( 5 0 1 7 8 9 )
NumValues ( 5 0 0.3 0.85 0.9 0.95 )
Orientation ( 1 )
DirIncrease ( 1 )
ScaleRange ( 0 1 )
)

that is within a block having also another function.

[gpz]

I don't think so. I have never saw anything like this before. What's the purpose of this?

[Csantucci]

This is explained in a topic I linked some posts ago
http://www.trainsim....hlight=MSTS+AWS
As explained there, inserting that line on top of a block of a control resets the alertert count. This is very prototypical, because if the train driver is moving controls this means that he is alive, and so this feature is present in real cases.

Reading the MSTSbin manual I found it has implemented the CTRL-Numpad4 key, that toggles on and off alerter operation. I think this is a quite useful feature, that I would like to see also in ORTS.

[gpz]

Okay, now I see. This is the current behavior in ORTS without these lines too. An other thing I don't like, since in my country there is no such feature on any locomotives, as far as I know. ;)

[Csantucci]

I have made some tests with the AWSMonitor block. I wasn't able to find any difference if it is there or not (same for the EmergencyBrakeMonitor block). Maybe there's one, but it's hard to find.
Timing of the alerter when triggered by a more restrictive signal ahead is governed by the difference between MonitoringDeviceMonitorTimeLimit and MonitoringDeviceAlarmTimeLimit pertaining to the VigilanceMonitor block. This difference states the time interval between starting of the alerter sound and display and the application of the penalty (emergency braking or whatever other thing has been defined). I wasn't able to find the parameter that governs the time between discovery of new signal state and starting of alerter sound/display.
Also the applied type of penalty is the one defined in the VigilanceMonitor block.
This is probably the reason why in the page about the Monitor blocks within Realmuto's eng manual the authors have commented "Kuju’s brake guy was lazy."

For the moment, if there aren't specific requests or needs, I don't foresee further analysis on MSTS behaviour in this field.

I hope Peter will tackle the problem of implementing this alerter function linked to more restrictive state of next signal... ;) and after that I think it is the good moment for me to foresee sound additions where useful.

[roeter]

As it is possible to add our own CVF definitions, why not create specific definitions for sounds in the SPEEDLIMIT definition?
This could define the sound trigger which, in turn, through the engine's sound definition, triggers the correct sound.

Suggestions for such definitions :

ORTS_EventOnSpeedRestriction ( xx ) # in which xx is the related trigger
ORTS_EventOnSignalStop ( xx )
ORTS_EventOnAspectBelow ( aspect xx ) # in which aspect is the highest SIGASP definition for which this trigger is activated

And there can be a lot more like these. The event would be triggered at the same time as the display changes, and just once.

Regards,

Rob Roeterdink

[cjakeman]

 roeter, on 24 October 2013 - 11:49 AM, said:

ORTS_EventOnSpeedRestriction ( xx ) # in which xx is the related trigger
ORTS_EventOnSignalStop ( xx )
ORTS_EventOnAspectBelow ( aspect xx ) # in which aspect is the highest SIGASP definition for which this trigger is activated

Proposals for new parameters on this and other threads seem to be springing up like mushrooms :-)

Just a word of caution - anything we create today will probably persist for many years to come. MSTS contains lots of poorly named and even misspelled parameters. Some are too narrowly targeted and should have been more carefully considered.

As the old saying goes, "Those who marry in haste, do repent at leisure."

[gpz]

 roeter, on 24 October 2013 - 11:49 AM, said:

Suggestions for such definitions :

ORTS_EventOnSpeedRestriction ( xx ) # in which xx is the related trigger
ORTS_EventOnSignalStop ( xx )
ORTS_EventOnAspectBelow ( aspect xx ) # in which aspect is the highest SIGASP definition for which this trigger is activated

And there can be a lot more like these. The event would be triggered at the same time as the display changes, and just once.

Wouldn't it be dangerous to let users assign their own trigger numbers? We could end up not being able to assign our own later, because we could never know if that number was already in use.

[Csantucci]

Peter,
you're right with your remark about trigger numbers. This must be carefully considered. Maybe we could allow inserting previously fixed trigger names, corresponding to predefined numbers, or we could leave a certain trigger number range free, but this still again has to be carefully evaluated before taking a decision.
I also wonder if the .cvf file is the right place for this. In many cases the sound is linked with a request of acknowledgement, that in turn usually leads to train trip if no acknowledgement arrives. So maybe the .eng file is better suited.
What I like in Rob's proposal is the policy underneath, that is to provide a parametrizable solution, that can be extended in parallel to identification of new needs.