Mtracks Track Database Alignment Error

[Zephyr06]

I recently laid a few Mtracks crossovers and noticed the TDB lines on all the No20 and No24 point sections do not line up with their Frog or Xover counterparts. The main route of the TDB gets connected properly, but the diverging route is offset (the problem does not occur with the No15 switch pieces). The shapes match up correctly, but there are 2 blue TDB poles present where the sections meet:

M1tPntNo20Lft-bug.png (1.6 MiB) Viewed 34228 times

This does not happen when laying the same track sections in the default MSTS editor.

Currently using TSRE5 v0.7.002 with build 0056 of the global tsection.dat.

Has anyone experienced this? Is there something that TSRE5 does differently when placing/writing track items that could cause this error?

All said, I'm having a wonderful time using the new editor to create routes after a long hiatus, thanks Goku!
Matt

[Goku]

Maybe there is a tsection bug in this shape definition, but MSRE has more tolerance for radius when snapping tracks togeher.
TSRE doesn't allow that huge offsets.

[eolesen]

Not sure if this is just a coincidence, Goku, but most of us who are reporting anomalies in the TDB rendering are using either UK Finescale, Scalerail with yard spacing, or MTracks.

All of those are built on ~4m track centers as opposed to the 5m track centers used by Kuju, XTracks, DBTracks, USTracks, etc.

I agree it's possible that the TDB definitions could be different than the actual shapefile for curved sections, but I'm also seeing some discrepancies happening with straight multi-track sections where there's no curvature to account for.

Could something in the math being used to chain TDB vectors together be influenced by track centers being closer together than 5m?...

[Zephyr06]

Following up on this issue, I want to share the root cause and a work around for laying Mtracks points in TSRE:

I noticed TSRE has trouble recognizing "SectionSkew" entries in the global tsection.dat when placing track shapes that reference them. This leads to misaligned TDB vectors even though the track pieces snap together properly in the editor. The point shapes for Mtracks #20 and #24 switches (M1tPntNo2*.s) happen to start with a skew section followed by a curve for the diverging path. When placed in TSRE, the initial ~0.5 degree skew gets skipped causing the TDB vectors to miss the blue pole on the adjacent Mtracks frog or xover shape. I tested this theory by placing the default A1t10mSkew.s in TSRE and found the same result - the TDB vector doesn't align with the following piece.

What I saw in TSRE when placing a #20 Mtracks point, global tsection build 0056:

mtracks-point-issue.jpg (97.98 KiB) Viewed 32496 times

I found a way to patch this issue by using the OpenRails include file feature. I created a file named "tsection.dat" and placed it in a folder named "openrails" within the directory of whichever route I'm editing in TSRE. Then, I wrote modified entries for the Mtracks points' skew sections that will temporarily replace the global tsection.dat entries whenever TSRE or OR loads the route.

Starting from the global tsection.dat, build 0056:

Code: Select all

_INFO( Number 20 Pnt sections)

TrackSection ( 31820
 SectionSize ( 1.5 0 )
 SectionSkew ( -0.5529 )
)
TrackSection ( 31821
 SectionSize ( 1.5 0 )
 SectionSkew ( 0.5529 )
)

_INFO( Number 24 Pnt sections)

TrackSection ( 31842
 SectionSize ( 1.5 0 )
 SectionSkew ( -0.5461 )
)
TrackSection ( 31843
 SectionSize ( 1.5 0 )
 SectionSkew ( 0.5461 )
)

I simply changed the "SectionSkew" lines to read "SectionCurve" and entered a 0.001m radius for each, while copying the degree of curvature over from the original skew entries. By replacing the culprit skew sections with an extremely short curve section, the TDB vectors for the Mtracks points now line up properly with the other shapes in the set.

The tested include file with required header (remember to include an empty first line if copying):

Code: Select all

include ( "../../../Global/tsection.dat" )

TrackSections ( 40000

_INFO(Mtrack No20 point skew)
TrackSection ( 31820
 SectionSize ( 1.5 0 )
 SectionCurve ( 0.001 -0.5529 )
)
TrackSection ( 31821
 SectionSize ( 1.5 0 )
 SectionCurve ( 0.001 0.5529 )
)

_INFO(Mtrack No24 point skew)
TrackSection ( 31842
 SectionSize ( 1.5 0 )
 SectionCurve ( 0.001 -0.5461 )
)
TrackSection ( 31843
 SectionSize ( 1.5 0 )
 SectionCurve ( 0.001 0.5461 )
)
)

Here's the result when I place a #20 Mtracks point in TSRE with the include file in place:

mtracks-point-fixed.jpg (99.48 KiB) Viewed 32496 times

Everything lines up without the unwanted blue poles. Throughout this process, I learned a lot about the structure of the tsection.dat and the usefulness of patching it locally with an include file.

-Matt

[eolesen]

Interesting. Just a guess that skew isn't very common thus not tested much when TSRE was being developed.

[Goku]

Indeed. Sadly, I didn't know that there is something like "SectionSkew". TSRE has no support for it.

[eolesen]

Skew was originally for route builders who couldn't calculate approach angles over short distances and needed to line up pieces before the smaller sections like 0.2m were invented.... It's rare enough that not supporting it shouldn't be a huge loss.