Problems With Trainsimulations BNSF Scenic Subdivision Demo Route

[niknak]

If you go into manual mode then back to auto mode, the signal goes back to normal.

Thanks to Gerry.

Thank you both. I'll try and remember that next time

[pschlik]

Excessive derailment detection is often a product of poorly defined superelevation and/or poorly defined rolling stock. The starter route has nothing defined for either, so it's all default data...and default data isn't the pinnacle of accuracy. It's still effectively an MSTS route with dds textures thrown in.

[R. Steele]

If you go into manual mode then back to auto mode, the signal goes back to normal.

Thanks to Gerry.

Thanks for the nod Derek ---- I have discovered that while this "work around" does reset the signals --- it can upset the AI train logic in OR. Under conditions I have not been able to reproduce --- resetting the signals can cause an oncoming AI train to stop at a signal and not proceed -- or -- to use an alternate passing path path. Both times this happened to me I was able to use a save to resume the simulation at a different point, reset the signals, and avoid scrambling the AI logic.

Certain routes, seem especially prone to this red signal problem upon resuming the simulation from a save point....probably take a signal expert to figure out why.

[meeshu]

If you go into manual mode then back to auto mode, the signal goes back to normal.

Thanks to Gerry.

Noted, thank you.

But this workaround shouldn't really be necessary if the route (and consists) were properly designed to begin with(?)

From observed behavior of the route while running consists, it seems that there are inherent issues with the route due to signalling and derailing problems.

[derekmorton]

I suggest that you run the route with the latest version of OR before making comments like that.

[meeshu]

What is the weight of the cars that are derailing? It seems cars that are unrealistically light will often derail. Also I have noticed if there is an error in the cars wag file regarding the cars weight it will derail on any curve at any speed.

The weight of the derailing cars varies a bit. Car 0-11, which frequently derails, is an empty well car with a mass of 17.5 t. Other cars that derail were loaded with a total mass of either 67.5 t or 88 t. Some of these other cars include - 0-5, 0-8, 0-31, and 0-32. So car mass seems to be largely irrelevant as to which car derails (apart from car 0-11 perhaps).

I had a look at the derailing car respective *.wag files and compared them to non-derailing car *.wag files. I didn't find any obvious discrepancies/errors within any of the *.wag files.

So it seems the car derailing is most likely caused by some issue with the route itself.

[meeshu]

I suggest that you run the route with the latest version of OR before making comments like that.

OK. Ran Open Rails testing version 1.5.1-1417 (latest as of an hour or so ago) on this demo route and again ran the activity What Goes Up.

First the good news. The anomalous signal near MP 1726 is no longer an anomaly. The signal shows up within the Track Monitor and indicates clear (green) signal and appears to function as intended.

OR_testing_1.5.1-1417_signal_derailment.png

The bad news as seen in the screenshot is that there was another car derailment.

The invisible switch is still invisible and can only be seen within the Track Monitor.

OR_testing_1.5.1-1417_invisible_switch_derailment.png

Again, there was also another car derailment as seen in the screenshot.

Remaining screenshots show more car derailments.

OR_testing_1.5.1-1417_derailment_3.png
OR_testing_1.5.1-1417_derailment_2.png
OR_testing_1.5.1-1417_derailment_1.png
OR_testing_1.5.1-1417_derailment_0.png

Overall, there seems to be a slight improvement (with less issues occurring) when running OR testing 1.5.1-1417 with respect to OR 1.5.1 stable.

The mysterious signal has been fixed and is no longer mysterious.

There are still quite a few car derailments, but perhaps not quite as many as when running under OR 1.5.1 stable.

The still remaining invisible switch is distracting and should really be removed (if possible).

[derekmorton]

I get no derailment warnings doing this activity with the latest unstable, so its something in your settings.

Log is from the latest ORNYMG with the same result.
OpenRailsLog.txt

You can see my settings with the log, the activity is different.

[meeshu]

Tried the activity What Goes Up again this time running under Open Rails New Year Monogame version 159.

I got a similar result as that for OR testing version 1.5.1-1217. That is, I still got car derailments occurring and invisible switch.

To be clear, the route I'm running is BNSF Scenic Subdivision Demo which was downloaded directly from Trainsimulations about a week or two ago.

The activity I'm running is What Goes Up using the default consist for this activity.

[geepster775]

I replaced the consist for 'what goes up' with a mullan consist of 53 foot spines with mullan physics, and emptied one middle well on the second set near the head end, and also emptied a leading well deeper in the train, and still got derailment messages for both. Near the foss river bridge, even the loaded wells right behind the power's drawbar also stringlined.

The invisible switch is likely showing on the track monitor due to this message in the log. Every time a zero degree node shows up, I get that line in the log.

"Information: Reindexing semaphore entries of signal type bnsf_switch for compatibility with MSTS"

[kapitaen]

The invisible switch is likely showing on the track monitor due to this message in the log

This switch is displayed because two switch are actually installed there.

Screen Shot 12-08-24 at 03.46 PM.jpg

Screen Shot 12-08-24 at 03.45 PM.jpg

Jan

[eric]

Yep, the zero node switches were used as a workaround to fix issues in MSTS on excessively long track nodes. Those could be safely removed, but would then break every activity and path expecting that node to be there.

[geepster775]

Yes, I know they are actually there. I've been deleting them while reworking the activities

I'm just saying the arrows dont show in MSTS track monitor, but do show in OR, likely because of that longstanding issue with that "re-indexing semaphore" message, whatever that means. I believe it is also related to why position lights on the pokey work right in MSTS but are odd acting, sometimes dark, in OR.

Something was coded differently that requires changes to signal scripts, that nobody has made evidently.

[kapitaen]

Sorry, im too late.

Jan

[R. Steele]

If all the folks in this thread that are posting about the "vestigial" defects of MSTS of this free route, please try the new SP Shasta...beware -- it is payware --- and does not have any of the MSTS vestigial defects....it was made for OR.

I wouldn't blame TS for pulling this route, they sure in heck are not going to invest their valuable time in reworking it. I'd much rather see the new SandPatch and other routes in the pipeline.

So ---

why don't some of you talented people with the know how --- correct the route?