Revisiting the RailDriver in Open Rails With Experimental Monogame and RailDriver Support

Open Rails development has been coming along quite well, particularly in testing the adaptation of the Monogame framework. (Monogame is the open-source adaptation of Microsoft’s XNA4 platform.) The Monogame platform brings some significant performance improvements, with better handling of memory and DirectX that makes Open Rails perform better and run more smoothly with large, complex routes and scenery than ever before. (Note, however, that the monogame implementation requires Windows 7 to run. It can’t run on Windows XP.)

It’s already been decided that Monogame is the way ahead for Open Rails, since it’s an open, actively developed platform for modern computers. A large portion of the development work this year has been in preparing and testing the Open Rails code base to move onto the Monogame framework. It might not seem as ground-breaking as, say, the introduction of working turntables, but in reality it’s even more important, since it moves the core software off of the old closed XNA framework which will eventually go end-of-life and onto a modern, open-source platform which will continue to support modern computers and operating systems.

Along the way, the source code repository has moved to GitHub, which makes it easier for developers and experimenters to create alternative forks of the project, and for those changes to eventually be folded into the main branch of development, if desired. That’s how the Monogame project began, as an independent fork to test the possibilities. After much testing and hard work, the Monogame fork’s progress is steadily being integrated into a new “Unstable” branch alongside the ongoing “Experimental” branch of Open Rails. This is in preparation for the eventual migration to Monogame for the main and Experimental branches.

There’s also a fork of the project that overhauls RailDriver support in Open Rails. Github user and Open Rails experimenter “perpetualKid” has been working on improving how the RailDriver is handled. The sluggish response of the RailDriver controls has been addressed. Control response is now quick and accurate. The improved RailDriver code includes the ability to re-map the RailDriver’s buttons and controls, just like the existing ability to re-map the keyboard inputs. And there’s a built-in calibration system that works hand-in-hand with the improved control behavior.

Here are some screenshots to show some of the details of the improved RailDriver interface.

First, here’s the new tab in the Open Rails settings menu system:

Clicking the “Legend” button brings up a helpful graphic which identifies all the RailDriver controls and buttons to help with creating custom mappings. (The default mappings are the same as the ones built into Open Rails, which imitate MSTS.)

Clicking the “Calibration” button utilizes the control legends dsplay and on-screen prompts to move the controls to specific positions to generate a calibration for Open Rails:

By following on-screen prompts and referring to the guidance on the pictorial display, the RailDriver can be quickly set up to work reliably with Open Rails. Calibration is stored in the Registry and neatly organized with other Open Rails entries. This means that once calibration is done, it’s available every time any route is run under this version of Open Rails, regardless of where the route is stored. (The old default RailDriver implementation in OR relies on a calibration file, which must be present in the “Train Simulator” folder of every installation profile. This means that for mini-routes and multiple installation profiles, it was necessary to remember to drop a copy of the calibration file in each one. Using the Registry simplifies this.)

The most recent and important upgrade to this version is that it now includes the auto-updater function. Prior versions had to be downloaded individually to replace the old ones. Now, the auto-updating behavior that users of the Experimental OR builds is available, although with a slight difference.

As Monogame development has progressed, a new “Unstable” update channel was added. When the update option is used in this new RailDriver version, changes from the “Unstable” OR channel as well as specific RailDriver changes will be merged in. This results in a different build than the “Experimental” or “Unstable” builds. But it is generally parallel to the “Unstable” Monogame build, with RailDriver support added.

It’s important to understand that this RailDriver-enabled version of OR is an unofficial version. It’s not directly supported by the Open Rails development team. Since it leverages the “Unstable” Monogame development path, it’s highly experimental and not guaranteed to be 100% reliable or functional — there may be bugs. But as long-term users of the “Experimental” channel already know, the advantages generally outweigh the occasional bug.

You can download the RailDriver-enabled fork from perpetualKid’s GitHub page here. Scroll down to the bottom of the page to find the link for “Release Download OR-MG x.x.x RD” to go to the page with the latest Release download. Be sure to note the information on the page with respect to any dependencies.

After you’ve downloaded the program, unzip it to a directory on your computer — and remember that you can run multiple versions of Open Rails, so it doesn’t have to replace any of your exiting installations. You may want to make a shortcut to “OpenRails.exe” in the new install and place it somewhere handy, with its own name to identify it as the RailDriver version.

Run the new version, and be sure to click the “Options” button and go to the “Updater” tab. Then make sure “Ultimate” is selected for the updater channel. Finally, go back to the main menu screen and click the usual update link that appears in the upper right. The updater will merge the relevant changes.

IMPORTANT: Changing the updater channel changes it for ALL versions of Open Rails that you have installed. This is a limitation of how the updater setting is stored in the Registry. If you also run the “Experimental” build, for instance, don’t update it until you go into the settings and change to the appropriate update channel. Then go back and update from inside that version. When you launch the RailDriver version, of course, you’ll need to switch the channel back to “Ultimate” before checking for updates to that version. It’s simple — just something extra to remember if you’re testing multiple Open Rails versions.

If the RailDriver is your favorite way of controlling trains in Open Rails, then this fork of OR development may become your go-to version. Just remember that it’s highly experimental on two counts — It’s using both the experimental Monogame platform and the independently-developed Rail Driver additions. Both of these features are highly desirable for eventual inclusion in the main Open Rails branch, so this is a way to try out the future of OR.