[railguy]

I've been going to post about this for way over a year--I'm finally getting around to it. Here is some background. This concerns the revised Blackfoot Route, commonly referred to as "Blackfoot 3." It is, in my opinion, one of the finest routes in the MSTS/OR realm, beautifully detailed and rendered. However, it has on vexing issue that I've not been able to solve. For those unfamiliar with Blackfoot 3, it is an unsignaled route running some 110 miles =/-. I've built numerous activities for the route, with paths built in TrackViewer.

Now, the problem. In any activity that I run, trains run out of authority near Milepost 104 (latlong 53.161130 -110.179). To run past the point (eastbound or westbound), the player must go to manual mode, otherwise the train will show off path/no authority. Oddly, AI trains will run right past that point without issue, even when using the same path defined for player trains. Trackviewer shows no errors when drawing the paths. Looking at the spot in TSRE does not show any readily apparent issue. I'm not an expert in tracklaying and route building, so I don't know if there is some track issue right there that I can't recognize, or some track database error. I don't see anything in the OR logfile that would indicate an issue, so far as I can tell. This problem has occurred in multiple versions of NY Monogame for over a year. Routeriter also shows no errors.

I'm curious to know if anyone else has run into this problem on this route, or if my route has some "glitch" in it somewhere. I don't want to re-install the route because I have added some scenery objects, etc. that I would have to redo--I have not, so far as I know, touched any of the track work whatsoever. Does OR have some limit or anything on a "dark" route that would affect track authority and why would it occur at the same point both eastbound and westbound? Any thoughts or advice appreciated.

[Weter]

Hello.
I'm not experienced route builder yet, however I've seen on our MSTS routes so-called "zero-switches": they are invisible, but have to be inserted in the long 1-track stretches without intermediate signals and real switches, for some reason, I didn't learn yet. They can be seen in MSTS AE as switches (black circles), but with only two exits, not three/four, as real switches/frogs/xovers have. Player shouldn't press G in free rides to avoid sudden derailments.

About route: static objects are listed in world *.w-files, while track vectors - in *.tdb-file of all the route, so You can experiment with copy of a Your customized route, "reinstalling" TDB-file only...

Good luck!

[railguy]

I keep several backup copies of all my MSTS/OR installations. I did some checking--the following track-related Blackfoot 3 files were modified on the same day in late 2022: the .rdb, .rit, .tdb, .tit, and tseection.dat files. I have a backup copy from 2017 of all of those files, except the tsection.dat file. Are you suggesting (and I have thought about it) just replacing the 2022 .tdb file with the older 2017 .tdb file to see if that solves the issue?

[Weter]

TDB and RDB are keeping vectors and nodes for roads and tracks (the trajectory, rolling stock's wheels and car spawners should follow).
They refer to global Tsection.dat file's entries, calling data from there.
TIT and RIT are separate "lists" of items, belonging tracks and roads (for example, crossings, platform&siding markers, etc.) AFAIK, these are not used in ORTS. tsection.dat inside the route's folder is description of all dynamic track pieces, present on the route.
World files keep position info and shape names for all visible objects on the route, which are static and visible tracks and roads pieces.
There's a risk, if common ID numbers of track sections are used in TDB and W files, that they wouldn't match, but having enough of disk space for testing copy of the route - You can try.

But description in the first post hints, that the issue could be with signaling interpretation (or path processing) function for the player's train, but not with the route...

I'd advice to wait or ask for elaboration, about real purpose of invisible switches on long stretches - and about could they (or their absence) be the reason of described issues.

[railguy]

For further information, this is what I found when I zoomed in on the trouble spot in TrackViewer. Screenshot of TrackViewer attached. Edit: Here is what I've established. The point shown in the screenshot is a "junction." Apparently it is some defect in the track. When re-drawing this path (or drawing any path), TrackViewer will allow the path to be drawn right over this junction. However, once the path is saved and then re-opened, the broken node (at the junction) shows up again and the path shows as broken. I'm going to try some additional experiments with other paths to see if there is some pattern. Edit 2: After creating some test paths, I found the pattern--only westbound paths are affected. Totally strange.

Attached thumbnail(s)

• 

[R H Steele]

railguy, on 29 July 2024 - 12:03 PM, said:

...the broken node (at the junction) shows up again and the path shows as broken....

Have you tried using TrackViewer to fix the broken node? Alternative: have you tried drawing the path past the node, cutting and storing the tail, the redrawing the path and add the stored tail. Try some tricks with the trackviewer.
Trackviewer manual sections 6.9 and 6.9.1 deal with fixing broken nodes.

OR .... try this, start the path just past the point in question and draw to its end. Save Path, the use the mouse and drag the start point back past the broken node, and save path. ( with cursor on desired node -- control+left mouse = drag nodes )

[railguy]

I've tried everything that you've suggested, except the last one of dragging the start point back past the broken node. I'll try that one right now and report back.

Edit: Tried dragging the start point back over the node. Successfully moved the start point, then saved the path. Closed TrackViewer and OR. Relaunched OR and TrackViewer. Opened the .pat file--broken at the node. I have to conclude that it is some sort of track defect that only affects westbound paths.

[R H Steele]

A weird defect for sure. Have you tried contacting Rory or any of the other team members listed in the route's readme?

[railguy]

I haven't tried contacting them, however, I went back to my archived copy of the route made shortly after I downloaded the route back in 2017. The defect was present then, so I suspect that it has been in the route all along. Since it is near the west end of the route, and doesn't affect eastbound paths, it likely won't be noticed unless the activity uses a westbound AI that has to get past the defect to interact with an eastbound player train. In the case of a westbound train, the player must go into manual mode to get past the defect. That doesn't create a huge issue, as the route is unsignaled, anyway.