ORTS TrackViewer Player Path Wait Points

[ekeating]

Hey all,

I was making an activity where the player train is to stop at a red signal momentarily. Simulating a hyrail getting off the tracks and clearing the mainline. To do so, I placed a 2 minute wait point short of the red signal. I approached the stop signal and stopped on the wait point for approximately 5 minutes. If I had to guess, I had the train stopped on the wait pint about 3 cars back from the lead locomotives (60+ car freight train). In theory, the signal would have cleared once the wait point expired, but that never occurred. Instead, after about 7 minutes I placed the signalling in manual mode, cleared the signal, and placed it back into auto mode once the signal had been knocked down. I didn't have any further issues the rest of the trip.

I was curious if anyone else has seen this pop up in activities they've made and may be able to provide insight. I went back and double-checked my path just make sure there wasn't anything that I may have overlooked in the path creation! Although this certainly isn't a severe compromise in the experience, I'm attempting to gain a better concept of what to expect in future activities where I wish for an AI train to overtake the player train. Additional info, this was on TrainSimulations' ORTS version of the BNSF Seligman Subdivision 2.0. I'm using the current stable install of ORTS v1.3.1.

Let me know if any more information is needed. Thank you all in advance!

EK

[geepster775]

Never had a wait point fail to behave normally, but have had differences in perceived location vs actual location.

Suggestions: Have autopilot stop the train at the interpreted location and see how far off that was from the intended location. Adjust in the path accordingly. Watch the dispatcher screen under the F5 hud, and see the time the computer has scheduled the wait point to expire and compare with the actual clock. The only time I had the clock expire without the signal clearing is when other traffic had already been committed to the track segment.

[csantucci]

EK's problem has occurred to me recently. I went digging in the code, and found that the train wasn't really stopped, but had a speed of, let's say, 0.00001 mph. This is not a problem of the player, but a precision problem of the physics. Being the test to start the WP count a test for a full zero speed, the WP never started counting.
Usually this is solved by releasing all brakes (also the dynamic one) and applying them again.
Even simpler, actual Unstable and OR NewYear MG revisions have introduced a certain tolerance in the 0 speed check, so that the problem should no more occur.

[ekeating]

EK's problem has occurred to me recently. I went digging in the code, and found that the train wasn't really stopped, but had a speed of, let's say, 0.00001 mph. This is not a problem of the player, but a precision problem of the physics. Being the test to start the WP count a test for a full zero speed, the WP never started counting.

This makes sense. At the wait point in this particular scenario, the player train is waiting on a noticeable descent at the stop signal. Given slack rolling in and out and the possibility of the train physically moving slower than a speed noticeable to the naked eye. I'm willing to believe that this may have been in the case in my instance.

I also reloaded the activity and some save points that I had. When looking at the "dispatcher screen" Shift+F5 HUD menu, I noticed that the AUX wait point was not showing for the player trains. They were showing for all other AI trains (I use wait points to simulate crew changes at the ends of the route). Is this a phenomenon others have seen before also? Also, would it be suggested to update my ORTS from the stable 1.3.1 to the latest unstable or NewYear MG versions? Full disclosure, I haven't done much research at all into these newer updates.

EK