Scalerail and Scailroads issues

[PXSE]

I'm having a hard time with some ScaleRail and ScaleRoad issues in Open Rails.

In this video published over a year ago, you can see a train on the 3DTrains Feather River route running with Open Rails super-elevation enabled

https://www.youtube.com/watch?v=D7ieotxZn0o

When I execute the same activity with super-elevation on and running with today's version of Open Rails, I get Kuju-like track substitutions that are not seen in the year old video. Why is that?



Also, since there is no Streamlines rolling stock pack for Sherman Hill released to the public yet, I installed Sherman in the same ORTS installation as my Feather River Route that contained the Streamlines UP equipment pack, so I can run some of the Feather River UP stock and consists on Sherman in the meantime. However, when these 2 routes are installed in the same ORTS profile and share the same Global folder, it appears that the later Sherman installation has over-written and clobbered some ScaleRoads files originally installed by and needed by the earlier Feather River. Why is that?

[PXSE]

Adding to those issues, it seems that the ScaleRoads necessary to run the Streamlines Green River Route are equally boogered, although my DRG&W routes reside in a different ORTS profile and share the Global folder with other DRG&W routes that require only Xtracks and NewRoads. I think the payware Green River is the only DRG&W route build with ScaleRoads. I also think the DRG&W installation is still at TSection 38. The combined Feather River and Sherman ORTS installation uses the experimental version 44 required by Sherman.

Does anybody know if the Green River installer comes with a separate ScaleRoads trojan installer embedded in it, or whether when you say yes to installing ScaleRoads it pulls the needed files from a files cache on the 3DTrains server, and perhaps these files have been changed since that Streamlines route was first released 5 years ago?





And of course, who doesn't know of the issue with Sherman producing white tracks when you have super-elevation turned on. You can see from the photos, Open Rails is again attempting to substitute Kuju-like tracks, it's hard to tell, but you can see from the side shadow in the first pic below that those locomotive wheels are riding on 'fat rails'. Is this track white because Sherman is missing some textures in its routes/textures folder to make the Kuju-like replacements display properly? Or is it a function of 3DTrains doing something different with newer Sherman track shapes to 'discourage' the use of Superelevation? When I bought Sherman in 2015, I recall getting the first large download about 600-700K in size, and then a patch of some sort for ScaleRail while the topic of 'beta ScaleRail version 2.0' was being bantered around on the forums. What did that ScaleRail patch do to Sherman?

Every time someone questions the white tracks, Marc Nelson quick to hop in and say "disable Superelevation". True, that's a quick fix, but not really an answer. We have the feature, we need to be able to use it.

I'm an astute fella, and all of these issues simply do not pass the smell test as being innocent blunders or mistakes. I find it funny that one 3Dtrains route can clobber another 3DTrains route when you simply run their respective installers in a shared installation. Yes, I probably would say that all the 'low hanging fruit', revenue-wise, has probably been plucked from the Feather River tree, so its of lesser economic consequences that the newer shall clobber the older, but really.....

I wonder if the contortions done to the track by the super-elevation function of Open Rails was considered a 'derivative use' of the ScaleRail track profile by 'someone' and there was some sort of IP fight behind the curtains that have since disabled the appearances of what you see in that year old video.

With many route projects taking over 5 years to complete, where the version that the route builder has installed can become obsolete before the route is released, is this an intentional obsolescence disablement pattern of Scale_____ products and is that something route builders should be giving a little bit more thought to?



In the last picture, with super-elevation on, the one track that the engine is on is not super-elevated (no tilt to the engine) and still displays properly, while the other one is responding to the ORTS super-elevation function. Haven't dug in to see how that track piece may be different from the rest.

[lateagain]

This reminds me of a few OR Cab View issues I've had.

I assume by the screengrabs you're running OR in 16x9 aspect ratio? I was. Why wouldn't you? After all 16x9 is the current aspect ratio for most monitors.

Just out of interest, and if nothing else to rule this out, try running the routes in the original MSTS aspect ratios? Does the problem go away?

I'm not saying this is the solution but in my research into the Cab View issues this did play a part.

[baldwin]

From the Open Rails manual:-
OR implements super elevated tracks using Dynamic Tracks. You can change the appearance of
tracks by creating a TrProfile.sft in the TrackProfiles folder of your route. The document “How to
Provide Track Profiles for Open Rails Dynamic Track.docm” describing the creation of track
profiles can be found in the OpenRails /Trunk/Source/Documentation folder

[crstagg]

Adding to those issues, it seems that the ScaleRoads necessary to run the Streamlines Green River Route are equally boogered, although my DRG&W routes reside in a different ORTS profile and share the Global folder with other DRG&W routes that require only Xtracks and NewRoads. I think the payware Green River is the only DRG&W route build with ScaleRoads. I also think the DRG&W installation is still at TSection 38. The combined Feather River and Sherman ORTS installation uses the experimental version 44 required by Sherman.

Does anybody know if the Green River installer comes with a separate ScaleRoads trojan installer embedded in it, or whether when you say yes to installing ScaleRoads it pulls the needed files from a files cache on the 3DTrains server, and perhaps these files have been changed since that Streamlines route was first released 5 years ago?

..............

ScaleRoads is NOT a requirement for the Streamlines Green River Route.
See http://www.trainsimulations.net/msts-routes.html which I quote here:
"System Requirements

• Microsoft® Train Simulator (1.0 or higher)
• 256 MB 3D video card (minimum)
• 1.1 GB of available hard disk space
• 1 GB computer memory (RAM)
• Xtracks Track System (included with the product installer)
• MSTSbin (For improved performance and physics handling)
• Adobe Acrobat (for documentation)"

[geepster775]

It's not a separate package requirement, but the route does come with 165 pieces of Scaleroads (330 total files between .s and .sd) that goes into global. That's probably why TSN doesn't list it as a line item requirement. It looks to me like an early version of the road package because the road pieces have only one yellow median lane stripe.

When you install Green River, the installer unpacks as follows -

Installs SR_ files
Installs documentation
Install the route files
Installs the rolling stock from a separate package
Prompts for permission to run the XTracks installer inside. If you decline, it places the entire XTracks zipped package on your hard drive, unopened.

If you unpack the route into a fresh OR install, and then any other reason comes along to install Scaleroads again, or if you copy over a template version of the global folder that contains the whole enchilada with the works (Xtracks, NewRoads, Scalerail, Scaleroads, etc) you could possibly be overwriting the files supplied by the route installer with a newer version of the roads in your template.

Looks like the same scenario between the WP3 and Cheyenne routes as well, where the newer route using a newer version of the roads is overwriting the older route built with an earlier version when they share the same Global folder. I guess it's best to mini-route them both, even through the routes doc's don't mention much in terms of that need.

[geepster775]

From the Open Rails manual:-
OR implements super elevated tracks using Dynamic Tracks. You can change the appearance of
tracks by creating a TrProfile.sft in the TrackProfiles folder of your route. The document “How to
Provide Track Profiles for Open Rails Dynamic Track.docm” describing the creation of track
profiles can be found in the OpenRails /Trunk/Source/Documentation folder

Always nice to hear from the manual.... hehehe

Although, I doubt 99% of the user base has little interest in running out and getting an advanced math degree to decipher that. Seems more prudent that one person who is capable of splitting that atom do so and then share it. Ideally, any special profiles needed should be distributed with the route rather than rely upon secondhand distribution, creating a route product fully enjoyable to both sim audiences.

I took curious note of the OP's top screenie that shows how Open Rails is elevating a spur track with a gravel pile playing bumper post. Shouldn't OR have common sense to not do that? Be able to differentiate between a mainline track and a rusty spur and know when it is appropriate and not?

[geepster775]

With many route projects taking over 5 years to complete, where the version that the route builder has installed can become obsolete before the route is released, is this an intentional obsolescence disablement pattern of Scale_____ products and is that something route builders should be giving a little bit more thought to?

I believe that populating changes to Tsection/Global requires a certain degree of respect. It's eternal legacy factors doesn't support do-overs all that well, and some of these rail and road packages have been re-freshed a couple of times. Not too critical of a problem when everything had to be mini-routed under MSTS, but with extreme compartmentalization becoming less of a need under Open Rails, a sloppy do-over affecting Global can create bigger problems if what is being re-worked is not documented thoroughly. Time for the tinkerers of Global to come down from the MSTS-only tree and adjust their practices accordingly.

[R. Steele]

...I took curious note of the OP's top screenie that shows how Open Rails is elevating a spur track with a gravel pile playing bumper post. Shouldn't OR have common sense to not do that? Be able to differentiate between a mainline track and a rusty spur and know when it is appropriate and not?

Quite agree.