Local tsection.dat entries limitation?
#31
Posted 11 August 2024 - 07:28 AM
TSRE already converted the SectionIdx value to be a 32 bit integer.
#33
Posted 14 August 2024 - 10:05 PM
The track section etcetera ID numbers don't really matter until a track database rebuild needs to be done. That's when those ID number collisions really "hit the fan" so to speak (at least as I recall), as it assumes/expects each ID number to be unique while it figures out the correct vector data for each track/road shape the new database. If there's track section ID 271 in the global tsection.dat and in the route's local tseciton.dat, Murphy's Law states it will use the wrong one every time.
#34
Posted 14 August 2024 - 10:07 PM
Weter, on 11 August 2024 - 12:20 AM, said:
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.
I would bet a considerable sum of money (that I do not have) that those index numbers are lost. That kind of optimization is something I would expect to be implemented in a later version of the game (which never came).
#35
Posted 15 August 2024 - 07:21 PM
Jovet, on 14 August 2024 - 10:07 PM, said:
TSRE already does some node collapsing on edit saves for the TDB to eliminate gaps when nodes are deleted (to avoid the TDB from growing to an unmanageable size), so it's not impossible to do.
I just don't see a lot of value in doing it for the local TSection. Most users will never run out of local TSection index numbers, and the size of the TDB isn't being driven by missing index numbers.
#36
Posted 15 August 2024 - 09:03 PM
Jovet, on 14 August 2024 - 10:05 PM, said:
The track section etcetera ID numbers don't really matter until a track database rebuild needs to be done. That's when those ID number collisions really "hit the fan" so to speak (at least as I recall), as it assumes/expects each ID number to be unique while it figures out the correct vector data for each track/road shape the new database. If there's track section ID 271 in the global tsection.dat and in the route's local tseciton.dat, Murphy's Law states it will use the wrong one every time.
Joe, do you see any problems with this in world files?
Example 1
Quote
UiD ( 423 )
SectionIdx ( 20914 )
Elevation ( 0 )
JNodePosn ( -12997 14202 -990.96 22.6368 -334.16 )
CollideFlags ( 551 )
FileName ( ../../routes/Cal-P/shapes/SLW_1tSwt_c_m03dL_Ext_Y.s )
as compared to
Quote
UiD ( 1894 )
SectionIdx ( 20914 )
Elevation ( 0 )
JNodePosn ( -12997 14202 -581.808 22.6368 33.7518 )
CollideFlags ( 527 )
FileName ( SR_1tSwt_c_m03dL_Ext.s )
The SectionIDX() values are identical, the two shape files are dimensionally identical, but the first one points to a replacement texture file.
#37
Posted 15 August 2024 - 09:58 PM
Genma Saotome, on 15 August 2024 - 09:03 PM, said:
Nope. The game doesn't actually care what shape file is used when rendering in the world. You could replace it with a single-family house and it wouldn't cause any train-driving problems. Trying to edit the track after that in an editor could cause issues, but I don't believe that's what you're asking about.
#38
Posted 16 August 2024 - 11:16 AM
If you do opt to edit a piece of track and have tsre simultaneously updating the database, it works fine. You can replace a straight piece with a turnout, or a straight piece with a curve, and the tdb will be updated, both updating the section index as well as any changes to coordinates, and breaking into two nodes if necessary.
In the context of dynamic track, it is true that you can edit the parameters for the shape in how it's rendered, but for whatever reason tsre doesn't automatically update it's definition in the local t-section. That only seems to happen upon create.
#39
Posted 16 August 2024 - 02:00 PM
Jovet, on 15 August 2024 - 09:58 PM, said:
I've known that about the game for along time; what I was ignorant about was whether it would cause any issues in the .tdb and/or software that uses the tdb, such as when it is rebuilt.
I've done this trick for a long time and it convinced me there is no particular reason the file name is required in the tSection file (limited by what I knew of various software utilities) and that in turn helped me realize the TSection file is not about road and tracks, it is only about the dimensions used to construct a path, which, if true, means many different track or road shapes should be able to use the same SectionIDX() number so long as they conform identically to the the path the Tsection data will produce. Want a brand new a1t_w_100m.s? Go find the SectionIDX() for the original Kuju track and use that.
So why is the shapefile name in the Tsection file? My guess is to help people find specific entries. With the understanding I've outlined below we could be doing this:
TrackShape ( 2 Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 )
Instead, what we have been doing is this:
TrackShape ( 2 FileName ( A1t100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 116 FileName ( A1t100mStrtTun.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 14051 Filename ( RR_Rur_a_1LStr_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) RoadShape ( ) )
TrackShape ( 14986 FileName ( A1t100mStrtConcrete.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
Trackshape ( 19190 FileName ( tunnel01-100-3d.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 19414 FileName ( tunnel01-100.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 20019 FileName ( VT1t100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 21559 FileName ( A1t100mStrtRndTun6m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 23519 FileName ( SR_1tTun_c_Str_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 23752 FileName ( NRa1t100mstrtRndTun.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
Trackshape ( 23860 FileName ( NRa1t100mstrtTunBase.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 24255 FileName ( LM1t100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 24761 FileName ( SR_1tEng_w_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 26807 FileName ( SRn30_1tStr_p_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 26877 FileName ( SRn30_1tStr_w_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 26947 FileName ( SRn36_1tStr_p_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27017 FileName ( SRn36_1tStr_w_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27083 FileName ( SRn30_1tTun_p_Str_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 27111 FileName ( SRn30_1tTun_w_Str_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 27139 FileName ( SRn36_1tTun_p_Str_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 27167 FileName ( SRn36_1tTun_w_Str_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 27421 FileName ( DR_rA1s_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27532 FileName ( DR_yA1s_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27642 FileName ( DR_sA1s_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27752 FileName ( DR_hA1s_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27868 FileName ( DR_nA1s_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 27990 FileName ( DR_tA1s_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 28397 FileName ( M_Tun_1t100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 30474 FileName ( SR_1tBrg_n_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 32014 FileName ( SR_1tStr_w_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 32103 FileName ( SR_1tStr_c_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 32367 FileName ( SR_1tTun_w_Str_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 32400 FileName ( SR_InvisiTrack_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 32422 FileName ( SR_1tBrg_w_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 32606 FileName ( SR_1tBrg_c_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 32788 FileName ( SR_Dirt_1LStr_100m.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) RoadShape ( ) )
TrackShape ( 34002 FileName ( eb_1t100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 34116 FileName ( eb_1t100mStrtTun.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 34234 FileName ( eb_1t100mStrtRndTun.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 34512 FileName ( eb_1t100mStrtTunFW65.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 34546 FileName ( eb_1t100mStrtTunF65.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 34592 FileName ( eb_1t4r_100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 34653 FileName ( eb_1t100mStrt_vtun.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 36707 FileName ( Tram_A1t100mstrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 36776 FileName ( TramBB_A1t100mstrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 38005 FileName ( S1t100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 38073 FileName ( gr1l100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) RoadShape ( ) )
TrackShape ( 38115 FileName ( A1t100mtrConcrete.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 39102 FileName ( C1t100mstrtsub.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 39127 FileName ( C1t100mel.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 39142 FileName ( L1t100mstrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 39178 FileName ( C1t100mstrtsubdm.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 39184 FileName ( C1t100mstrtcub.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) TunnelShape ( ) )
TrackShape ( 39750 FileName ( A1t100m7Bridge1.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 39755 FileName ( A1t100m7Bridge2.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
TrackShape ( 39845 FileName ( A1tBrdg100mStrt.s ) Numpaths ( 1 ) SectionIdx ( 1 0 0 0 0 2 ) )
There are 56 TrackShape() there, all of them are for a single track of 100m that is a tangent. What makes them redundant is the last bit of data, specifically SectionIdx ( 1 0 0 0 0 2 ). That is what points to the specifications for length. ALL 56 would be correct had they pointed tot he original KUJU entry in TrackShape( 2 ) -- the very first line. I will guess a roughly equal number entries for each of these specs: 5m, 10m, 50, 250, and 500m... somewhere north of 300 different TrackShape() entries. All completely redundant. Perhaps double that to account for wood vs concrete ties... I guess the total will come close to 700 redundant entries. And that's not considering curved tracks but I'll guess at least 400 redundancies.
In short, the tsection looks bloated because we have filled it with identical path specifications.
The game might need to know which shapes are roads vs. tracks, and maybe which are TunnelShapes, but those could be found in the world file if we would put them there via the .sd file. Add a ShapeAlias parameter for holding n number .s file names and all of the information that anyone uses today would still be present but there would be, at least, more than 1000 numbers that would be newly available AND it would be vastly easier to deal with alternative ballasts, alternative shaped concrete ties, alternative rail colors and for my own needs, alternative berms attached to shapefiles, none of which would require consuming a ShapeFile() number if the definition of their path had already been set up.
#40
Posted 17 August 2024 - 02:23 PM
Quote
Thanks for hint, Eric: I think, that's the thing there.