[railguy]

I have hesitated posting this because it might ruffle some feathers among activity creators. That said, after 3 exasperating days of trying to adapt an activity obviously created in the MSTS AE Editor that was supposedly designed to work in OR, I want to give what I hope is some helpful advice.

First, some history. The MSTS activity creation philosophy was to create AI paths that were as short as possible to interact with player trains. The reasoning was two-fold. First, MSTS would often "choke" on having too many AI trains operating at once, overwhelming the RAM, etc. on computers in the early MSTS era. Second, while the AE could "play" the activity in "VCR" mode for the activity creator to check how the activity would run, long paths or multiple AI trains could "confuse" the AI dispatcher, causing deadlocks, etc. that the AE might or might not detect. So, creators got into the habit of creating short paths for AI trains to try to avoid these problems. The particular activity that is giving me fits in OR was created this very way. Bluntly, it runs horribly in OR and here is why and how it will have to be repaired.

The OR AI dispatcher is much "smarter" than the MSTS dispatcher and the activity creator has more options to create viable paths. HOWEVER, what the OR dispatcher does not like is computing the logic of meets, etc., and then having a new AI train "born" with a short path in the middle of an activity. An example of how this causes trouble is one that I observed from the MSTS activity that I'm "remodeling" now. About an hour into the activity, a new short path AI westbound train is "born" to meet an AI eastbound train and, following it, the eastbound player train. But, the short path train is created with no siding long enough to accommodate it between it and the eastbound trains, which are also long. Obviously, a deadlock results. In OR, it is possible for the player to assume the dispatcher role to resolve some deadlocks and conflicts, but there is no way to resolve this one.

The solution is, in many ways, diametrically different on OR from MSTS. My advice is to create OR AI paths that are longer, up to and including running the full length of the route, with passing paths, etc. placed at regular intervals. Doing so allows the OR dispatcher to "sort out" the logic of meets, etc. over more miles of route, more signals, more running time, and more sidings, crossovers, etc.

In this particular activity that I'm reworking, I could see the creator's logic of how the activity would flow (in MSTS logic), but it breaks in multiple places in OR. I tried to work around the "short AI paths" issue, but I would have been better off just to scrap the AI paths in their entirety and replace them with paths that essentially run the full length of the route. Designing an activity this way requires some intuition as to running times, etc. to effect meets at specific locations, but it can also be more dynamic as to where meets, etc. occur.

One of the OR Developers might want to chime in on some of the OR Dispatcher logic--for example, how many signals, etc. down the line is the OR program looking at when determining meets, etc. I want to say (from observation) at least 5 or maybe more signals. One thing that I have noticed that can create a deadlock--when an AI train is short enough to fit between switches without fouling on a signaled siding, but is too long to fit between the signals. OR will let the train proceed to and into the siding, but will not clear the signal for the opposing AI or player train.

All thoughts and ideas appreciated. Thanks.

[rickloader]

These OR features are a strengh rather than a weakness. As you desccribe , the MSTS short paths with trains "born" and eliminated have become an ingrained convention . Perpetuated in RW/TS2xxxx with "portals" and maybe even in TSW. It is so silly.having trains popping up.
Short path activities are a nonsense because even with a slight variation in timings the whole scenario falls apart. OR can run full length paths with little performance cost and the "dispatcher" is robust enough to handle most situations
(Note Rob tells us there is no dispatcher but trains clear their own path)

I agree the best option is to rewrite the Msts activity with full paths
Or better still use Timetable mode. Author Rob has included several features to control paths and meets. The false distinction between AI and player trains is also gone . (another silly convention)
Timetable mode enables a complete NETWORK simulation with hundreds of trains. I am trying to do this network with New Forest route and it is very satisfying to see the whole route alive with trains.Recent improvements to the dispatch viewer by Chris J and Looky give an enhanced network view, and remember OR allows to to jump to view any train in game.
So why bother with limited MSTS activities?

[roeter]

railguy, on 07 November 2023 - 03:04 PM, said:

One of the OR Developers might want to chime in on some of the OR Dispatcher logic--for example, how many signals, etc. down the line is the OR program looking at when determining meets, etc. I want to say (from observation) at least 5 or maybe more signals. One thing that I have noticed that can create a deadlock--when an AI train is short enough to fit between switches without fouling on a signaled siding, but is too long to fit between the signals. OR will let the train proceed to and into the siding, but will not clear the signal for the opposing AI or player train.

OR does not have a dispatcher function as such. There are three logic processes which control train movements, one is the signalling, the second is the deadlock processing, the third are train commands, but these are only available in timetable mode. All three are worked through the trains themselves.

Signalling control works mainly through the SignalNumClearAhead variable.

Deadlock processing: when a train is started, the deadlock processing searches for deadlocks and possible meets through the full length of the train's path, against all existing trains, also using the full length of the path of those trains (from the present position onwards). Note that reversal points are considered to be end of path in this process. When a train reverses, a full deadlock test is performed again. Because the train length is taken into consideration when testing for possible meets, deadlock processing is also performed again when a train changes its length, due to detach or attach actions.

Train interaction commands, like $wait, as available in timetable mode, are processed during pre-processing and work through links between trains. The required information is linked to the position in the train's path where the command must be activated. As for deadlock processing, the full paths of both trains (upto any reversal points) are checked to establish the location where the $wait must be activated.

The processing of the signalling using SignalNumClearAhead was copied from MSTS, though with the difference that MSTS counted signal heads whereas OR has the option to count (normal) signals only.
The deadlock processing is specific for OR and has no MSTS equivalence. Train commands, of course, do not exist at all in MSTS and also not in activities.

Regards,
Rob Roeterdink

[Aldarion]

And that is why I love timetale mode so much, and I dont want to look ever again to an "activity"

[railguy]

"Deadlock processing: when a train is started, the deadlock processing searches for deadlocks and possible meets through the full length of the train's path, against all existing trains, also using the full length of the path of those trains (from the present position onwards). Note that reversal points are considered to be end of path in this process. When a train reverses, a full deadlock test is performed again. Because the train length is taken into consideration when testing for possible meets, deadlock processing is also performed again when a train changes its length, due to detach or attach actions." (My italics emphasis added.)

The above post from Rob pretty much confirms my understanding of the "dispatcher" logic of OR. The paragraph that I quoted above is where I think "short path" AI trains cause issues in OR. The logic of the OR program can account for many more variables than MSTS could, but it can falter when--after the program has logically computed how to handle meets, etc. among existing player and AI trains--a new AI train with a short path is created during the activity right in the middle of the paths of the already existing player and AI trains, particularly when the "new" AI train has no place in its path (like a siding) of sufficient length to accommodate it, or the player train. Then a deadlock is inevitable. Now, in theory, using manual mode and switching the player engineer between the player train and the AI train, the player could execute a "saw-by" where the trains are broken into pieces short enough to clear on the siding. As in real railroading, even a "simple" saw-by can sometimes take a couple of hours to execute, however.

Please note here that I don't say all of this as a criticism of how OR handles the logic of executing an activity. I think that the logic is pretty brilliant. But, the old "short path" philosophy that many MSTS activity creators used (often out of necessity to make the activity run in MSTS) can cause problems in OR. Over the next few days, I'm going to rework the activity that is the reason for these posts, adopting long paths for the AI trains. My guess is that will solve most all of the deadlock issues. How I plan to do this is as follows:

Let's say that the route runs from Station A at the west end of the route to Station Z on the east end. The player train is running from Station C to Station X. There will be 10 AI trains running, 1 eastbound from Station A to station Z, 8 westbound trains running from Station Z to Station A, and one westbound train running from Station M to Station A. The eastbound AI is to pass the eastbound player train at Station C just after the start of the activity. This will be programmed by placing a Wait Point in the player train path to allow the EB AI to overtake it. The WB AI trains will be created periodically, such that they will meet the player train (and that EB AI train) at various points during the activity, taking care that two AI trains are not created on top of each other. What I will likely do is create the Station M-A westbound train on the siding at Station M at the beginning of the activity and use a Waiting Point to hold it there until I'm ready for it to proceed westward--that will allow the OR logic to evaluate it presence from the beginning of the activity. A number of those WB Z-A AI trains will have starting times prior to the starting time of the player train. What I will sometimes do, to give OR maximum time to evaluate meet logic is to create an AI train with an earlier start time, then use a Waiting Point to delay its departure. On this particular activity, the route has numerous longer sidings and, through the use of passing paths, those sidings can be made available to both player and AI trains. One of the interesting dynamics of this particular activity is that the player train is underpowered and can not make running time. I'll see how all of this turns out after I modify the activity.

[Amtrak115]

railguy, on 08 November 2023 - 05:14 AM, said:

Let's say that the route runs from Station A at the west end of the route to Station Z on the east end. The player train is running from Station C to Station X. There will be 10 AI trains running, 1 eastbound from Station A to station Z, 8 westbound trains running from Station Z to Station A, and one westbound train running from Station M to Station A. The eastbound AI is to pass the eastbound player train at Station C just after the start of the activity. This will be programmed by placing a Wait Point in the player train path to allow the EB AI to overtake it.

This is where you lost me....Wait points don't effect player trains....in activities that I've created...I've use Wait points on AI routes to Quote slow down an AI train to facilitate a passing opportunity....in later activities I developed, i used an OR only modification of Wait points to hold an AI train at a certain point to ensure that Player train would See the traffic. While I admit I will use "short" AI train paths for traffic but nothing so short that traffic just pops up in view of player....To me there is no need for the simulator to continually have to process train movement data on traffic that the player train has past and will not see....Why take up the execution cycles ....

I'm not an advocate of timetables either...not because I don't understand them, but in my believe that in 90% or better cases railroads don't operate on Timetables anymore...but on train orders that are coordinated with dispatchers to facilitate their movement across territories. maybe in Europe or other countries Timetables are the prevalent method to facilitate traffic, but I don't see it in the US, except in cases of passenger operations...

Anyway just my take....I'm curious will you tell me the name of the activity...I'd like to look at it...if it's not one of mine....lol.....

Amtrak115

[railguy]

^Waiting points don't affect player trains, except for this (from the OR manual), my emphasis in italics:

"WPs set in a path used by a player train have no influence on the train run, except – again – when the
WP is followed by a signal in the same track section."

This is how I use a player train waiting point. It will hold a signal red for the player train, thus allowing a following train to overtake it. The key is to set the player train waiting point for a long enough time to allow the following train to enter the block protected by the signal before the player train waiting point expires.

I agree that using Timetable mode may work for "scheduled" train operations (often common in Europe), but are not well-suited for U.S. train operations. (For the record, I am quite familiar with railroad dispatching (with some real world experience in that area), using both Timetable and Track Warrant systems.

[Amtrak115]

I stand corrected...."WPs set in a path used by a player train have no influence on the train run, except – again – when the WP is followed by a signal in the same track section." i could never get this to work....

" (For the record, I am quite familiar with railroad dispatching (with some real world experience in that area), using both Timetable and Track Warrant systems." For the record...I have NO real world experience...just what I observed...

amtrak115

[Laci1959]

This is how I use a player train waiting point. It will hold a signal red for the player train, thus allowing a following train to overtake it. The key is to set the player train waiting point for a long enough time to allow the following train to enter the block protected by the signal before the player train waiting point expires.

Hello.

This can be combined with a Location Event. The wait time is overridden by the Location Event and restarted by the delay. When restarting like this, I usually set the new waiting time to 1 second. Of course, the location of the Location Event that triggers the restart of the delay must be chosen well in this case.
The advantage is that it also works well in the event of a delay. It also works in the conditions AI train > lead train, lead train > AI train, and AI train > AI train.

Sincerely, Laci 1959

[railguy]

^I am not a big fan of location events that affect train operation because they are set in the TSRE, independent of the train's path. The location event can potentially affect any train passing over them. I use location events for things like weather changes, etc., but generally avoid them for train operations. A potential solution would be path-specific or service-specific location events that only affect an individual path or service.

As to my earlier post, I re-worked my "subject" activity as I outlined in the post. I have not fully run it as yet, but, so far at over halfway through, it has operated perfectly, including an overtake as part of a three-way meet near the beginning of the activity. I plan on finishing the run of the activity today.