Missing Track Sections

[MackDaddy]

Hello All,

After some time away from route modification work, I have re-entered the arena and am in the process of learning TSRE.

I recently converted MLT's Kicking Horse Pass to US3 tracks...so dynamic track is involved.
Using "Horace", had to "pair" the older tsection.dat file that came with the route with the more modern tsection.dat file housed within the GLOBAL/SHAPES folder in order for Route Riter/TSUtils to increase the height of the track 15 cm.

The signaling of the entire route was upgraded immediately after it was converted to US3 tracks by a fellow hobbyist using Route Editor.

I am NOT adding and/or deleting sections of track during this modification work...just making scenery enhancements.

Throughout the modification work thus far on KHP using TSRE...minimal issues for me adding objects, deleting objects, etc...and saving. Appears to be a fantastic program, and I am still just getting my teeth cut on it...thanks GoKu!

In this (1) particular section of the route however...even if I add (1) mere shape/object to it and save...when I open the route in ORTS Mono, random sections of track (a significant amount but not all) are missing. In TSRE however, these same track sections are still visible.

I do have back-ups of my .w files (the entire route actually) thankfully.
For what it's worth, editing the terrain and saving in this same area...without adding any shapes...does NOT cause the track sections to disappear.

Threads I have read regarding this same/similar topic all seem to gravitate toward the relationship of the route's tsection.dat and tsection.dat within the GLOBAL/SHAPES folder. I believe I had already addressed that particular issue with the aid of Horace following the conversion to US3 tracks...but perhaps I didn't?

Any ideas on how to fix, and/or potential work-around(s)?

Thanks in Advance!

Jeff M.

[geepster775]

It would seem to me that any US3 conversion should be the LAST step done. The state of the route just before you convert to US3 needs to be your ultimate preservation point, as in any reworking of the route after that needs to start with that pre-US3 copy, and then converted to US3 again.


Since the US3 process is conversion after the fact, there is no USx or DBx anything in the Tsection, it all operates off of Xtracks A1t... shapes

[MackDaddy]

Thanks for the reply and advice geepster775.
Converting the track to US3 from the giddy-up is a habit of mine from the MSTS RE days.
1) If the track wouldn't convert to DB3 or US3 perfectly...then I didn't feel I'd be 100% satisfied modifying the route and would move-on to another route that would
2) As you know, raising the US3 or DB3 track 15 or so centimeters more often than not is required...strange "things" can happen to the route following execution of this TSUtils function, such as but not limited to: bridges and crossing gates disappearing. Always good to
get that taken care of first in my opinion before investing too much time adding new shapes/more entailed modification work.

Strange, modified near 1/4 of the KHP route via adding/deleting shapes then saving and having no issue with track sections missing while in ORTS Mono. Then I got to this particular stretch of the route and the hammer comes down.

Seems that I have (2) options at the moment
1) Modify route with X-tracks in place...scenery modification work...convert to US3 tracks last...then run the risk of losing shapes after I use TSUtils to raise the track
2) Continue on my current path and have track sections potentially disappear while newly added shapes remain in place following a save

Work-around for either option would involve making plenty of saves and manually copying/pasting objects/entries that may have have gone missing in the .w file(s) I presume?


Jeff M.

[geepster775]

Plenty of those early DB/US conversions are now 'locked' at their present state and not further modifiable from a TDB standpoint. Add to that so many of them were done prior to a US/DB trackprofile becoming available to properly display dynamic track in US/DB contours and are now locked because of earlier dynatrax conversions to work around dynamic track (a step that is now obsolete, replaced by a better solution)

To support ongoing evolution of any route, your working copy must be kept/preserved in Xtracks fashion and then converted over to US/DB. These conversions need to be considered very disposable. Any TDB/RDB changes needed later on, you dispose of your current US copy and revert back to modifying your Xtracks copy, preserve a new archive copy in Xtracks, and convert it to US again.

In your case, however, is TSRE making inadvertent changes to your TDB that you may not be aware of because of its settings?

[MackDaddy]

That would be wonderful if it was something I could simply change in the TSRE settings...using version .697 by the way.
Here's the settings...

consoleOutput = false

# main directory of your game data
gameRoot = C:/train simulator

# route directory name to load on startup by default
routeName = asdasasdasd1233

# optional start tile
#startTileX = -5306
#startTileY = 14961

# route edit
#createNewIfNotExist = true
writeEnabled = true
writeTDB = false
#deleteTrWatermarks = false
#deleteViewDbSpheres = false

# geo data
geoPath = F:/hgst

# misc
#systemTheme = true
#colorConView = #FF0000
#colorShapeView = #00FF00
#toolsHidden = true
usenNumPad = true
tileLod = 2
objectLod = 4000
maxObjLag = 10
allowObjLag = 1000
#cameraFov = 20.0
leaveTrackShapeAfterDelete = false
#renderTrItems = true
#useImperial = false
#ortsEngEnable = false
#oglDefaultLineWidth = 2
shadowsEnabled = 1
#shadowMapSize = 8192
#textureQuality = 4
ignoreMissingGlobalShapes = true
snapableOnlyRot = false
imageMapsUrl =
#AASamples = 16
#mapImageResolution = 2048
#cameraStickToTerrain = false
#mouseSpeed = 0.1
#mainWindowLayout = W
#ceindowLayout = CU1
#useQuadTree = false
#fogColor = #D0D0FF
#fogDensity = 0.5
#defaultElevationBox = 0
#defaultMoveStep = 0.25

[GokuMK]

Are track sections or track shapes missing? It is huge difference. If you are talking about shapes, check OR log file if they still are in TSRE but not in OR.

[MackDaddy]

Hi GokuMK...thanks very much for the development of and access to TSRE...and for the tip to review the ORTS log!
I'm not sure that I've figured this completely out, or identified what the actual causal agent is...but I have learned a lot this evening.
Perhaps you, geepster775, and/or someone else can shed more light on it.

So...in that particular world file with certain track sections not visible in the simulation...but still visible in TSRE...ORTS log stated (I'm abbreviating here)...particular pieces of DynaTrax do not exist or can't be found in the Global/Shapes folder.
That struck me as odd, cause I remembered DynaTrax .s files residing in the route's respective SHAPES folder, not the GLOBAL/SHAPES folder as do all of the US3 .s and .sd files.

I then went to other parts of the route that I had already modified and saved successfully...no issue with missing track sections when viewing in the simulation. I decompressed their world files to confirm there were sections of DynTrax.s files being called for...and sure enough there were; however, I noticed (1) stark difference within those .w files in comparison to the (1) that is currently giving me fits.

No issues with the way it is listed here:
TrackObj (
UiD ( 4806 )
SectionIdx ( 40210 )
Elevation ( -0.005 )
CollideFlags ( 535 )
FileName ( "..\\..\\routes\\KHPass2\\shapes\\DynaTrax-584.s" )
StaticFlags ( 00200180 )
Position ( 886.36 274.506 770.867 )
QDirection ( -0.002111 -0.591623 0.001549 0.80621 )
VDbId ( 4294967294 )
StaticDetailLevel ( 0 )
)

Compared to the file name of a DynaTrax.s in the .w file that has been misbehaving:
TrackObj (
UiD ( 2 )
SectionIdx ( 40143 )
Elevation ( 0 )
CollideFlags ( 527 )
FileName ( ..\..\routes\KHPass2\shapes\DynaTrax-517.s )
StaticFlags ( 00200180 )
Position ( -460.399 298.958 91.9315 )
QDirection ( 0 0.362032 0 0.932166 )
VDbId ( 4294967294 )
StaticDetailLevel ( 0 )
)

Notice the \\ in the file name of one and the \ in the file name of the other

I manually adjusted the file name of each piece of DynaTrax.s in the .w file to read \\ rather than \...re-compressed...fired-up the simulation in ORTS Monogame...and the missing track sections returned into plain view.
Additionally, the other modifications (additions of random shapes) I had made earlier were still in place.

I then saved this most recent copy of the route...went back into TSRE...added some other random objects/shapes to that particular .w file...saved...fired-up the simulation again...and everything behaved "normally"...that's encouraging and a good thing!

Why would there be \\ in certain . w files but \ in this (1) .w file...all within the same route, same route .w folder?
Error during the DynaTrax conversion process?
But...these track sections were visible in the simulation until I made changes and saved within TSRE.
As previously stated though...now that the \\ adjustment has been made...I seem to be able to make modifications and save with no longer having sections of track disappear while in ORTS.
Can't make heads or tails of it.

Jeff M.

[eolesen]

I've had pieces with filename substitutions in TSRE and not had any issue.

And yes, that double "\" is critical as the single "" is interpreted in most Unicode readers as an escape character and needs the second slash to be interpreted as a true slash. It's a mistake I've seen in some replacement scripts before.

[GokuMK]

But...these track sections were visible in the simulation until I made changes and saved within TSRE.

You did say something about compression. Are your .W files compressed to binary format? TSRE always converts .W files to text uncompressed format when .W file is saved.

[MackDaddy]

Did not know that GokuMK about a .w file being saved in TSRE...but thanks for letting me know.
Out of habit...before diving into the .w files...I uncompressed them all (assuming they were all compressed) using Route Riter.
Not sure if the .w files I had modified were already uncompressed before executing the Route Riter decompression process.
According to your statement...sounds like they probably already were uncompressed.

As far as when they are compressed, is it to binary format? I am fairly certain they are...whichever format Route Riter compresses the .w files into...is the format they are compressed...which I believe is binary?


Jeff M.