OR not recognizing the MSTS .eng-file parameters "MonitoringDevice"-parameters

[Markus Gelbmann]

In MSTS the .eng-file parameters "MonitoringDevice..." work just fine, but OR seems to ignore them at leat partially.

For example: MonitoringDeviceResetOnZeroSpeed ( 1 ) in the alerter (VigilanceMonitor)section keeps the alerter quiet if the train doesn´t move (reverser neutral or brakes applied or both) in MSTS. In OR, however, emergency brake keeps kicking in at a standstill all the time if one forgets to regularly press the correponding button.

Discussed already over here ( http://www.elvastower.com/forums/index.php?/topic/21679-alerter-going-off-on-zero-speed/ ), I found out, that this feature hasn´t yet been implemented, but I was told to nevertheless report this as a "bug", or rather a "feature request".

Also affected with the MonitoringDevice parameters not being read are the Overspeed, AWS, EmergencaBrake etc. monitors.

[Peter Gulyas (pzgulyas)]

May I ask what is the role of AWSMonitor, and what should that do?

[James Ross (twpol)]

The AWS alerts you to the upcoming signal's state a few hundred meters before you reach it. In the UK, the system gives a short "ping" sound for clear (green) signals and a warning "bzzt" for other (yellow, red) signals which must be responded to quickly or the emergency brakes are applied.

Not sure how much of that is modelled by MSTS, though, and haven't played in MSTS for ages.

[r.roeterdink (r-roeterdink)]

The differences in AWS systems over various countries are such that it is impossible to capture the working of such systems with just an engine parameter.
It would at least require a whole set of route-related parameters on how the system would actually operate. And even that might not be enough - it could well be that signal-linked parameters are required to ensure the correct working, as in many countries different systems are in use side by side, with relative simple systems being used on branch lines and much more advanced systems for main lines, and almost full control on high speed lines. Many systems are linked in with in-cab signal displays.
Futhermore, there is ofcourse the history of development of these systems which should also be taken into account, with routes set up to represent the situation in the past having completely different systems as present-day routes would have.

So, my advice is to leave well alone and not consider implementation of AWS of any sort - until version 5.0 or something.

[James Ross (twpol)]

Whatever MSTS implements for this parameter - if it uses it at all - should be implemented in OR for 1.0. That's the plan and don't go diverging randomly like this please.

[Peter Gulyas (pzgulyas)]

Well, I couldn't find reference for MSTS, but in real life ( http://en.wikipedia.org/wiki/Automatic_Warning_System ) the signal state ahead should be checked 180 m before the train reaches it whether is restricted, and generate an alerter-like warning if needed.

However the existence of AWS is route-dependent, but it is defined as .eng parameter in MSTS, inconsistently. Also I think there is no easy way to check if we are 180 m before a signal...

[James Ross (twpol)]

If MSTS doesn't implement AWS, that's fine. I can't find anything suggesting it does it either, so I think we're okay to ignore AWS for now. Just implement the parameters that are documented in the MSTS Tech Docs, MSTSBin docs and the "Engine File 2.0" documents (I forget their exact name).

[Markus Gelbmann (gelbmann-markus)]

Does that mean the existing Alerter Monitoring device will also not be recognized? I somewhere in the above lost track of this all..

[James Ross (twpol)]

Sorry for the confusion, we got side-tracked with AWS. The target for Open Rails 1.0 is to implement all MSTS functionality, including the alerter monitoring.

[Markus Gelbmann (gelbmann-markus)]

That´s good to hear. especially as to me the difference between alerter and AWS was not quite clear until I now did some Research.

[Peter Gulyas (pzgulyas)]

Markus, the existing alerter monitoring device works already, since r1711. Just the implementation is not full yet, that's why I haven't closed this ticket. (I will finish it soon.)

[Markus Gelbmann (gelbmann-markus)]

Thanks for the News, another good Thing to hear. Although actually I did not mean this in my above post. ;)

[Peter Gulyas (pzgulyas)]

I implemented (at least tried to implement) the majority of the MonitoringDevice parameters in r1732. Now I close this ticket, but I kindly ask everyone to submit a new ticket if something works differently than expected.