Problems With Trainsimulations BNSF Scenic Subdivision Demo Route

[meeshu]

Tried to run the activity What Goes Up for BNSF Scenic Subdivision Demo route by Trainsimulations.

Running the activity with Open Rails version 1.5.1 stable.

First issue is the frequent message appearing that cars x have derailed despite driving well below the track speed limit and going around gentle track curves. Train speed around 12 mph for track speeds 25 mph and then 20 mph.

Getting frequent messages about car derailments left, right, and center!!!?? Car 0-11 seems to be the principle car that "derails" the most often, with other derailing cars including 0-31, 0-5, and 0-8.

Then the Track Monitor shows a switch which suggests a siding or alternate track route is ahead but on arrival at the switch point (as shown on the Track Monitor) there is no switch and no other track!

All this occurs for only running the activity for about 10 minutes or so.

The frequent car derailing messages seem to be wrong? Cars shouldn't be derailing so frequently at low track speeds and in gentle curves? Is there some bug in the route and or bugs within the cars *.wag files? I haven't checked the cars derailing force statements within their respective *.wag files yet.

And the apparent invisible switch to nowhere? On a quick forum search for this invisible switch issue, it seems these invisible switches may be placed within routes as an aid to prevent broken couplers occurring? If so, these switches are distracting in the Track Monitor in that you are expecting your train to move over to another track shortly but that is not the case. A way around broken couplers is to increase coupler strength values within locomotive and car *.eng and *.wag files respectively I would have thought, and do away with these invisible switches.

[slipperman]

Hi meeshu,
After all the time it's been available. I doubt the problem is with the route.

The 'invisible switches' were only required in MSTS. As this is a demo route for Open Rails, I doubt it contains any such switches (but I could be wrong!).

If you've not made any changes to the route, it's more likely that the problem is due to some setting/s you've made.

Cheers,
Ged

[eric]

Keep in mind there have been different versions of the Demo route. Only use what comes with that particular installer, as something downloaded from here might be for a different version.

[meeshu]

Thanks for the comments.

I haven't (intentionally) made any setting changes to Open Rails version 1.5.1 stable. I haven't made any changes to the demo route nor any of its activities, consists, cars and locomotives.

The Demo route was downloaded direct from Trainsimulations recently. The activity What Goes Up is the default activity that comes with the demo route.

So the questions still remain with regards to invisible switches and frequent derailing cars while running this default route under OR 1.5.1 stable.

[niknak]

I remembered some problem like this with the activity from aeons ago so I've just downloaded the BNSF Scenic route and it's trainset again and run the 'What Goes Up' activity. I only tried the 1st few minutes but I can confirm that car 0-11 derails at 12.12 and cars 0-39 and 0-41 derail at 12.13. This is with a clean install of the route and trainset, consist etc. I've attached the log although it doesn't show the derails. btw I ran the beginning of the act again in autopilot with no derails but I guess that's autopilot's physics for you lol.

[R. Steele]

So the questions still remain with regards to invisible switches and frequent derailing cars while running this default route under OR 1.5.1 stable.

Many routes made for MSTS have invisible switches... OR ignores them. BUT they still show up as switches in the monitor.

A way around broken couplers is to increase coupler strength values within locomotive and car *.eng and *.wag files respectively I would have thought, and do away with these invisible switches.

True for MSTS, OR should have couplers set for real values.

Yes, newer routes made for OR, such as the Mullan and SP Shasta, etc.... do not have buried hidden switches.

RE: frequent derailing of cars message, many MSTS routes had curves and even straight sections ( Powder River for instance -- see attached image ) where you get the derailing message in OR, bad data from old routes, either ignore it or turn off "Curve Dependent Speed Limit" Options/Simulation.

Capture.jpg

[R. Steele]

btw I ran the beginning of the act again in autopilot with no derails but I guess that's autopilot's physics for you lol.

Yep, autopilot dispenses with all the derail messages, and other operational niceties.

[niknak]

Thanks for the info Gerry.

[geepster775]

I would have thought that either deselecting "advanced adhesion model" or selecting "simple controls and physics" would make the derailment messages stop, but no.

The derailment messages involve empty well cars. I don't think the current coding reflects reality all that well, as its damn near impossible to stringline one empty well that shares articulated trucks with two adjacent loads. But yet, that is what is happening here.

Probably need to check and see if the dumbing down of the rolling stock in between version changes (taking away the OR Seligman spine cars and reverting to older stock with MSTS physics) is having an effect here.

[meeshu]

Thanks for the detailed replies!

As far as the car derailments are concerned, and apart from legitimate derailments due to string lining, excessive speed etc, this is otherwise (apparently) caused by "bad (route) data"?

So the route is basically bugged and should be fixed. Could Route Riter, or other software, correct bad route data and hence eliminate these unintentional car derailments?

By the way I've come across another anomaly while running this demo route. A stop signal with signal pole appeared near MP 1726 as seen via locomotive cab and outside views, but was not shown in the Track Monitor!? Train passed this anomalous signal without issue despite being a stop.

Open Rails 2024-12-06 10-15-02.png

[oper190]

By the way I've come across another anomaly while running this demo route. A stop signal with signal pole appeared near MP 1726 as seen via locomotive cab and outside views, but was not shown in the Track Monitor!? Train passed this anomalous signal without issue despite being a stop.

Just an FYI - I've seen those in other Routes too. A signal script issue perhaps?

[niknak]

This sometimes happens to me upon resuming a save in various routes. For example it's just happened whilst running an activity on 3DTS Donner Pass. Once I'm past that red signal then all other signals begin to appear in the track Monitor as normal.

[Sleepy]

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.

[derekmorton]

A stop signal with signal pole appeared near MP 1726 as seen via locomotive cab and outside views, but was not shown in the Track Monitor!? Train passed this anomalous signal without issue despite being a stop

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

Thanks to Gerry.

[R. Steele]

this is otherwise (apparently) caused by "bad (route) data"?

So the route is basically bugged and should be fixed. Could Route Riter, or other software, correct bad route data and hence eliminate these unintentional car derailments?

I am not a route builder....however, sticking my dang neck out ( caveat - this is my crude explanation ) --- the trackage is simply a series of vectors --- strings of numbers or data if you will, that the simulator uses to find the "path" for the rendered track in the sim.

It takes a real craft/talent to properly lay track, MOST especially with a tool like the MSTS RE. There aren't too many of them in this hobby, you could probably count them on one hand. All sorts of talented & untalented people have created routes and laying the track is probably the most important aspect of it. SO any mistakes, higgery-jiggery, jerry-rigging, or improvisational short-cuts could result in bad numbers in the track vectors....trains will -- more than likely -- still run --- but you could expect odd things to happen under the right circumstances. Not to mention, the code in OR for those particular derailment warnings may still need improvements and refinements....to meet all anticipated cases.

...and if this (ill-advised - in my opinion ) explanation is so far out of bounds as to be ridiculous, someone please provide a serious knowledge-based explanation.