[dforrest]

Some MSTS users have created specific tsection.dat files which only include reference to track section used in the particular route. Would there be any performance advantage in using these tsection.dat files when running a route in Open Rails?

[vince]

dforrest, on 03 February 2018 - 08:04 AM, said:

Some MSTS users have created specific tsection.dat files which only include reference to track section used in the particular route. Would there be any performance advantage in using these tsection.dat files when running a route in Open Rails?

I think the TSection.dat that you refer to is a route specific \Global\TSection.dat used in a MiniRoute installation.

This has nothing to do with a routes TSection.dat file. They are two completely different files!
Unfortunately, both have the same filenename.
One is the Global TSection.dat and the other is the routes TSection.dat (index of DT).

And I question why would a MiniRoute install be needed with open Rails at all? Mini's were created for MSTS users so each route could have it's own separate Global and Trainset & Consist folders because MSTS loads all sounds from ALL trainsets in an installation! Something that thankfully Open Rails does not do.

The routes TSection.dat file are an index of Dynamic Track used in a route. Any route that has Dynamic Track has a TSection.dat file.
This, what we call a 'Local' TSection.dat is used ONLY for indexing Dynamic Track in a route.

It has nothing to do with the Train Simulator\. . . .\GLOBAL\TSection.dat file which contains the index for ALL track in an MSTS installation and is used by all routes within that installation.

If your curious you can open either file with NotePad, WordPad, Context or other text program and see the differences for yourself.
While your at it, Go here for a complete explanation of what MSTS file do.

More information here: http://msts.steam4me...lders_work.html
Enjoy!

Regards,
vince

edit:spelling/typos/links

[dforrest]

I obviously wasn't clear!

I am referring only to the tsection.dat file read by MSTS from the installation's Global folder, not the one in the route folder.

What has been done in MSTS (using Route Riter and Train Store) is to create a tsection.dat file specific to the route which only includes reference to the track sections used in the particular route and to swap this as necessary to be the tsection.dat file read and used by MSTS to run the particular route. This has a beneficial effect on MSTS's performance. I am not referring to mini-routes.

My question is, would there be any performance advantage in using these tsection.dat files when running a route in Open Rails?

[ckawahara]

Only gains I see is that the smaller file size means less read activity on the part of the storage drive. Guess if the reduced file size results in hundrweds of files found and not used or just not found at all, the savings could be several seconds.

[vince]

dforrest, on 03 February 2018 - 10:06 AM, said:

I obviously wasn't clear!..........................................snip.....................................
My question is, would there be any performance advantage in using these tsection.dat files when running a route in Open Rails?

Performance advantage? No. The Global TSection.dat is loaded up once when you run the Sim.
It takes less than a millisecond (1/1000th of a second) to load a 5MB file. No speed advantage here at all.

It DOES have an advantage in the size of the Global\TSection.dat file as the file, unedited, is around ~5.1MB size.
For example on the LIRR I was able to reduce it's size to 1.5MB using Route_Riter.

There is a size advantage a.) Less space on hard drive . . . not so much needed these days. and b.) a much less cluttered list of track sections in the MSTS Route Editor. . . This is not needed at all with the new TSRE Route Editor.
Goku has a setting to ignore listing trackshapes not used in the route . . .ignoreMissingGlobalShapes = true
Narrow Gauge, Dual Track, ScaleRail ect. so with his editor you have a nice clean list of only the shapes used in your route.

Regards,
vince

[Goku]

dforrest, on 03 February 2018 - 08:04 AM, said:

Some MSTS users have created specific tsection.dat files which only include reference to track section used in the particular route. Would there be any performance advantage in using these tsection.dat files when running a route in Open Rails?

There will be performance difference, but so small that can't be noticed by human eye. Not worth the work.
Maybe in MSTS times when computers have 64 MB of memory it was good solution, because track definition database consumes some megabytes, but today it is so small compared to everything else ..

[espee]

Quote

And I question why would a MiniRoute install be needed with open Rails at all?

Mini Routes are still useful with OR, Inflammable created 1067mm narrow gauge track shapes of default track shapes. Dropping these shapes in a route in a mini route means you don't have to futz with the tsection.dat file etc...

[Genma Saotome]

I often mess around with the contents of the \global\tsection file.

Sometimes I want to try out new road and/or track shapes and I know they're going to sit there for a while. I don't want something goofed to be present in the tsection file of routes I run so I reserve one mini route directory for this sort of activity. And indeed I have occasionally goofed something and the software stops reading the tsection file at that point... but doesn't stop OR from running.

On occasion I have stripped out thousands of entries in the tsection file because they were always in the way when selecting shapes from a list.

For a long time I have had shapes in the tsection file that will, eventually get submitted for inclusion in the official file... but not yet. Best to keep an eye on that file so it doesn't get lost!

Editorial opinion: Had KUJU done their work correctly the tsection file would never have contained the shape file name. The data would have been entirely about segment length and sets of segments in sequential order (both with a unique identifier for programatic lookups, plus whatever was necessary for multiple paths, etc.) -- AND NOTHING ELSE. The model maker would craft his 100m whazzit, go over to the tsection file and lookup the spec for 100m,look where that was used for track, and bingo, he'd has the correct numbers. The file name would be put into the world file, where it belo0ngs. Instead we have a bloated file containing gobs of identical specifications -- how many entries are for 1t100m? 10m? Ad nauseum. It's a complete foobie.

[Goku]

The shape names in global tsection.dat are only for Route Editor purposes. They must be there.
With TSRE procedural tracks and selectable templates, they will be not that important, but sometimes still usefull to bind a custom template to specific shape name.

[Genma Saotome]

Goku, on 04 February 2018 - 06:42 AM, said:

The shape names in global tsection.dat are only for Route Editor purposes. They must be there.

The shape names in the tsection file are meaningless... you can edit the name in a world file so it no longer matches the name in the tsection file and so long as your new shape conforms to the specification of the ShapeIdx() it uses everything will be fine, no matter what name is over in the tsection file. Conversely you can change the shapeinx() value in the world file and again so long as the new value provides size specifications that conform to the shape used, everything works.

IOW you can build a complete "track" library of shapes made from alligators and snakes, go into any world file and methodically replace track shape NAMES with your swamp critter shape names, no other changes, and EVERYTHING will display as defined in the world file and run as defined by the specifications in the tsection file.

If that isn't the way TSRE does things than you are adding an unnecessary constraint.