Adding USTracks to your route

[Shawmut]

I've been converting my routes to the late Norbert Rieger's USTracks system (a derivation of his much larger DBTracks library) since Norbert came out with the system. Recently I've been involved in a test of ORTS physics, and used the venerable old chestnut, SLI/Trainsimulations.net's BNSF Scenic Route v.2 as my test bed route.

This route originally came out in April of 2006, and was built using the default set of Kuju tracks only, hence when this route's tsection.dat file was made it was based off of the original 2001 Kuju global tsection.dat.

Later, in 2011, SLI improved the route's scenery and updated the route's locomotive physics and sounds, included a whole new rolling stock folder, made new activities, and updated the signals and trackside infrastructure. They also added five Xtracks sections to the route, which is why the route came bundled with an Xtracks installer. The default tsection.dat file that overwrites the original Kuju one is Build 00038. SLI didn't rewrite the whole route, eschewing re-inventing the wheel in favor of simply adding those Xtracks shapes to the world files but not updating the route's local tsection.dat's numeration to coincide with the Build38 version of the global tsection.dat file that the route purchaser must now use to get the route to run.

As we shall see, this will have implications for the very reason I'm writing this thread.

But before I get into the nitty-gritty of techniques employed to lay USTracks, let's take a look at just what a difference they'll make in your route. The pictures below were all taken on a copy of BNSF_Scenic purchased from trainsimulations.net. The first three images were taken in Everett Yard:

Hyy8yHE.jpg HyyaM6e.jpg Hyyb1an.jpg

I think you can see just how much this track - IMHO better track than what TS2018 serves up! - improves a route's appearance. The next shot was taken in Skykomish.

HyybeQl.jpg

In no small measure this is because not only does the rail look real, but the ballast actually has a 3D berm the way real track does. But it also improves things in more subtle ways that aren't immediately evident without further comparison.

We'll go into that in the next post.

Regards,

David

[Shawmut]

I just ran into an image file size limitation that this board has, so I think that from now on I'll simply post the links to online images rather than uploading the images to trainsim.com. This will mean the images will take up the full frame; I hope that this does not make reading the text, where the meat of this thread lies, too difficult. Okay, now back to our regularly scheduled broadcast ...

As you can see in the next few screenshots, the default Kuju track not only does not have the look of T-section rail (or bullhead rail, for that matter), but it actually gives the illusion of being of a wider gauge than 4' 8 and 1/2":





Because the fat Kuju rails spread out the distance the top of the rail covers over the ties, the tie plates have to be stretched further on the tie as well.



Finally, the flat nature of the ACleanTrack1.ace files means that, as is illustrated in the next shot, the ballast is sometimes floating higher than it should, and in all cases does not have the 3D effect that the USTrack system does:



The USTracks system solves these problems and is an easy project that will elevate (pun intended ;-) your route to no end ...

Normally, installing Norbert's track system is a 3 step process:

A. You uncompress the world files and substitute your selected track system's nomenclature.
B. You then use DynaTrax v.0.62 to convert the dynamic track in the route to DynaTrax shapes that will reside in the route's Shapes folder
C. Finally, you raise your now-installed track system by anywhere from .05 to .15 to eliminate terrain spills.

All of these procedures are clearly outlined with excellent images and clear text on Norbert's site, which is still being maintained: http://dbtracks.de/

I don't intend on reiterating what Norbert has so clearly written; simply follow the steps on his site ... the links are at the top right hand side of the page:
* USTracks 1.0 Beta Downloads
* Installation Instructions
* Dynatrax Manual
* Position Adjustment

Note that the link he has for Track Shape Substitution, used when a switch machine fouls another piece of track is not used with the USTracks system because these tracks do not have point moving apparatus of any kind.

As I said, normally route conversion takes the above three steps and they go quite quickly; you can do a route in a day and perhaps take a few more days going over it mile-by-mile in TSRE5 to fiddle with localized track height issues as in, for example, yards and docks. But that was not the case with BNSF_Scenic, where I ran into an issue that I had not seen before. What that issue was, and how I resolved it, I'll deal with in the next posting.

Regards,

David

[paulytechnic]

This thread couldn't have better timing, David! I just finished converting Blackfoot v3 and Horseshoe Curve to US3 tracks, and was about to move on to converting Scenic Sub 2.0 within the next few weeks. I'm really looking forward to reading your solution before I start!

[Shawmut]

Before beginning any of the steps below I made backups of my WORLD folder as well as the following route files:
BNSF_Scenic.rdb
BNSF_Scenic.rit
BNSF_Scenic.tdb
BNSF_Scenic.tit
and the local tsection.dat.

Step A of track conversion requires that you de-compress your world files (I use Route_Riter for this) and then use a text editor to replace the nomenclature. I highly recommend that you take Norbert's advice and use Note Tab Light to do this; it has much better memory management than ConText does and will not choke when you ask it to swallow 3-400 uncompressed text files. And it's free, too.

Step B is really easy: Tim Booth's DynaTrax app does all the work for you: it creates the shapes, places them in the correct subfolder of your route, and modifies the world files to boot. Couldn't be easier. Grab it in the file library here or over at uktrainsim.com.

Step C is a little trickier, mostly because there's no real fool-proof number I can give you to have you raise the track elevation by just the right amount for each different route you convert. Norbert recommends you raise the trackbed up by .15 centimeters. You can actually use a smaller number and just keep doing this uppity routine as many times as you want until you get just the right height; what that height is will vary from route-to-route.

To raise the roadbed you have to use a utility included in TSUtils that Mike Simpson has handily added to Route_Riter, or you can download TSUtils separately from the file library. Norbert includes the text of a simple batch file that you can use, or you can use the graphical interface in Route_Riter:



The button you want is the "Raise or Lower Track (mveobj)" button. Normally this routine takes about a half-minute or so to run and then *voila* your track no longer has terrain spills on it.

But not this time .... This is the screen I got when I ran this utility:



What this screen is telling me is that the local (i.e. the tsection.dat file found in BNSF_Scenic) is too small to fit in the global tsection.dat file that came with Xtracks. Build 00038 has a minimum number of 40000, and the 376 number found in the original Kuju file is simply to small to fit in.

Well, no problem, that other button I have circled above, "Modify route for new tsection.dat (cvrt)" will do the trick. By the by, the Horace app found in the TKUtils package (also available in the file library) will do the same procedure. I prefer Carlos' TSUtils: all you have to do is to rename the original global tsection.dat file to tsection_old.dat and then select that file - not your new Xtracks-compatible tsection.dat (current build is 00044) - when the cvrt routine asks for it. Then Route_Riter/TSUtils takes over, adjusting your world files, your local tsection.dat, and your .rdb, .rit, .tdb, and .tit files for you.

Now when you run your little batch file (or use the mveobj button in RR), your local tsection will be in sync with your global tsection and all will be well with the world: the track will elevate by the amount you specified and you can either decide to accept this elevation or perhaps add a bit to it if you are still not quite satisfied.

And it did elevate my track by the amount I had specified and I thought that all was well and good until I headed east out of Skykomish ....

We'll take a look at what I found just past the Foss bridge in the next post.

Regards,

David

[Shawmut]

After checking the yards in Skykomish for terrain spills (they were all gone :-) I jumped in a train and headed east out of Sky up the grade that requires a 20 mph maximum for freight trains. Perfect for looking at every inch of the roadbed to make sure that all terrain spills are gone.

All was good and well as I passed the signal east of Foss Bridge until I came to an area that - suddenly - had no track! Yikes! What happened here?



And here ...



The clue to this problem is actually on those two screens above. Look at the track monitor and what do you see directly in front of my Auto-Signaled train? Yep, it's one of those pesky A1tPnt0dLftMnl.s/A1tPnt0dRgtMnl.s combos that were needed as a kludge to fix an MSTS broken coupler bug when a train had gone over too many (I seem to remember 10 miles, but my memory is hazy here) miles without a track node.

Evidently SLI decided to introduce these into the route to head off the problems that the Rodgers Pass route had. But why were the shapes missing? They are standard Xtracks shapes that are listed for all of God and Man to see in the recent tsection.dat files; they should have therefore been in the route. Hmmm ....

So I went back and re-installed my default files that utilized Kuju and Xtracks, did the tsection.dat conversion again so that old and new, global and local files were in sync, and then elevated my default track with Norbert's uppity.bat file.

I got the same blank spaces. So it wasn't anything to do with USTracks; it was something else.

I fired up Route_Riter and had it spit out all of the track sections that BNSF Scenic v.2 used, and here are the added Xtrack sections that SLI used:

* A1t5_5mStrt.s
* A1tPnt0dLftMnl.s* A1tPnt0dRgtMnl.s
* A1t90mStrt.s

I then fired up Note Tab Light, dumped all my uncompressed world files in same and had it find every instance of those specific shapes. To my surprise, there were only five, count 'em, five world files that had these shapes in them. The culprits were:

* w-012830+014729.w
* w-01830+014731.w
* w-012842+014734.w
* w-012852+014731.w
* w-012854+014730.w

I then had ConText compare a modified by the tsection-normalization routine (cvrt) world file with its unmodified parent .... and then, folks, the light dawned.

Below is what I found. The modified/normalized file is on the left, with the gaping gray hole, and the unmodified file, with the items that CVRT deleted highlighted in yellow, is on the right:



Take a look at the track shapes that are highlighted in yellow: those freakin' A1tPnt0d points!! CVRT apparently didn't like finding a tsection.dat file that, hermaphrodite-like had a combo of 1st gen 2001 Kuju section numbers combined with post-apocalyptic Xtrack numbers, and so it just loped them off!!

And that's why my train found a gaping hole just past the Foss Bridge ... (and a few other locations on the route ;-)

To solve the problem I simply copied and pasted those sections back in their respective normalized files, and all was well again in virtual Oregon:



and



In this last shot you can clearly see, by the difference in the oil stains on the ties, where those 0degree points are located. But at least they are located where they should be and my virtual copies of Warren Buffet's trains wont fall into some twilight zone hole!

This has been a very long-winded thread, and apologize for its lengthy nature. But I saw no way of explicating this without going into excruciating details.

And now, when you run into this sort of problem on whatever route you may be converting, you can proceed with the firm knowledge that the solution is actually fairly easy to find. Happy converting!

Regards,

David

[Shawmut]

This thread couldn't have better timing, David! I just finished converting Blackfoot v3 and Horseshoe Curve to US3 tracks, and was about to move on to converting Scenic Sub 2.0 within the next few weeks. I'm really looking forward to reading your solution before I start!

Glad to be of service, Paul!

Norbert was a friend of mine; his knowledge was vast and his technical skills very impressive. Many folks don't know that he also maintained the Xtracks library as well as his own fine-scale shapes.

At any rate, one time I asked him if he dabbled in other trainsims, specifically a German one called "Zusi" (a contraction of "Zug Simulator," i.e. train simulator in German). I had a copy of Zusi 2 and found that it had the most impressive AI of any train simulator I had ever used. Zusi is based on a concept very similar to "timetable" mode in ORTS.

At any rate, he said that he knew about it but didn't partake of it, nor of TS20XX either. He said that what he loved about MSTS (I don't think that OR was even on the horizon at that point) was that it was fueled by amateur participants who each created and shared with their virtual friends the hobby they loved. He wasn't against payware by any means, and indeed he professionally converted a fair number of payware ProTrain routes with his DBTracks packages. But it was our sharing that most moved him.

Regards,

David

[ragtimer]

For those of us without the skill to do this conversion would you consider uploading the necessary files to the F/L as was done for the Michigan Iron Ore route ?

[Shawmut]

For those of us without the skill to do this conversion would you consider uploading the necessary files to the F/L as was done for the Michigan Iron Ore route ?

Assuming permission can be obtained from the current owners, and pending my finishing of some terrain re-modeling around the grade to the Boeing facility, yes.

Regards,

David

[geepster775]

I wonder if it would be easier, since this kludge is no longer necessary under OR, to undo their hacking and remove their zero degree node bundle and simply replace it with a 100M straight in those locations before doing any US conversions - if you can get the straight story from them as to how they hacked the stuff in to begin with.

[ebnertra000]

I wonder if it would be easier, since this kludge is no longer necessary under OR, to undo their hacking and remove their zero degree node bundle and simply replace it with a 100M straight in those locations before doing any US conversions - if you can get the straight story from them as to how they hacked the stuff in to begin with.

A 0° node can be removed manually easily enough as long as there are no interactives between the 0° node and any switches either side of it.