[Sid P.]

Has anyone else encountered similar problems as described below? (Sorry if it seems like a long-winded description!)

I have been trying some of the classic "beginner" activities in the default Marias Pass route in Open Rails. I had earlier submitted a fix for the "Autotrain Setout" activity to Elvas Tower because ORTS started the player train on the wrong side of a switch, leading to a collision with an oncoming AI train. The fix was to slightly change the starting location of the Player path in the activity files.
See http://www.elvastowe...-open-rails-08/

I have just tried the "Morning Intermodal" activity, and a similar problem occurs - ORTS places the player train on the wrong branch, and the program starts with "Out of Control - Off Path" showing in the Track Monitor. Again, the fix is to change the starting location of the Player path to be beyond the switch by modifying the player .pat file.

In both cases, the player path, as shown in the MSTS Activity Editor, starts just before a switch, and is shown in green continuing past the switch. (See attached captures.) In MSTS, the player train is placed on the Player path with the last car at the path's start point, behind the switch. In ORTS, the player train is placed entirely past the switch, but on the other branch.

I can understand that ORTS could have different placement rules, and would need to place the train completely beyond the switch instead of spanning it, but I am puzzled that it does not chose the Player path, as defined in the activity files.

Attached thumbnail(s)

• 
• 

[roeter]

This has been known for quite some time.
It occurs in the conversion of the MSTS path to the (old) internal OR format [based on this format, a further conversion was introduced with the new signalling to the present internal format].
When a defined point of a path (starting point, end point, waiting point, reversal point) is quite close to a switch, and therefor quite close to both tracks branching from that switch, the conversion sometimes selects the wrong track.
Problem (and a MAJOR headache) : the conversion is __VERY__ complicated ;) , and the original author is no longer on the team.
This, by the way, was also the reason why the present internal format is derived from this old format rather than directly from the MSTS format.
I've had a look at this about a year ago (I reported the first bug [1080735] on this on 19-11-2012), but I'm certainly __NOT__ going to change this code - it's just too risky.
The way around the problem is quite easy - just move the point a bit away from the switch. Making a mistake in the conversion could mean errors in most - or at least a lot more - paths.
Ofcourse, anyone wanting to have a go at this is very welcome to do so : you can find the code in RunActivity\AI\AIPath.cs.

Regards,
Rob Roeterdink

[R H Steele]

In Rich Garbers manual on Activities he makes a point about the "3 switch" rule that MSTS uses for signals. I certainly am not qualified to explain it, but in a few instances that the problem arose with me - I moved the start point 3 switches away (this is not always possible or desirable) and the problem did not occur. Open Rails ran the activity fine, did not test the results in MSTS. Cheers rhs (aka gerry)

[R H Steele]

To follow up what I posted before .... I have been working on the new Marias Pass 5 and ran into the same problem. (See post about reworking original default MP activities for new route) and in the Auto Train with Set-Out activity that starts near the Java Set Out I ended up moving the start point to quite a distance before the original point to MP 1164.00. The Player Train then starts on the correct path, however, it now holds at a red signal at the beginning of the activity for the first traffic train, which is fine. Signal goes green and Player can proceed to the set out siding. The second traffic train still passes when you are setting out the car on Essex Siding 2 or there abouts. Maybe this helps a bit. Cheers rhs (aka gerry)

[Sid P.]

Many thanks Gerry and Rob for the explanation and comments. Sounds like a good idea to leave the code alone at this point in time.
Rob, I just spotted your post on "Discussion" about the new Marias 5 activities, haven't read it yet.
Interesting point in "Auto Train with Setout: I moved the player path start onto the player path, rather than moving it further behind the switch. Your result is more interesting, although different from the MSTS version.
Cheers,

[R H Steele]

 Sid P., on 06 December 2013 - 09:32 AM, said:

Many thanks Gerry and Rob for the explanation and comments. Sounds like a good idea to leave the code alone at this point in time.
Rob, I just spotted your post on "Discussion" about the new Marias 5 activities, haven't read it yet.
Interesting point in "Auto Train with Setout: I moved the player path start onto the player path, rather than moving it further behind the switch. Your result is more interesting, although different from the MSTS version.
Cheers,

Sid P - The post Open Rail Discussion Post "Marias Pass 5: running original Marias Pass default activities for OR" is from me (Gerry) and I have attached the first MSTS default activity fixed for Marias Pass 5 to the post.(autotrnsetout.act). Now that you mention it, moving the starting point back to accommodate how Open Rails converts path data from MSTS format to OR format does result in a significant change at the start of the activity. If you accelerate too much at the beginning you could blow right past the red signal! The other option I tested was to shorten the player consist to make it fit the length of track available at the original starting point - no need to move the starting point.. didn't like that. I did not check the differences in track layout between the Default Marias Pass Route and Marias Pass 5, there have to be difference. MP5 does look great. Cheers rhs (gerry)

[JeroenP]

I had a go at understanding the details of the ORTS placement related to the problems noted in the first post. I found that actually both issues do not seem to be related to placement itself.

I investigated the Morning Intermodal in quite some detail, using the latest source code and debugging what is going on in detail. What actually happens is that 'InitialTrainPlacement' fails. And the reason that it fails is due to the AI train coming from the other side. The AI trains start earlier and are being run (at 5s intervals) before the actual start of the activity. For the Morning Intermodal the "Traffic 01" AITrain moves along and clears the track in front of it. At some point in this run it clears the track where the player train is supposed to start. This startpoint is indeed just before a switch (or after the switch as seen from the AItrain). But being close to the switch is not important here. The relevant point is that the starting point is on a single-mainline track (also true for the AutoTrainSetout). So it is a point where the AI train has to pass as well. When the player train is placed after the pre-running of the AItrains, the 'InitialTrainPlacement' fails (and returns false). Even though the path (path from patfile, AIpath, and also the validRoute[0]) and also the frontTDBTraveller are on the intended track (the rearTDBTraveller is on the starting point and hence on the single mainline).

I have no idea what happens after the initial placement fails. Clearly, the train does appear. I guess it follows the wrong path, because at that point in time the switch has been set already by the oncoming AI train. But I am not sure here. I do know that the AItrain is still quite some distance away. So apparently the AItrain clears the tracks/signals for quite some distance (although perhaps in this case there are not a lot of switches and signals anymore between the AItrain and the start point of the player train).

Knowing the above, it is clear that delaying the AItrain is a workaround (which I have verified indeed). Removing the AItrains altogether also works (for both the Morning Intermodal as well as the AutoTrain setout). So if anyone is changing the activities, this gives other options that perhaps have less influence on the player train.

For the AutoTrain setout it is interesting to note that in v0.9 the default activitity starts on the wrong track indeed. But in the latests version of the source it actually starts fine. I guess some recent changes in the AItrain or signalling code might be the reason.

Given the analysis above it is clear that at least for these two examples the placement is not the issue. The difference between MSTS and ORTS seems to be related to the behaviour of the AItrains and the signalling. I cannot judge whether there is still a problem in the signalling/AItrains code, or whether the current code simply has side-effects on existing MSTS routes that have to be taken for granted.

Cheers, Jeroen.

[Sid P.]

Hi Jeroen- Interesting analysis, thanks.
There is another subtle difference between OR and MSTS in the startup processing that involves time.
I submitted a bug (Bug #1249872) to Launchpad for an activity that I created with Skyline Activity Generator for the Mactier route.
In "Auto Mode" an AI train appeared and collided head on with the Player train early in the activity without showing a red signal. But if I started running the activity in Manual mode, the signalling was correct. It turns out that AI trains created with start times within the 10 seconds before the start (creation) of the player train may not be handled completely. (See Rob Roeterdink's reply in (https://bugs.launchp...or/+bug/1249872) .
In this case the bug was fixed by starting the AI train a few seconds earlier (i.e. outside the 10 second window). This may apply to other activities as well, especially those created with the same template.
Further, I have been trying to fix an activity in Surfliner 1 ("Autoracks to San Diego") that involves some reversal points placed on a path that runs over several sets of switch points in the yard. OR cannot decide on the placement of the Player train, reports the problem and crashes on startup. So far, I have not been successful in making an OR version that duplicates the MSTS version completely. It is tricky running the activity in MSTS as well, so maybe it will not get translated to OR.
The lack of good documentation for the Activity Editor in MSTS contributes to the difficulty of modifying its activities to suit OR, as well.

I just updated to X1908, and the shadows are back. Great work!

[JeroenP]

Dear Rob (and others)
I investigated in more detail the issues related to wrong placement. I have attached a number of code-change proposals.

Basically I did two things.
First I started, based on your earlier comments, to rewrite AIPath.cs and PATfile.cs. I do not think I changed anything functional, I only did quite
some refactoring: removing outdated code, re-order and document code, make it more logical in places. I then also simplified a bit of code in AI.cs, Simulator.cs and OnlineTrains.cs related to calling AIPath. These pieces of code now no longer call PATfile directly. I also added some convenient constructors to Traveller.cs

Two comments on this refactoring
1. I did not think the code in itself was that complicated. However, it is certainly true that the interpretation of the various flags in .pat files is almost impossible without more documentation (or perhaps extensive investigate with route/path editor)
2. All of the refactoring does not solve the placement problem.

Therefore, secondly, I had a look at the actual placement, that is done in traveller.cs. Here also I started with refactoring the code in such a way that instead of placing the traveller on the track in various steps, first the code now checks whether placing will work. And only when (at the highest level) it is clear that the placing will work, then the placing on the track is actually done.
It is then relatively easy to not only check the first possible placing, but to check all possible placings. And find the most optimal one.

Basically this is indeed a rewrite as mentioned by James Ross in bug 1080735.

I verified that this solves the issue in Surfliner2 (bug 1080735). I also verified it on the Cumbres and Toltec Scenic Railroad (where it happens to be the initial placement of the train). In both cases I found that the requested worldLocation is indeed close to the originally selected track, but really on top of the correct track.

Since I am new to ORTS, I post the code here. But let me know if you prefer me to post it on launchpad. I guess you do not want me to check it in into SVN directly.

Best regards.
Jeroen.

Attached File(s)

•  TravellerPlacement.zip (37.38K)
  Number of downloads: 234

[roeter]

Thanks for your help - I'll have a look at it sometime over the weekend.
And placing the code here is quite fine, works just as well as Launchpad.

Regards,
Rob Roeterdink