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

[Csantucci]

A revised version of the document is available in the first post.

[roeter]

From version 2203 onward, OR-specific sigcfg.dat and sigscr.dat must be placed in OpenRails subdirectory, and must not be renamed.
Note that the sigcfg.dat in the OpenRails directory must contain ALL signal definitions, and that ALL related sigscr files (as referenced in sigcfg.dat) must also be copied, in full, to the OpenRails directory.

Regards,
Rob Roeterdink

[Csantucci]

Rob,
to check the change I copied the OR-specific sigscr.dat and sigcfg.dat into an OpenRails subfolder within the route's folder (with their standard .dat extension), and renamed the ones in the route root folder to an unrecognizable name to OR, so I would be sure that it gets the ones in the OpenRails subfolder. I got a pop-up window telling that an essential file is missing (sigcfg.dat) and OR cannot continue. Must the MSTS version of sigcfg.dat be at its place even if it not used?

A new release of the guide is now available in the first post.

[roeter]

Hi Carlo,

Seems something has gone wrong in the update - it works in my testversion, but not in the updated version.
Looks like I missed out on one of the changes somewhere.
Will sort it out.

Regards,
Rob Roeterdink

[roeter]

Ah - I had updated all and everything for trains and signals and what have you, but it had slipped my mind that viewer also loads sigcfg.dat :whistling: .
Corrected in version 2204.

By the way - you can verify which sigcfg.dat is loaded in the log-file, for if the OR-specific file is used, it is shown as SIGCFG_OR instead of SIGCFG.

Regards,
Rob Roeterdink