[Csantucci]

Extract from the introduction of the attached document:

"In the moment I'm writing this document the area where there are the most incompatibilities between MSTS and OR is that related to activities. MSTS activities of even medium complexity often run in a significantly different way in OR, and therefore often loose appeal (because some “combinations” of trains don't work) or even could lead to deadlocks (which does not happen often).
Activities run differently on OR partly because of the difficulty of simulating the same timings as MSTS, but mainly because of decisions that have been taken (at least by the moment) by the OR developers.
Considering the importance of activities to enjoy the game, and considering the large base of already developed and running MSTS activities, it is evident that providing a reasonable procedure to port to OR activities developed for MSTS could lead to the availability of a good number of OR activities for the pleasure of OR players.
Aim of this document is to describe this procedure."

28/4/14 more info added as per Rob's post.
29/4/14 corrected typos and errors, clarified some items.
30/4/14 modified info on position of OR-specific sigscr.dat and sigcfg.dat files

06/1/15 document removed because it is outdated due to the implementation of the "Enhanced compatibility with MSTS activities" features


Suggestions for corrections and additions are welcome.

Some short final considerations.

I can't deny that I would prefer if OR could provide a higher compatibility with MSTS activites.

Having the possibility to toggle player train control between human control and OR control would highly speed up porting operations.

I hope this document can encourage some activity developer in porting activites (it IS possible!), and can lead developers to achieve a higher degree of downward compatibility between OR and MSTS activity management.

[Eldorado.Railroad]

 Csantucci, on 27 April 2014 - 07:51 AM, said:

Porting MSTS activities to OR.doc

Carlos,

This is a great idea. Like many, I have been seeing differences in how activities that are still created in MSTS translate "differently" to Open Rails.

I have not downloaded this file , yet. Why, because if this is a Word document it can also be a vector for a malware. While I am sure that every effort it being made to insure this does not happen may I suggest that a "safer" document format be used?

La ringrazio molto per il vostro sforzo!

[Csantucci]

Thanks Eldorado,
here you have the .pdf version if you prefer!


P.S. A .pdf version is now available in the first post.

[edwardk]

I was under the impression that the AI train follows the routes designated speed limit in OR. Is this actually the case?

Edward K.

[gpz]

 Eldorado.Railroad, on 27 April 2014 - 09:20 AM, said:

Why, because if this is a Word document it can also be a vector for a malware.

It is mainly just a hype of computer security companies. You have a negligible chance for a virus infection through documents...

[Csantucci]

 edwardk, on 27 April 2014 - 01:02 PM, said:

I was under the impression that the AI train follows the routes designated speed limit in OR. Is this actually the case?

Edward K.

Max speed reached by the AI train - provided there is enough braking distance up to next speed reduction - is the minimum between route max speed in that point (including signal max speed) and the first parameter of MaxVelocity within the .con file. I would expect that also max speed as defined within the .eng file is considered.

[roeter]

Two important differences are missing from the document.

• Rise in speed limits.
  
  • MSTS :
    
    • AI trains :
      AI trains will start to accelerate as soon as the leading engine passes the speedsign or signal which sets the higher speed limit.
      
    • Player train :
      Player train is allowed to accelerate (with the higher speed limit indicated in F4) as soon as the leading engine passes the speedsign or signal.
    
    
  • OR :
    
    • AI trains :
      AI trains will retain low speed and only start to accelerate after the end of the train has passed the speedsign or signal.
      
    • Player train :
      The player train will not be allowed to accelerate until the end of the train has passed the speedsign or signal. The track monitor will show the higher speed along the track at its actual location, but will set the raised speed limit only when the train is clear of that location.
  
  In particular for activities with long trains over sections of route with relative low speed restrictions, this difference can lead to significant differences in timing for both AI and player trains.
  
  
• Permissive signals.
  
  • MSTS :
    
    • AI trains :
      AI trains are allowed to pass Permissive signal at danger, but if an AI train closes up to the train in front (either AI or player train), that train ahead is completely ignored and the AI train will run straight through it.
      Generally, the activity will then end with the error that the player derailed its train :oldstry: .
      
    • Player train :
      Player train can pass through Permissive signal at danger.
    
    
  • OR :
    
    • AI trains :
      AI trains are allowed to pass Permissive signal at danger and will keep a preset distance to the train in front. If the train in front is moving, the train following it will adjust its speed so as to follow at fixed distance.
      
    • Player train :
      Player train can pass through Permissive signal at danger (no difference with MSTS).

Also, you mention that an OR-specific sigcfg.dat file needs to be placed in the main Route directory, and be named sigcfg.dat_or.
That, however, was only an experimental setup.
In its final form, use of OR-specific sigcfg.dat will follow the same lines as that for OR-specific .eng and .wag files.
There needs to be a OpenRails subdirectory, and an OR-specific sigcfg.dat file must be placed in this directory, using the original name.
Note that this file must contain all signal definitions.
Any referenced sigscr file(s) must also be placed in the OpenRails directory even if there are no changes.

This final setup will be introduced soon.

Regards,
Rob Roeterdink

[Csantucci]

Rob,
thank you very much for your additions and clarifications. I have added them to the document and uploaded a revised version on my original posts. I am also happy you will introduce the OpenRails subfolder within the route folder to contain OpenRails specific route files.

[cjakeman]

Hi Carlo,

As no-one else has chosen to do it, I'll implement the feature your document lists - to start an activity with the player train already moving.

I didn't implement it when I did the freight activity elements as I was rather new to OR and it seemed a bit tricky, but now I have a little more confidence :-)

[Csantucci]

Thanks Chris, it's a functionality I like (and I'm sure I'm not alone), and moreover everything that makes more compatible OR to MSTS referring to activities is welcome! :sign_thanks: