[Csantucci]

An action has been started to achieve enhanced OR compatibility with existing MSTS activities. The changes in activity behaviour are at the moment operating only if the new checkbox "Enhanced compatibility with MSTS activities" in the Experimental tab is checked.
In release 2341 the first issue has been addressed, that is the management of the dependency of the AI train maxspeed from the efficiency/performance parameter as set in the MSTS activity editor.
The MSTS behaviour is as follows, as partially documented in the American trainsim forum and retested by myself:
If the AI train does not make station stops, its maxspeed (not considering signal, speedpost and route speed) is given by the first MaxVelocity parameter in the .con file, expressed in meters per second, multiplied by the "Default performance" parameter (divided by 100) that can be found and modified in the MSTS AE in the "Service editor". Such parameter divided by 100 is written by the AE in the .srv file as "Efficiency".
If the AI train makes station stops, its maxspeed depends from the "Performance" parameter for every route section, as can be seen and defined in the AI train timetable (that is maxspeed is the product of the first MAxVelocity parameter by the "Performance" parameter divided by 100).
Such performance parameter list is written (divided by 100) by the AE in "Service_Definition" block in the activity editor, again as "Efficiency" (for every station stop).
The rule followed by MSTS is as follows: from the starting location of the AI train up to the first station, the "Performance" linked to such station is used; from the first station to the second one, the "Performance" linked to the second station is used and so on. From the last station up to end of path the "Default performance" mentioned above is used.

This behaviour has now been implemented in OR.

There is a certain amount of further issues to achieve better compatibility. I hope that with time at least the most impacting will be addressed.

[markus_GE]

Sounds like a great start, Carlo :)

However, AFAIK, there was something more to AI speed control, which has to do with the second number in MaxSpeed. I hope I can still find the info, but really have no clue where to look... Hopefully Google will help ;)

Cheers, Markus

[markus_GE]

Follow up: I even had a bookmark on it ;)

http://msts.steam4me...s/ai_speed.html

Cheers, Markus

[Csantucci]

Thanks Markus.
The second MaxVelocity parameter defines how AI trains reduce speed in curves, but there isn't a precise formula on how this is done. I don't have the intention to address that, because behaviour in curves should be more related to physics than to .con parameters, and anyhow it provides only second order compatibility improvements.

P.S. messages crossed.

[markus_GE]

Reading the information linked above, the formula simply goes like this:

MaxSpeedAfterEfficiencyFactorMultiplication * SecondParameterOfMaxVelocity = MinimumVelocityThroughCurvesAndOnGrades

Somehow, however, grades and so on will have to come into play for Speeds between Max and Min. No info on that in the link I posted, however.

Quote

behaviour in curves should be more related to physics than to .con parameters

Probably better that way, in order to keep train speeds somewhat reasonable.

Cheers, Markus

[Buttercup]

My experience with the "second" MaxVelocity factor is with introductory train rides (ITR) or automatic operation in MSTS. The second factor affected acceleration and braking. Reducing the value greatly smoothed the performance of the ITR train. The value set by MSTS was almost always to big. The ITR would over speed causing rapid braking which would lead to over speed causing rapid braking etc etc. Reducing the number reduced or eliminated the problem.

I have used the inter-station efficiency many times in MSTS to time ai between stations. Good to have it back.

[captain_bazza]

There was mention of Marias Pass, however, the mountain grades on this (default) route are inaccurate in places by as much as +3%, making proper tsting of physics impossible.

IMO, an OR activity editor needs to be user friendly. It must be remembered, that according to early rumour, the default MSTS tools/utils were originally intended for inhouse developers' use only. I believe they decided to bundle them when it was realised that without user tools the sim would go nowhere. [citation - required]

That might explain the relatively basic nature of the tools and the dire lack of documentation, or support, from the date of release. (There were a couple of fixes included with the only official patch.)

Cheers Bazza.

[markus_GE]

captain_bazza, on 13 July 2014 - 05:07 PM, said:

There was mention of Marias Pass, however, the mountain grades on this (default) route are inaccurate in places by as much as +3%, making proper tsting of physics impossible.
[...]

So there is a decision to be made: Should a fall-back MSTS-like AI handling mode be introduced to, just like in MSTS, allow underpowered AI´s t just motor up any grade too steep for normal physics, should this be the standard handling of AI in enhanced-compatibility mode, or should it be left to the user to correct such obvious set-up errors in an activity?

Cheers, Markus

[roeter]

The experimental flag for enhanced compatibility must be set to 'off' by default when running in timetable mode.

Details for this compatibility are taken from the activity definition, but clearly there is no such data in timetable mode. Therefor, checking this information when the flag is set leads to a program crash - see attached log file :  OpenRailsLog.txt (11.4K)
Number of downloads: 530

Regards,
Rob Roeterdink

[markus_GE]

Is there a way to simply bypass the compatibility setting when running a timetable? I guess, this would be the best option...

Cheers, Markus