[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: 532

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.

[copperpen]

gpz, on 24 October 2013 - 09:48 PM, said:

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.

Yes it would be dangerous to allow this. It is one thing to develop new parameters with data that OR can read, but another thing entirely to develop new parameters with new assigned triggers. Something similar has already happened with the multiplayer use of the T key for texting. This key is actually used by MSTS for activating the refuelling process with steam and diesel engines.

[gpz]

Csantucci, on 25 October 2013 - 01:28 AM, said:

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.

I think let the sounds just be as sounds, as it was till now. The behavior of the train protection system should not be set in cvf, rather in eng as you said, but that is more or less independent of the sounds.

Csantucci, on 25 October 2013 - 01:28 AM, said:

What I like in Rob's proposal is the policy underneath, that is to provide a parameterizable solution, that can be extended in parallel to identification of new needs.

Yes, a limited set of events would be the way I think, and the set should cover all possible use cases.

[Csantucci]

gpz, on 25 October 2013 - 02:39 AM, said:

I think let the sounds just be as sounds, as it was till now. The behavior of the train protection system should not be set in cvf, rather in eng as you said, but that is more or less independent of the sounds.

It's better to examine some real cases. In general the relationship between cab and visual and acoustic warnings and the train protection system is quite tight. It is some visual and/or acoustic warning that leads the train driver to acknowledge the alerter. And the visual/acoustic warning is stopped when the train driver acknowledges the alerter. And then there are the visual and/or acousting infos, that do not require train driver acknowledgement.
To make a practical and near to me example: in the Italian RSC (continuous signal repetition in cabview) system things work this way, roughly speaking:
- when next signal is not clear and does not have a less restrictive aspect than the just passed, the acoustic warning (alerter) is triggered and the train driver must acknowledge;
- when next signal has a less restrictive aspect than the just passed, there is an acoustic info (no need for the train driver to acknowledge)
- when next signal is clear and the just passed is also clear, there is no acoustic info.
So, how to provide the hooks for the acoustic info in these three different cases? I see only two ways:
1) defining many different trigger numbers for every specific case of every national system, and coding all the hooks to them
2) parametrically define them in the train control system definition, and so needing less trigger numbers.
Are we sure that the first solution is better?

P.S. Peter, referring to the RESET TWO_STATE applied in front of other control blocks within .cvf, pls. wait to proceed. I made a test, and I'm not so sure that what is affirmed in the trainsim forum thread corresponds to reality. At least with MSTSbin the alerter count is reset by moving certain controls also without needing to insert that line in the .cvf file. Sorry for confusion, but I'm in an exploring phase.

[gpz]

I modified the speed limit displaying cabview controls in r1831 to show the signalling limits only, moved the whole code from Train.cs to TrainControlSystem.cs, and fixed the crash Pedro reported.

As a proof of concept, and to ask what are your opinions about it, I implemented some functions of EBICAB, like showing the current speedpost limit, switching off when the next signal speed is higher than current, allowing to release brake after overspeed emergency application in case the speed is within limit again. This is completely inactive, cannot be switched on by any option, the only way to activate it is to replace the line "TrainControlSystem = new MSTSTrainControlSystem(this);" in MSTSLocomotive.cs by "TrainControlSystem = new EBICAB(this);", and recompiling. The related code is at the end of TrainControlSystem.cs file.

[roeter]

Sorry to cause confusion, but the parameters etc. I mentioned earlier were only intended as examples of what could be done.
Carlo mentioned somewhere that he wanted to add sound events relating to monitoring, and that is what I was referring to.
As for including these in the cvf : there is indeed a strong, direct link to the change of the monitor indication, and the related sound. These cannot be separated. It seems reasonable to define them in the cvf file, as they must be processed as part of the monitor processing itself. They could also be defined in the sound files, but that would make it more complicated.

As I see it, these steps now need to be taken :

• Create a set of sound events which can be used for signal and speed monitoring functions. This can be an 'open' set, that is the events as such are not linked to a function - these could be defined as 'reserved for signal monitor'.
  Note that the actual sound file linked to these events must be defined in the engine's sound files.
  
• Define the list of parameters which will be required to cover most common systems (i.e. the systems we know).
  We can, at the moment, only hope that this will be sufficient to cover all possible systems, but .... ;)
  
• Finally just implement the code :D

Regards,

Rob Roeterdink