[Weter]

I have been performing an experiment:
Building a route with dynamic track sections only (plus switches, of course).
Since some moment, new dynamic sections are looking right, during placement&extrusion, but yellow lines of TSRE look random, incorrect and odd.
Investigation of local tsection.dat file shows: entrie's number have exceeded 2x32768 (65536) and each further section takes small-numbered entries from nowhere*, as a reference, instead of real 5-sign entries.
Second observation is, the order of items jumps over 1-3 numbers (so there are free, unused numbers, plus some entries are not referenced by any real sections, being just mirrored instances of some referenced ones.
*Count starts from 40000, and I have doubts, any entry is being deleted, after deletion of sections, but instead, likely new one have being added, after modification of the same section... Overflow takes place.

So, I feel disappointed, as I can't finish the route, hitting limit, but still, I can renumber entries and delete unused ones to free some numbers for more sections.

I'd like to hear other's opinions about the question.

[eric from trainsim]

It's a constraint I'd really like to see revisited.

Currently, sections 00001 thru 39999 are in the global TSection.

Sections 40000-65536 are in the local.

How hard would it be to break the limit entirely, and replace with logic that looks in the applicable TSection first, and the alternate TSection second if the lookup fails?

For example.... if section 65537 is encountered, look in Global, attempt Local if not found in Global, and fail entirely if not found in both?

[dajones]

A year or so ago, I took a small dynamic track only route and renumbered the dynamic track so that all section numbers started with 70000. I tried it in both OR and TSRE. Both displayed the route properly. But TSRE crashed when I tried adding more dynamic track. For the most part TSRE uses 4 bytes to store section numbers, but there is one place in the TrackShape class SectionIdx structure where an unsigned short is used. Changing that from a short to an int might remove the current limit on dynamic track sections.

Doug

[eric from trainsim]

Doug, that limit was fixed in v8.002 forward (available at Trainsim.com)

[Weter]

Thank you both, Doug and Eric for your answers.

[Weter]

Please, let me ask some more questions about local tsection syntax and its handling by TSRE:
The second part of the file have consequent entries numbering.
The first one has gaps in numbering, and large gaps (about ten, or just a little less) is likely to be filled during further route editing.
However gaps as 2-3 numbers are being kept.
So, my first question is: does TSRE look for free/unused numbers to re-use them?
Second will be: why gaps are being left anyway, and why to write "mirrored" entries (containing the same values, but negative-signed)?
Third: am I right, thinking, that deletion of no longer used dynamic track sections doesn't free any entries (at least, in first file's part)?
Fourth: can file be re-built by some mean, to cull unused entries, what would free-up numbers for useful usage?

[eric from trainsim]

There is no optimization for gaps, which only occur if pieces were deleted. There might be one number gaps for opposing curve geometry.

[engmod]

>The first one has gaps in numbering, and large gaps (about ten, or just a little less) is likely to be filled during further route editing.
However gaps as 2-3 numbers are being kept.

Let me first say that this is a general comment about dynamic numbering and disk writing algorithms, they are very similar.

To write memory code to compact as you go is VERY time intensive.
To write to the next available slot is the shortest time and lets say it takes a time unit of one,
To go searching for a slot in all the available space, would take about 100 time slots,

On a disk drive ( mechanical disk ) it is about 5000 time slots.
The disk driver will only write forward of the current head position, and it will find the nearest slot that is large enough to write the current buffer.

[Genma Saotome]

Odd that I asked Derek about this just 2 days ago. The important fact is the number 40,000 is not a decimal number, it it hex. Converting it over to a decimal number, Derek said there are about 120,000 open numbers left. I suspect that will be more than enough.

[Genma Saotome]

I do have a question about how OR makes use of the tsection file. If the software needs information about SectionIDX(38037) how does it get to that data in the tsection file? Binary search or (god forbid) serially?

FWIW, there are around 32,000 individual records (measured 1 record per id number). I use an edited version whose records look like this

_INFO( XTracks narrow gauge curves)
TrackShape ( 39991 FileName ( N1t54r1d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36206 ) )
TrackShape ( 39992 FileName ( N1t54r5d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36208 ) )
TrackShape ( 39993 FileName ( N1t54r10d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36210 ) )
TrackShape ( 39994 FileName ( N1t54r20d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36212 ) )
TrackShape ( 39995 FileName ( N1t72r1d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36214 ) )
TrackShape ( 39996 FileName ( N1t72r5d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36216 ) )
TrackShape ( 39997 FileName ( N1t72r10d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36218 ) )
TrackShape ( 39998 FileName ( N1t72r20d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 36220 ) ) )

For me, that's much easier to read.