[Fred]

I've looked for this bug in this forum and I can't believe that nobody reported it before. The activity timing is different between MSTS and OR.

For example, an MSTS activity has you waiting at a station until an oncoming train gives up the single track ahead of you. As soon as the train gives up the track you get a green to proceed. With OR the oncoming train is not there and you have a green signal. However, the train is waiting for you at the next passing siding further up the track.

That is only one example. In short I have found that the AI traffic timing is not the same for MSTS and OR.

[gpz]

It will never be the same. It is impossible to write it to be the same without actually having the same code, which is kept secret my MS. The best practice is to set up the activities specifically for OpenRails.

[farrmp]

Actually it has been discussed extensively here on ET and other sites.
Do a search on roeter (Rob Roeterdink) here in the Open Rails section.
Because MSTS Signaling and Train Control is a 'Black Box' it is impossible to
to duplicate it even if you wanted to. The work that Rob and others have done
is outstanding and amazing (no more 'cornfield meets' for me) and where necessary
those Activities that aren't quite right can be modified to work pretty much 'as
they did in MSTS' without too much trouble (More about that in some of the
threads you will find in your search.

Paul

[Lindsayts]

 Fred, on 08 January 2014 - 11:21 AM, said:

I've looked for this bug in this forum and I can't believe that nobody reported it before. The activity timing is different between MSTS and OR.

For example, an MSTS activity has you waiting at a station until an oncoming train gives up the single track ahead of you. As soon as the train gives up the track you get a green to proceed. With OR the oncoming train is not there and you have a green signal. However, the train is waiting for you at the next passing siding further up the track.

That is only one example. In short I have found that the AI traffic timing is not the same for MSTS and OR.

As stated in the above replies this is a know issue. The problem (one of them anyway) is that in MSTS the AI train physics is VERY basic where as in OR it effectively uses the same as the users train physics, so the timings will almost certainly always be different. Hopefully when OR's own activity editor is developed this will allow existing activities to be edited to correct the situation.

Lindsay

[dennisat]

 farrmp, on 08 January 2014 - 12:05 PM, said:

..Activities that aren't quite right can be modified to work pretty much 'as
they did in MSTS' ....

I've found that usually very little modification is necessary and with a little thought, the acts will still run OK in MSTS as well. One of the biggest nuisances I've found are acts where the AI does not have a proper timetable. In some acts I've come across a few AI, sometimes all the AI, have timetables with 00:00 arrive and depart at every stop :victory:. This flummoxes OR and you'll get very unexpected results. It can be cured in most cases in the MSTS AE by just pressing the "recalculate this" button on each AIs timetable when the times will be filled in using the "performance" percentage. MSTS seems only to use the "performance" percentage and the times calculated will thus conform to what MSTS would have run to anyway. Occasionally the "recalculate this" freezes and, even worse, will scramble the act :cheers3: so take backups should you try to use this facility.

Dennis

[edwardk]

Another thing to keep in mind is that AI trains under OR will follow the track speed set by the route. This never happened in MSTS so the only way to control the AI meet is to change the performance factor.

Edward K.

[roeter]

Well, my name got mentioned in there somewhere (and thanks for the compliment, by the way), so I better join in.

For starters, there was ofcourse no knowledge of how train control worked in MSTS. But even if there had been, it would not have been used - for AI control certainly was not a strong point of MSTS (and that's putting it very mild) - there are good reasons these are often referred to as 'artificial idiots' on most forums.

So, new logic was develloped and as a result, there are various reasons why timing of AI trains is different.

One of the most obvious is how AI trains react to changes in line speed : in MSTS, on a rise in line speed, AI trains will start to accelerate immediately when the front of the train passes the speed sign, but in OR, the rear of the train must be passed that sign before acceleration is allowed - and for long freight trains coming out of low-speed sections that can make a real difference in timing.

Another very important item is that in OR, AI trains will stick to timetabled stop timings, and use either the stop-time in the timetable or the maximum stop time defined for a platform - it disregards the weird 'number of passengers' item, which in MSTS often lead to very long station stop times.

The way in which AI trains are processed before the actual start of the activity is also important. This process is exactly the same as it is during the activity - so AI trains adhere to signals, linespeeds, station stops etc. - the only difference is that the update rate is 5 secs. rather than 0.01 secs, but that is just to save time.

One rather unfortunate side-effect of this 5 second interval concerns AI trains which are due to start just before the actual activity start. The timing of these AI trains in what some call 'fine-tuned' activities (but what I call fabricated timings) are worked out to the exact second when the train is to start so it is in a very exact location at the actual activity start. But as a result of the 5 second interval, this will never work that way in OR. And ofcourse, for these activities that difference is most obvious. That's a small price to pay.

Regards,
Rob Roeterdink