Problems With Trainsimulations BNSF Scenic Subdivision Demo Route

[oper190]

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.

I noticed that too, and had to rewrite a few sections of the sigcfg file - adding missing(?) SignalDrawStates - or it was it meant to be that way? OR seems less forgiving than MSTS was, it actually follows the script.

As to the no show "red" signals, I've only noticed it happening only on certain Routes. Will note which ones from now on. It appears to be only with Permissive Signals. I simply ignore them when I see they are not on the Track Monitor and going past them with no problem. Then the Track Monitor works properly showing signals. Why?????

[kapitaen]

All existing errors in ACTIVITIES "1_WhatGoesUp" are eliminated with the attached correction . The re-indexing semaphore error has also been eliminated.

Jan

download removed

[eric]

Jan, what was the nature of the fix?

[meeshu]

All existing errors in ACTIVITIES "1_WhatGoesUp" are eliminated with the attached correction . The re-indexing semaphore error has also been eliminated.

Jan

[ATTACH]n2316344[/ATTACH]

Thank you for your "fix".

Tested this fix under -

Open Rails 1.5.1 stable, Open Rails 1.5.1 - 1417 testing, and Open Rails New Year MonoGame v 159

For Open Rails v 1.5.1 stable, still had quite a few car derailments. The invisible switch still shows up in the Track Monitor. The mystery signal a bit further up the track now seems to be functioning normally, thank you.

For Open Rails 1.5.1 - 1417 testing, there seemed to be less car derailments, but still there were car derailments. Invisible switch still showing in the Track Monitor. Mystery signal working as it should be.

For Open Rails New Year MonoGame v 159, the result was about the same as for Open Rails 1.5.1 - 1417 testing with apparently fewer car derailments. Invisible switch still seen in the Track Monitor. Upstream signal now functioning normally.

So it appears that some more work is still required to remove all errors (if possible).

[kapitaen]

Jan, what was the nature of the fix?

List follows

Information: No route track gauge given in TRK, using default setting: 4.708 ft
Information: No track profiles found in TrackProfiles folder, using default track profile.​​

Track gauge, ORTSTrackGauge and ORTSForceSuperElevation set in BNSF_Scenic.trk.
TrackProfiles Default Track added in TRACKPROFILES Folder

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

This is not an error, just information. OpenRails corrects the signal script automatically. MEESHU is wrong to get upset.
SemaphorePos in OPENRAILS/sig.cfg manually corrected.

Warning: Signal referenced in .w file -12819 14715 as TrItem 146 not present in .tdb file​

w-012819+014715.w, manually corrected.

Warning: When expecting a number, we found a ) marker. Using the default -1 in C:\TrainSimulations\ROUTES\BNSF_Scenic\ENVFILES\WinterClear.env:line 153
Warning: When expecting a number, we found a ) marker. Using the default -1 in C:\TrainSimulations\ROUTES\BNSF_Scenic\ENVFILES\WinterClear.env:line 185
Warning: Skipped extra world_water_layer in C:\TrainSimulations\ROUTES\BNSF_Scenic\ENVFILES\WinterClear.env:line 302​

ENVFILES/WinterClear.env, world_sky_satellite_light set to -1, last world_water_layer deleted.

Information: Skipped unknown lighting model index 0 first seen in shape c:\trainsimulations\routes\bnsf_scenic\shapes\Concretesupportbase1.s​

lighting model in Concretesupportbase1.s set to -5.

SLI_BNSF_FREIGHT/ WagFiles, SOUND set to ..\\..\\TS_COMMON_SOUND\\platform_intermediate.sms .
TS_COMMON_SOUND/platform_intermediate.sms, 1 missing Stream fixed and set a closing bracket.

Invisible switch still showing in the Track Monitor.

If we remove the switches, we destroy all the paths and thus the ACTIVITIES. Why should we do that?

Jan

[geepster775]

Naturally, you should skip the trackprofile (which calls on Acleantrack) if you already have the US3 upgrade installed.

[kapitaen]

Naturally, you should skip the trackprofile (which calls on Acleantrack) if you already have the US3 upgrade installed.

However, this route installs the standard Kuju tracks via the Auto Installer and not US3.

Screen Shot 12-09-24 at 02.54 PM.jpg

Screen Shot 12-09-24 at 02.55 PM.jpg
Jan

[oper190]

The only real change from their earlier MSTS version of the route is the use of .dds textures with a newer track profile. If you upgrade to a different track profile you'll have to replace the track texture with .ace

[geepster775]

However, this route installs the standard Kuju tracks via the Auto Installer and not US3.

However, there is a conversion kit in the library with 984 downloads, File ID 84957, so quite a few need their trackprofile for US3 not to be overwritten with a profile for Kuju.

[kapitaen]

so quite a few need their trackprofile for US3 not to be overwritten with a profile for Kuju.

Good, agreed. I have removed the corrections.

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

This is apparently not desired.

Jan

[derekmorton]

Meeshu,

I have now got derailments with 11, 38 and 41.

Looking at what the cars are from and their settings reveals that these cars are from the same container 5 pack, they are also the only empty cars on the train.
A search reveals that these cars are widely used by TS on other routes.

At this point in time, the physics of 3 and 5 pack sets is difficult to set correctly.
The 2 ends have 2 axles each, but in between the cars are only 2 axles, so the physics for the cars is not the same.
The 2 end cars have 3 axles and the 3 ( in a 5 pack ) in the middle only have 2 axles.

The derailments that I have recorded so far have come from the middle 3 cars.

Does it still look like a route problem?

[niknak]

Meeshu,

I have now got derailments with 11, 38 and 41.

Looking at what the cars are from and their settings reveals that these cars are from the same container 5 pack, they are also the only empty cars on the train.
A search reveals that these cars are widely used by TS on other routes.

At this point in time, the physics of 3 and 5 pack sets is difficult to set correctly.
The 2 ends have 2 axles each, but in between the cars are only 2 axles, so the physics for the cars is not the same.
The 2 end cars have 3 axles and the 3 ( in a 5 pack ) in the middle only have 2 axles.

The derailments that I have recorded so far have come from the middle 3 cars.

Does it still look like a route problem?

I'm getting the same car numbers derailing.

[meeshu]

While running the BNSF Scenic Subdivision Demo route activity 'What Goes Up" once again, using the default consist, and running under Open Rails New Year Mono Game 159, I get the following derailing cars (in numerical order, not the order in which they derailed) -

0-8 loaded
0-11 empty
0-31 loaded
0.32 loaded
0-37 empty
0-38 empty
0-39 loaded
0-40 loaded
0-41 loaded

Car 0-11 seems to derail the most with about 4 or 5 occurrences, some other cars derail at least on two occasions, and a few cars derail once only.

I ran the activity only for about 30 minutes when I quit.

The derailments seem to occur at about the same positions along the route each time the activity is run.

[geepster775]

I think its both the routes and physics.

But it doesn't bother me that the code is advancing to the point where it separates the men from the boys, in terms of route engineering capabilities. Something eventually had to come along and separate the wheat from the chaff. The problem is, tho, there are a lot of freeware routes out there that ARE chaff, where the track laying was done by rank amateurs. And nobody can publicly admit such a 'crisis of crap' is looming lest they ruffle the feathers of the community harmony caucus.

I tend to agree with Derek that the physics of the articulated cars is not yet perfected. Here in North America, we developed the Husky Stack to deal with situations where the container loads are SO HEAVY that the weight exceeds the ability to share a 125 ton articulated truck with an adjacent load. Husky stacks take the form of one well platform supported by two pairs of freight car trucks, with no articulation, no weight sharing with the adjacent car's load. When no Husky Stack is available, they create them on-the-fly using 3 or 5 unit articulated cars. A 3 unit car is loaded only in the A and B position, and the middle C well remains empty. The middle empty well functions like a drawbar, connecting two outer wells whose load is supported by the equivalent of two individual truck pairs. On a 5 unit car, units A, B and D can carry heavy containers, while intermediates C and E must remain empty and where they, too, function as the equivalent to drawbars that connect the other 3 wells that are fully supported by their own dedicated pair of trucks. It is highly, highly, highly unlikely that these "faux drawbars" are capable of string-lining. But the physics of the sim doesn't seem to understand that.

[derekmorton]

Ok gents,

Getting further.

its not:-

DerailRailForce ( 2.5*67.5t ) - I tried 10 times the value
DerailBufferForce ( 171.5kN ) - I tried 10 times the value

I unticked curve dependent resistance.

Next was into the extended HUD, which showed:- Derailcoff going off the scale for car 11, the red value in the extended HUD.

I can't find a setting to change the derailcoff

I am going to report this as a bug.