Problems with ORTS starting some default activities for default Marias Pass
#1
Posted 05 December 2013 - 02:39 PM
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.
#2
Posted 05 December 2013 - 04:44 PM
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
#3
Posted 05 December 2013 - 05:10 PM
#4
Posted 06 December 2013 - 12:10 AM
#5
Posted 06 December 2013 - 09:32 AM
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,
#6
Posted 06 December 2013 - 10:15 AM
Sid P., on 06 December 2013 - 09:32 AM, said:
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)
#7
Posted 28 December 2013 - 10:01 PM
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.
#8
Posted 29 December 2013 - 02:37 PM
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!
#9
Posted 17 January 2014 - 01:15 PM
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
#10
Posted 17 January 2014 - 01:26 PM
And placing the code here is quite fine, works just as well as Launchpad.
Regards,
Rob Roeterdink