[engmod]

The G_tsection has a maximum number of 65,535.
The 40,000 was judged at the time to be enough for the future.

The 5 digits allowed for the numbers gives our (decimal) 65535 or (hex) ffff.

To get more in the tsection, we would need to go to 6 digits for the numbers.

Going to 6 numbers takes the hex from 32 bit to 64 bit, which will require programmatic changes.

The local tsection would need to be moved from 40,000 to a higher number or use the same number range as the global.

All programs using G_tsection would need to be rewritten to enable the 6 digit numbers.

At the moment we have control over Open Rails and TSRE.
There are a number of utility programs that will need to be updated as well.

[Genma Saotome]

Any idea what programs read the tsection file?

[Weter]

Track viewer, ORTS, TSRE, Train.exe ...

[Jovet]

engmod, on 10 August 2024 - 01:14 PM, said:

The 5 digits allowed for the numbers gives our (decimal) 65535 or (hex) ffff.
To get more in the tsection, we would need to go to 6 digits for the numbers.
Going to 6 numbers takes the hex from 32 bit to 64 bit, which will require programmatic changes.

65535 is the highest 16-bit integer number.
4294967295 is the highest 32-bit integer number.
18446744073709551615 is the highest 64-bit integer number.


If track indexes are currently limited to 16-bit numbers in OR and TSRE, that's not very forward thinking. It's understandable for MSTS 20 years ago, but....

[Laci1959]

Hello.

What about an alternative TSection.dat file that can be written to the route's Openrails folder?
As a test, I started writing one based on Peter Nevell's guidelines.
I copied 10 notes into the TrackSections block.
30 entries have been added to the TrackShape block so far. So you don't need a TrackSections entry for every TrackShape shape file. Starting from this, copying the current TrackSections to the alternative TSection.dat file should be enough, I think, maybe you need to find a place for two special elements.
Since I will use four types of DB elements, I created a grouping of thousands. Thus, only the shape walls of type DB1 need to be added to the TrackShape block, and then copied to the DB2 and DB 3 blocks. You only need to rewrite the first value of the serial number, and Notepad solves it with two clicks. Although this is also true for the name of the shape file.
That's 4,000 entries, if I buy double it's still only 8,000 thousand. Which is exactly one fifth of 40,000. Someone wrote that 1,600-1,700 entries are enough. This is a realistic number if someone only uses a certain type of shape file.
The DB1 spring clamp is a new track element, the DB2 spring clamp is a used track element, and the DB3 GEO clamp is a wooden cross-bottom track element. The DB4 is like the DB3, only it is a concrete cross-bottom track element.
There is a saying: Sometimes less is more.

https://kephost.net/p/MTMyMDc4NA.png
The TrackSections block of the TSection.dat file. For now, I will not copy the whole thing, rather just select what is needed.

https://kephost.net/p/MTMyMDc4NQ.png
The list of DB2 track elements in the TrackShape block, notice that the numbering starts from absolute zero. The DB2 element runs from 1000 to 1999.


https://kephost.net/p/MTMyMDc4Ng.png
List of DB3 track elements in the TrackShape block. The DB3 element lasts from 2000 to 2999.


The rails of the unique MÁV48.5kg system will go to the next stage, as the switches are very unique. They have a radius of 190 meters but are 6.32 degrees. Here, you have to find a place in the TrackSections block or come up with an alternative solution.
What is not expressly forbidden must be done, but at least it is worth a try.

Sincerely, Laci1959

[Weter]

In my case, it's the problem of route, built of dynamic track sections only (except switches). No fixed shapes for not divergent/crossing track sections. It's also called "procedural track" in ORTS and TSRE documentation. I likely have run out of free "slots" in route's tsection file (lists not shapes, but describes curves radii and lengths for dynamic track sections on the route), so, I can't define any curved dynamic section more. That is what this topic about.

Now, I'm thinking to substitute straight sections by fixed shapes, but I afraid, slots will not be freed then, so maybe I'll have to manually delete unused entries anyway.

[Jovet]

For those not that familiar, I can try to explain the problem simply:

Each track shape requires its own track shape ID. That index number uniquely identifies that track shape, and its track sections define what its track database vector(s) should look like for that shape.
When Kuju made MSTS, they designed a default global tsection.dat which included the track and road shapes that came with the game. That file also declared how many of those defined shapes there are.

When you create dynamic track on a route, it too needs its own index number(s). The MSTS (lazy) approach is to start automatically allocating index numbers at the end of the defined sections in the global tsection.dat. The original global tsection.dat defined 263 track shapes, and so the first dynamic track section used on a route would get ID 264, the next 265, and so on, and these would be stored in the route's tsection.dat file.

This created the problem that adding to the global tsection.dat file would cause index numbers for new entries to collide with in-use dynamic track numbers on various routes. The solution to this was the creation of the "standardized tsection.dat" file. This file defined 40000 track sections to force dynamic track sections in each route to start at ID 40001 and on. This allowed a nice buffer to allow new additions to the global tsection.dat file without colliding with any ID numbers used for dynamic track on any route. Utilities like Horace were devised to take existing routes and refactor the dynamic track on them to the 40001+ standard.

If track shapes IDs are limited to 16-bit numbers, with a max value of 65535, then that means—with the standardized tsection.dat file—that all routes can have no more than 25534 dynamic track shapes. This number can also be lower depending on how complex each dynamic track section is setup. (The line between track sections and shapes seems to be blurred here, since dynamic track can consist of up to 5 unique sections.)

The "obvious" immediate solution to me is to make sure that these numbers are 32-bit numbers. I like the idea of signed 32-bit numbers, with 2147483648 possible standard track sections, and 2147483647 possible dynamic track sections starting at -1 and working their way down. But, as Dave has pointed out numerous times, the whole "tsection.dat" thing could maybe be re-thought-out and done a lot better a different way entirely. And, how pertinent this all is if OR is destined to get procedural track anyways may make all of this moot.

[Weter]

Thanks again.
Okay. I feel, I can understand the basis now.
But I wonder, how have it been handled in process of route development:
We delete, replace or modify dynamic track sections on demand, but, as I have noted, index number is likely being increased only, no deletions/changes among no longer used/modified section's definition, which causes overflow much earlier, than it actually could be.

[Laci1959]

Thanks for the professional explanation, I understand the problem now.
The dynamic track is far from me because the dimensions are very American. I have dimensioned drawings of the bedding and rails used at MÁV, but I cannot convert the profile. So I let it go.
However, this would be the future, because it enables the construction of a more precise route.

[Weter]

Some topic here discusses possibility to change dynamic's track cross-section in future.
https://www.elvastow...-track-profiles
Dynatrax utility allows to substitute visible dynamic sections to desired shapes.