Open Rails Perpetual Railroad and Activity Editor
1.png
The scope of this project is really two programs in one, so bear with me while I explain exactly what is being released here and why the first part was necessary to build the second. Part One: The Activity Editor
2.png
The first part is the Activity Editor.
The obvious question is: Why build another activity editor?
The answer is twofold. First, I wanted a modern replacement for the original MSTS Activity Editor that still behaves very much like the program we already know. Second, and more importantly, the Activity Editor became the foundation needed to build the Perpetual Railroad underneath it.
The editor is basically a 1-to-1 recreation of the MSTS Activity Editor, but enhanced where needed with debugging tools, Open Rails features, and modern conveniences.
It is not intended to completely reinvent activity creation. If you already understand the MSTS Activity Editor, most of this should feel familiar.
Where it becomes considerably more powerful is troubleshooting. Optional AI Activity Debugging
3.png
The Activity Editor includes an optional AI-powered diagnostic system.
The AI is read-only. It cannot modify your activity files, paths, services, consists, route files, track database, or anything else.
Its job is simply to inspect what the editor and route are doing and help explain problems.
It can troubleshoot things such as:
And quite a bit more.
The purpose is to make activity creation and debugging as painless as possible.
Instead of spending hours trying to figure out why an AI train refuses to move, why a path breaks at a particular switch, or why an activity behaves differently from what you expected, the debugger can inspect the underlying files and track topology and tell you what is actually happening.
For people who do not want AI involved, the feature is completely optional.
The Activity Editor itself does not depend on AI to create or edit activities. Open Rails Live Integration
4.png
The Open Rails API is also connected to the editor.
This allows the Activity Editor to view the railroad while Open Rails is actually running, including things such as:
One particularly useful possibility is diagnosing a troublesome activity while the activity is actually running in Open Rails.
Instead of only examining the files before starting the simulator, the editor can compare what was supposed to happen with what Open Rails is actually doing. Open Rails-Specific Activity Features
The editor also supports more advanced Open Rails functionality that goes beyond what the original MSTS Activity Editor was designed for.
That includes features such as:
Again, though, the Activity Editor was never the final goal.
It was the groundwork for the second half of the project.
Part Two: ORPR - Open Rails Perpetual Railroad NOTE: All of the following images are outdated and should only represent the idea of what were building not its current form.
6.png
ORPR, or Open Rails Perpetual Railroad, is exactly what the name implies.
At the time of this post, it is an activity-driven perpetual railroad simulation.
Rather than thinking of every Open Rails activity as a completely independent scenario, ORPR keeps track of the railroad between operating sessions.
You finish one job, and the railroad continues from there.
For example, suppose you run a local or turn job on Monday.
You finish the activity, park the locomotive, leave cars at several industries, return empties to the yard, and shut Open Rails down.
You do not play again until Wednesday.
During that time, ORPR can simulate what happened to the railroad between Monday and Wednesday.
It keeps track of things such as:
When you come back Wednesday, the railroad has moved forward instead of magically resetting to Monday.
Your next activity is generated from the railroad's new state.
That is the basic idea behind the Perpetual Railroad.
It sounds simple when described that way, but underneath it there is considerably more going on. ORPR Creates the Railroad Files for You
7.png
One important point I want to make clear is that ORPR is not simply keeping a database of what cars are where and then expecting the user to go into the Activity Editor and build everything manually.
The program creates the necessary Open Rails/MSTS operating files itself.
That means ORPR can generate:
Those files are created from the current state of the railroad and the work that actually needs to be done.
If an industry needs empties, ORPR can determine what equipment is available, where it is located, what train should move it, what path that train needs to use, what consist should be assembled, what service is required, what AI traffic needs to coexist with it, and then create the activity needed to actually run the job in Open Rails.
The user does not have to manually create a path, then create a consist, then create a service, then create traffic, and finally put all of those pieces together into an activity every time the railroad needs another train.
That entire chain is part of the Perpetual Railroad.
In other words:
The railroad decides what work needs to be done, and ORPR creates the Open Rails files necessary to make that work playable.
Of course, all of those files can still be inspected in the Activity Editor, and that is another major reason the Activity Editor was built first.
If ORPR generates a complicated switching job with several AI trains, reverse points, events, pickups, setouts and timing requirements, the same editor can be used to see exactly what was generated and diagnose it if something does not behave as expected. Industries Actually Generate Railroad Work
Industries are not simply scenery or names attached to sidings.
They can have operating characteristics.
For example, a coal mine can produce a certain amount of coal over time.
As coal production increases, loaded cars eventually need to be removed and empty cars need to be supplied.
Those movements can either be scheduled or generated as needed.
A power plant can consume coal.
A factory can receive raw materials and produce outbound loads.
A yard can classify and hold cars for later trains.
An interchange can receive cars from another railroad.
The idea is that the traffic exists because the railroad actually has a reason to move it.
In very broad terms, think of it as something along the lines of:
JMRI meets Activity Master on steroids.
Except the railroad's state continues between activities. Scheduled and Unscheduled Operations
Not everything on a real railroad runs exactly the same way.
ORPR therefore allows trains to be both scheduled and demand-driven.
You might have scheduled passenger trains and through freights that operate at defined times.
At the same time, an industry might generate enough traffic that another local or extra movement becomes necessary.
The railroad can therefore include things such as:
The program plans around all of them.
And when one of those trains needs to exist, ORPR can generate the path, consist, service, traffic and activity structure required to actually run it. Locomotive Maintenance and Car Servicing
The railroad also has to take care of its equipment.
Locomotives can require things such as servicing, inspections, fuel, sand, or other maintenance.
Freight cars can require inspections or repairs.
Those requirements affect how equipment is assigned.
A locomotive that needs servicing should not simply be treated as permanently available.
A freight car requiring repair should not magically appear in the next train.
This can create periods where equipment availability becomes tight and other periods where the railroad has plenty of capacity.
In other words, the railroad can have busy periods and quiet periods instead of operating at exactly the same level all the time. Maintenance-of-Way Operations
Maintenance-of-Way is also part of the operating model.
For example, suppose an MOW train is going to be parked for the weekend.
The program does not simply choose an empty track and forget about it.
It can look ahead and determine whether that track is expected to be needed.
If the track is going to be used Saturday morning to stage freight cars or assemble another train, the MOW consist should not be parked there Friday night.
1.png
The scope of this project is really two programs in one, so bear with me while I explain exactly what is being released here and why the first part was necessary to build the second. Part One: The Activity Editor
2.png
The first part is the Activity Editor.
The obvious question is: Why build another activity editor?
The answer is twofold. First, I wanted a modern replacement for the original MSTS Activity Editor that still behaves very much like the program we already know. Second, and more importantly, the Activity Editor became the foundation needed to build the Perpetual Railroad underneath it.
The editor is basically a 1-to-1 recreation of the MSTS Activity Editor, but enhanced where needed with debugging tools, Open Rails features, and modern conveniences.
It is not intended to completely reinvent activity creation. If you already understand the MSTS Activity Editor, most of this should feel familiar.
Where it becomes considerably more powerful is troubleshooting. Optional AI Activity Debugging
3.png
The Activity Editor includes an optional AI-powered diagnostic system.
The AI is read-only. It cannot modify your activity files, paths, services, consists, route files, track database, or anything else.
Its job is simply to inspect what the editor and route are doing and help explain problems.
It can troubleshoot things such as:
- Path problems
- Service problems
- Missing or incorrect filenames
- Activity file problems
- Signal issues
- Timing problems
- Traffic problems
- Consist problems
- Event problems
- Missing references
- Track database problems
- Junction and switch problems
- Reverse points
- Wait points
- Deep-level track-node issues
- Live editor state
- Player and AI service relationships
- Problems between ACT, SRV, PAT, CON and TDB files
And quite a bit more.
The purpose is to make activity creation and debugging as painless as possible.
Instead of spending hours trying to figure out why an AI train refuses to move, why a path breaks at a particular switch, or why an activity behaves differently from what you expected, the debugger can inspect the underlying files and track topology and tell you what is actually happening.
For people who do not want AI involved, the feature is completely optional.
The Activity Editor itself does not depend on AI to create or edit activities. Open Rails Live Integration
4.png
The Open Rails API is also connected to the editor.
This allows the Activity Editor to view the railroad while Open Rails is actually running, including things such as:
- The live player train
- AI trains
- Signal states
- Player paths
- AI paths
- Reverse points
- Waiting points
- Train positions
- Other live simulation information
One particularly useful possibility is diagnosing a troublesome activity while the activity is actually running in Open Rails.
Instead of only examining the files before starting the simulator, the editor can compare what was supposed to happen with what Open Rails is actually doing. Open Rails-Specific Activity Features
The editor also supports more advanced Open Rails functionality that goes beyond what the original MSTS Activity Editor was designed for.
That includes features such as:
- Join/Split
- AI train horn blowing
- Wait Until
- Additional Open Rails activity options
- Expanded activity diagnostics
- Improved path and service inspection
Again, though, the Activity Editor was never the final goal.
It was the groundwork for the second half of the project.
Part Two: ORPR - Open Rails Perpetual Railroad NOTE: All of the following images are outdated and should only represent the idea of what were building not its current form.
6.png
ORPR, or Open Rails Perpetual Railroad, is exactly what the name implies.
At the time of this post, it is an activity-driven perpetual railroad simulation.
Rather than thinking of every Open Rails activity as a completely independent scenario, ORPR keeps track of the railroad between operating sessions.
You finish one job, and the railroad continues from there.
For example, suppose you run a local or turn job on Monday.
You finish the activity, park the locomotive, leave cars at several industries, return empties to the yard, and shut Open Rails down.
You do not play again until Wednesday.
During that time, ORPR can simulate what happened to the railroad between Monday and Wednesday.
It keeps track of things such as:
- Freight cars
- Locomotives
- Consists
- Loaded and unloaded states
- Car locations
- Engine locations
- Industries
- Industry production
- Industry consumption
- Scheduled trains
- As-needed trains
- Equipment servicing
- Railroad operations
When you come back Wednesday, the railroad has moved forward instead of magically resetting to Monday.
Your next activity is generated from the railroad's new state.
That is the basic idea behind the Perpetual Railroad.
It sounds simple when described that way, but underneath it there is considerably more going on. ORPR Creates the Railroad Files for You
7.png
One important point I want to make clear is that ORPR is not simply keeping a database of what cars are where and then expecting the user to go into the Activity Editor and build everything manually.
The program creates the necessary Open Rails/MSTS operating files itself.
That means ORPR can generate:
- Paths
- Consists
- Services
- Traffic services
- Traffic patterns
- Player activities
- AI train movements
Those files are created from the current state of the railroad and the work that actually needs to be done.
If an industry needs empties, ORPR can determine what equipment is available, where it is located, what train should move it, what path that train needs to use, what consist should be assembled, what service is required, what AI traffic needs to coexist with it, and then create the activity needed to actually run the job in Open Rails.
The user does not have to manually create a path, then create a consist, then create a service, then create traffic, and finally put all of those pieces together into an activity every time the railroad needs another train.
That entire chain is part of the Perpetual Railroad.
In other words:
The railroad decides what work needs to be done, and ORPR creates the Open Rails files necessary to make that work playable.
Of course, all of those files can still be inspected in the Activity Editor, and that is another major reason the Activity Editor was built first.
If ORPR generates a complicated switching job with several AI trains, reverse points, events, pickups, setouts and timing requirements, the same editor can be used to see exactly what was generated and diagnose it if something does not behave as expected. Industries Actually Generate Railroad Work
Industries are not simply scenery or names attached to sidings.
They can have operating characteristics.
For example, a coal mine can produce a certain amount of coal over time.
As coal production increases, loaded cars eventually need to be removed and empty cars need to be supplied.
Those movements can either be scheduled or generated as needed.
A power plant can consume coal.
A factory can receive raw materials and produce outbound loads.
A yard can classify and hold cars for later trains.
An interchange can receive cars from another railroad.
The idea is that the traffic exists because the railroad actually has a reason to move it.
In very broad terms, think of it as something along the lines of:
JMRI meets Activity Master on steroids.
Except the railroad's state continues between activities. Scheduled and Unscheduled Operations
Not everything on a real railroad runs exactly the same way.
ORPR therefore allows trains to be both scheduled and demand-driven.
You might have scheduled passenger trains and through freights that operate at defined times.
At the same time, an industry might generate enough traffic that another local or extra movement becomes necessary.
The railroad can therefore include things such as:
- Passenger trains
- Through freights
- Locals
- Yard jobs
- Turn jobs
- Industry jobs
- Transfer jobs
- Extras
- Maintenance-of-Way trains
- Special trains
The program plans around all of them.
And when one of those trains needs to exist, ORPR can generate the path, consist, service, traffic and activity structure required to actually run it. Locomotive Maintenance and Car Servicing
The railroad also has to take care of its equipment.
Locomotives can require things such as servicing, inspections, fuel, sand, or other maintenance.
Freight cars can require inspections or repairs.
Those requirements affect how equipment is assigned.
A locomotive that needs servicing should not simply be treated as permanently available.
A freight car requiring repair should not magically appear in the next train.
This can create periods where equipment availability becomes tight and other periods where the railroad has plenty of capacity.
In other words, the railroad can have busy periods and quiet periods instead of operating at exactly the same level all the time. Maintenance-of-Way Operations
Maintenance-of-Way is also part of the operating model.
For example, suppose an MOW train is going to be parked for the weekend.
The program does not simply choose an empty track and forget about it.
It can look ahead and determine whether that track is expected to be needed.
If the track is going to be used Saturday morning to stage freight cars or assemble another train, the MOW consist should not be parked there Friday night.
Comment