[jonas]

Many shapes are no longer displayed in the Trat 321 route. This is probably because the decompression library in the shape parser (SBR.cs) has changed since January 2025, which Carlo was able to point out to me.

This can be easily checked by using for example of the MSTS viaduct shape "LongMeg.s":

The original MSTS shape "LongMeg.s" is compressed by Kuju and is displayed without any problems in OR (U2025.02.01-1701). The shape "LongMeg.s" used in the "Trat 321" route was compressed differently by the "Trat 321" route builder and is no longer displayed.

 LongMeg_compressed_by_Kuju_MSTS.zip (92.09K)
Number of downloads: 60

 LongMeg_compressed_by_Trat321.zip (91.21K)
Number of downloads: 56




EDIT: One can find the original MSTS shape "LongMeg.s" in the "EUROPE1" Route of MSTS

[Kapitaen13]

Yes, the whole thing is confirmed here Probleme mit OR-Monogame-Versionen

and this is what the error message looks like.

Warning: System.IO.FileLoadException: c:\microsoft games\train simulator\global\shapes\a1t50mstrt.s ---> System.NotSupportedException: Dieser Vorgang wird nicht unterstützt.
   bei System.IO.Compression.DeflateStream.get_Position()
   bei Orts.Parsers.Msts.SBRException.TraceWarning(BinaryBlockReader sbr, String message) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Parsers.Msts\SBR.cs:Zeile 527.
   bei Orts.Parsers.Msts.BinaryBlockReader.TraceWarning(String message) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Parsers.Msts\SBR.cs:Zeile 514.
   bei Orts.Parsers.Msts.BinaryBlockReader.VerifyEndOfBlock() in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Parsers.Msts\SBR.cs:Zeile 482.
   bei Orts.Formats.Msts.distance_levels..ctor(SBR block) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Formats.Msts\ShapeFile.cs:Zeile 971.
   bei Orts.Formats.Msts.lod_control..ctor(SBR block) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Formats.Msts\ShapeFile.cs:Zeile 947.
   bei Orts.Formats.Msts.lod_controls..ctor(SBR block) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Formats.Msts\ShapeFile.cs:Zeile 933.
   bei Orts.Formats.Msts.shape..ctor(SBR block) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Formats.Msts\ShapeFile.cs:Zeile 155.
   bei Orts.Formats.Msts.ShapeFile..ctor(String filename, Boolean suppressShapeWarnings) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\Orts.Formats.Msts\ShapeFile.cs:Zeile 100.
   bei Orts.Viewer3D.SharedShape.LoadContent() in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Shapes.cs:Zeile 2041.
   bei Orts.Viewer3D.SharedShape..ctor(Viewer viewer, String filePath) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Shapes.cs:Zeile 2027.
   bei Orts.Viewer3D.SharedShapeManager.Get(String path) in C:\NoSistema\OR_officina\or_WORK\Git_ORTS_source_mio\Source\RunActivity\Viewer3D\Shapes.cs:Zeile 77.

Jan

[jonas]

Yes. But currently it affects not only the ORNYMG version, but also the OR Unstable version. Both have problems loading the "LongMeg.s" from the "Trat 321".

The older ORNYMG version 156.1, for example, still loads all the shapes from the "Trat 321" without any problems. The Unstable version basically cannot load the "Trat 21" because of the watchdog and the loading timeout.

But if I put the "LongMeg.s" from the "Trat 321" in a route that can be loaded with the Unstable version, it is not displayed there either.

[Csantucci]

To complete the above posts, this is an OR-Testing logfile with the non working .s file versions:
 OpenRailsLogSBR.txt (27.28K)
Number of downloads: 47

This is an OR-Testing logfile with the working .s file versions:
 OpenRailsLog.txt (12.89K)
Number of downloads: 48

As you can see, in this second case the SBR parser recognizes that there is an issue in the shapes

Warning: Expected end of block distance_levels; got more data in z:\program files\train simulator\routes\transfertable2\shapes\longmeg.s:byte 24592

but it behaves resiliently and is able to display them.

The uncompressed versions of the shapes are always displayed correctly.

[slipperman]

Hi,
The problem is with the Trat-compressed file, NOT Open Rails! NOT true! see later posts!! Ged

Comparing the uncompressed versions of the default and Trat longMeg.s files, line 1661 is the problem.
The Trat version has distance_levels ( 1 while the default version has distance_levels ( 4 although both are followed by 4 x distance_level entries.

I confirm that when using the original Trat version the bridge is not shown but after the file has been modified, using both the uncompressed and compressed versions, the bridge is shown correctly.

My tests used ORNYMG 161 with Windows 10 and the Europe1 (Settle - Carlisle) route in a default MSTS installation.

Cheers,
Ged

EDIT : I don't know much about LODs but as the Trat compressed file only used the first level, it is, very likely, the furthest distance away from the camera so doesn't show anything!!
I also confirm that when using the unmodified uncompressed Trat file, LongMeg is displayed correctly.

[Csantucci]

Ged,
the fact is that these shapes were shown correctly in older OR versions since creation of the Trat route. So I don't think that we can only say that it is a route's problem. If the route loaded correctly up to a month ago, it should continue to load correctly now.

[jonas]

Yes, thanks for the research, Ged!

In fact, in the "Trat version" of the LongMeg.s shape, an attempt seems to have been made to manually rewrite the first LOD with an original visibility of 300m to 2000m visibility (line "dlevel_selection ( 300 )" -> "dlevel_selection ( 2000 )") and to "hide" the remaining three LODs with 600m, 800m and 2000m. To do this, in line 1659 of the shape, the index 4 for the original 4 LODs was changed to index 1, so only the first LOD, changed to 2000m visibility, is indexed.

So this explains the SBR parser warning, as already mentioned by Carlo:

Warning: Expected end of block distance_levels; got more data in z:\program files\train simulator\routes\transfertable2\shapes\longmeg.s:byte 24592

Whatever the reason why the "Trat 321" route designer carried out this manipulation(s) on the shapes (probably to avoid loading the many LODs of the shapes into memory on the already huge route with the latent threat of memory overload, but to load only one LOD per shape if possible), the fact remains that the "Trat 321" ran in earlier OR versions. As Carlo has already mentioned, the parser was tolerant of such shape manipulations.
...and it remains astonishing that the decompressed shape is always loaded and displayed correctly, regardless of whether it has been manipulated or not.

[slipperman]

Hi,
If it's of any help, using the original 'Trat' compressed shape file, ORNYMG 160.1 and 160.2 display the bridge correctly - but 161 doesn't.
Additionally, version T1.5.1-1435 displays the bridge correctly, but T1.5.1-1511 (the latest) does not.
I don't currently have any testing versions between these two

More info which might be useful!
Looking at the Unstable versions, the last one to display the bridge correctly was U2025.01.03-1838. This appears to have been derived from T1.5.1-1462 which also displays the bridge OK.
U2025.01.03-2137, although derived from T1.5.1-1462, does NOT show the bridge correctly.

Cheers,
Ged

[Csantucci]

Further analysis shows that the problem is that in last OR versions

sbr.InputStream.BaseStream.Position

generates a Not Supported Operation Exception (such versions don't like getting the actual stream Position)

Here is a brutal hack for ORNYMG 161, that overcomes the Trat321 problem
 Orts.MG161fixes.zip (1.4MB)
Number of downloads: 56

[jonas]

Thanks Carlo, the hack works well and it seems to me that all shapes in Trat 321 are displayed again now.

Again specifically about the Trat321 route:
For many (all?) distance_levels-problem-shapes being warned about in the OpenRailsLog.txt, the route builder seems to hide the contained LODs of a shape beyond the first LOD by simply set the index to 1. Unfortunately, this also affects many Tracks and also Grantries in this route. This is why the world in Trat 321 with the newer OR version appeared so "perforated".

Greetings
Jonas