[BUG n°1662150] Activity Mode, AI trains very late on Win 7 computers

[Looky1173]

Imported from https://bugs.launchpad.net/bugs/1662150

Property	Value
Reported by	Kevin (sd45)
Date reported	Mon, 06 Feb 2017 11:40:39 GMT

I created this activity, designed to showcase many Open Rails features.

http://www.trainsim.com/vbts/showthread.php?326579-CP-990-Oil-train-storage-run

The activity was designed to really put pressure on how well Open Rails delivers. I was throwing a lot at it intentionally, to see how well Open Rails held up and delivered clean activity execution. The activity featured 8 AI trains, of which 5 of those AIs share a common path that runs from one end of the route to the other. The remaining 3 AIs use short, custom paths related to loose-car switching.

The use of one long shared AI path is a common technique used by commercial content developers who release routes that also contain rolling stock and activities. These commercial developers have yet to really release any new routes specifically for the Open Rails platform.

The problem behind the creation of this bug report is the way all Windows 7 beta testing computers produced sufficiently late AI times, for all AI trains using the one long shared path, to the extent the activity could not be successfully completed without major "speeding" or other extreme improvisation by the player train.

The activity was built on a computer with these specs:

i7-4790K 4 core @4.0 Ghz, 16 GB ram, GTX 970, SSD, Win 8.1 Pro 64 bit

I sent the activity, along with screen grabs of my Open Rails options check boxes to multiple beta testers. "Late", "Early", or "On Time" is defined as a comparison to the activity creator PC results.

Beta tester 1 i7-6700 4 core @3.40 Ghz, 16 GB ram, 2 X 4GB NVidia video cards, SSD, Win 10 Pro 64bit AI fleet arrives ON TIME

Beta tester 2 i7-7700 4 core @3.6 Ghz, 16 GB ram, GTX 1070, SSD, Win 10 Home 64bit AI fleet arrives ON TIME

Beta tester 3 i5-2400 4 core @3.10 Ghz, 32GB ram, GTX 960, SSD, Win 7 Pro 64bit AI fleet arrives 5-10 minutes LATE

Beta tester 4 i7-4790 4 core @3.60 Ghz, 8 GB ram, GTX 760, Win 7 Home 64bit AI fleet arrives 5-10 minutes LATE

Beta tester 5 i7-3770 4 core @3.40 Ghz, 32 GB ram, GTX 650 Ti, Win 7 Pro 64 bit AI fleet arrives 5-10 minutes LATE

Beta tester 6 AMD A8-5500 4 core @3.20 Ghz, 8 GB ram, GTX 1060, Win 10 Home 64-bit AI fleet arrives ON TIME

I copied the exact same ORTS files and my Mactier test installation on the 8.1 desktop over to my old XP desktop. The only difference in settings was to uncheck LAA on the XP box.

AMD Athlon 64, 1 core @2.41 Ghz, 2 GB ram, Nvidia 7800 GS, HDD, Win XP 32 bit AI fleet arrives 15-30 seconds EARLY

All Windows 8.1, Windows 10, and Windows XP machines came in matching close enough (within 1 minute difference). All Windows 7 computers produced extremely late timings, enough to bust the activity.

You will never see commercial developers making activities for Open Rails if this can't work reliably. Possibly a short term work-around is using localized paths for all AI trains, but that is a step back from the MSTS days of being able to fleet multiple AI trains over the same long end-to-end path.

[Looky1173]

Imported from https://bugs.launchpad.net/or/+bug/1662150/comments/1

Property	Value
Posted by	Carlo Santucci (carlosanit1)
Date posted	Mon, 06 Feb 2017 21:28:57 GMT

Do all those people have used the same OR version? And which one did they use? Do all those people have set the same way the experimental options, as e.g. Forced Red at Station stops and Location-linked passing path processing? I have both Win7 and Win10 on my computer, but I don't have the payware, so unfortunately I can't test the issue.

[Looky1173]

Imported from https://bugs.launchpad.net/or/+bug/1662150/comments/2

Property	Value
Posted by	Kevin (sd45)
Date posted	Tue, 07 Feb 2017 00:40:08 GMT

I requested that the testers use 1.2 or the latest X version. The individual with the slowest processor (the i5) used X3770, I know because he sent me screen grabs. I sent all users screenshots of my options settings, so they knew what they were and could align to them if they wanted. Ultimately I have no control over their settings (but then neither do commercial content developers have any control over their customer's settings either)

I have a feeling this is not a recent development. You have to go back to before Windows 10 came out, when the vast majority of simmers were on Windows 7. I remember many claims as to how the activities bundled with payware routes seldom worked successfully in Open Rails. The biggest claim was AI timings were off and meets between trains no longer worked like they did in MSTS. Since Windows 10 came out as a free upgrade, the problem likely has subsided for many of them. I went direct from XP to 8.1, and to tell you the truth I never saw any widespread timing issues, aside from making a few minor changes to timings to suit my preferences. And I view 8.1 as more of a technological twin to 10 than it ever could be to 7 or Vista.

I'm trying to be more helpful to you all. The reason I chose payware for these demonstration activities is to place all the physics variables 'under one roof', ENG file values likely set and established by the same person. I chose Mactier route since it is a single track design where meet timing issues are more critical to clear the path for each other by a specific time (compared to double track routes where trains simply pass by each other unimpeded) and the rolling stock for it is more recent era physics (2013-era rather than 2009 or 2005).

[Looky1173]

Imported from https://bugs.launchpad.net/or/+bug/1662150/comments/3

Property	Value
Posted by	Carlo Santucci (carlosanit1)
Date posted	Tue, 07 Feb 2017 07:51:27 GMT

I think I'll build a test activity for the legacy Marias Pass route and let it run under Win7 and Win10 on my computer, and I'll see whether something changes.

[Looky1173]

Imported from https://bugs.launchpad.net/or/+bug/1662150/comments/4

Property	Value
Posted by	Kevin (sd45)
Date posted	Tue, 07 Feb 2017 14:57:56 GMT

If you use Marias Pass, I would suggest starting the AI at Shelby and using one long path across the route for your fleet of AIs. Start the player around Conkelley and time things so a meet happens on the single track around Coram or Belton. Where Open Rails has to 'calculate' the first AI position across that long path and insert it into the activity near the end of its long path at startup of the activity.

Another alternative

The Mactier route I used is free, available from the Trainsimulations website, so using that would employ the exact same signalling and other factors as used in my activities. The AI's fleeted out of Toronto, and the first AI meets the player train at Mactier, it pulls in while the player is still sitting there prior to departure. On the 8/10/XP machines, the first AI pulls in within 1:30 of the activity starting. On Win 7 desktops, it arrives almost 6:30 into the activity. I did deploy wait points at 2 spots along that one long AI path, so that is a factor in my AI arrival times, but ALL AIs using that one path were delayed equal time by the same wait points. In my activity, AI5 meets the player train almost half-way through the route, and according to win 7 testers, that one arrives 10 minutes late. AI8 near the end of the player run, and near the start of the AIs journey across the long path, is less than 2 minutes off.

I could also work from my end and 'de-payware' the rolling stock, and send you my activity as I have it for the Mactier Route.

[Looky1173]

Imported from https://bugs.launchpad.net/or/+bug/1662150/comments/5

Property	Value
Posted by	Carlo Santucci (carlosanit1)
Date posted	Tue, 07 Feb 2017 15:24:57 GMT

Kevin, I've decided to use the Moffat Tunnel instead, because it is completely single track and am just running it. If I don't get variations between Win7 and Win10, your proposal to de-payware your activity could be interesting. I'll let you know.

[Looky1173]

Imported from https://bugs.launchpad.net/or/+bug/1662150/comments/6

Property	Value
Posted by	Carlo Santucci (carlosanit1)
Date posted	Thu, 09 Feb 2017 11:26:57 GMT

An accurate analysis showed that the problem is due to different versions of sigcfg.dat, and not to Windows version or to OR issues. Therefore I mark this bug as invalid.