StaticDetailLevel ( 99 )

Mit OpenRails sind bis zu 99 StaticDetailLevel möglich.

MSTS unterstützt nur max. StaticDetailLevel ( 10 ), TSRE5 in der Grundeinstellung auch.

Erst mit der letzten Version von TSRE5 wurde die Anzahl auf die Möglichkeiten von OR erweitert.

Allerdings ist dies nicht gut dokumentiert.

Es bleibt zunächst dabei, dass die Anzahl auf 10 beschränkt bleibt. Im Route-Editor wird unter Detail Level: eine höhere Eingabe unter Custom wieder limitiert auf 10. Höhere händische Editionen von z.B.

Tr_Watermark ( 12 )

in eine World-Datei beim Speichern von TSRE5 wieder gelöscht.

Damit eine Strecke eine höhere Zahl für StaticDetailLevel akzeptiert, wird in der <Route>.trk Datei folgende Zeile verlangt:

TSREMaxStaticDetailLevel ( 12 )

Die Zahl kann nach Belieben hoch gesetzt werden.

Gruß Hehl

Kleiner Nachtrag: Der Eintrag

TSREMaxStaticDetailLevel ( 12 )

gehört in die .trk Datei, die sich im Ordner der Strecke befinden muss.

Mit OpenRails ist auch eine solche Datei im Unterordner OpenRails möglich, um zusätzliche ORTS..Parameter aufzunehmen. TSRE5 liest die Daten aus den OpenRails Unterordnern nicht ein.

Wozu überhaupt soviele StaticDetailLevel?

Die Idee die mir da vorschwebt ist eine Strecke, die in mehreren Epochen spielt.

Dann wären einzelne Objekte durch andere zu ersetzen.

Zum Beispiel ein Bahnhof der zwischenzeitlich abgerissen und durch einen Neubau ersetzt wurde.

Das geht mit einem Trick auch mit OR.

Nach meinen Tests nutzt OR beim Einlesen der Objekte einer World-Datei die Zeilen

StaticDetailLevel ( 0 )

gar nicht, sondern richtet sich ausschließlich nach den Trennmarken

Tr_Watermark ( 12 )

Diese erscheinen gewöhnlich in numerisch aufsteigender Reihenfolge.

Aber auch das ist OR egal. Selbst doppelte Einträge werden richtig gedeutet.

(Beispiel)

    Tr_Watermark ( 11 )
    Static (
        UiD ( 6735 )
        FileName ( Bstg10mA.s )
        Position ( -34.4518 16.0197 -182.024 )
        QDirection ( 0 -0.979902 0 0.199479 )
        VDbId ( 4294967295 )
        StaticDetailLevel ( 11 )
    )
    ...
    Tr_Watermark ( 13 )
    Static (
        UiD ( 6753 )
        FileName ( Bstg10mM.s )
        Position ( -30.8842 16.0197 -190.423 )
        QDirection ( 0 -0.979902 0 0.199479 )
        VDbId ( 4294967295 )
        StaticDetailLevel ( 12 )
    )
    Tr_Watermark ( 11 )
    Static (
        UiD ( 6751 )
        FileName ( Bstg5mE1.s )
        Position ( 108.693 16.0197 -519.041 )
        QDirection ( 0 -0.979902 0 0.199479 )
        VDbId ( 4294967295 )
        StaticDetailLevel ( 11 )
    )
    Static (
        UiD ( 6752 )
        FileName ( Bstg5mE1.s )
        Position ( 117.362 16.0197 -515.777 )
        QDirection ( 0 -0.987233 0 0.159281 )
        VDbId ( 4294967295 )
        StaticDetailLevel ( 11 )
    )

Hat man folgende Abfolge in der World-Datei, und setzt die Weltobjektdichte auf 11,

werden die Objekte 6735, 6751 und 6752 angezeigt, 6753 hingegen nicht.

Damit bietet sich folgende Möglichkeit (wieder als Beispiel):

Alle zu ersetzenden Objekte werden unter Tr_Watermark ( 11 ) gespeichert, wie z.B. ein in späterer Zeit abgerissener Bhf.

Alle Objekte einer neueren Variante unter Tr_Watermark ( 20 ) hinterlegt, wie ein neues Bahnhofsgebäude.

Jetzt brauchen nur zwei Zahlen der Tr_Watermark ( xyz ) Einträge geändert werden, 11 --> 15, 20 --> 11.

Logischerweise per Editor oder besser noch per Script.

Dann zeigt sich die Strecke in einer neueren Verfassung, oder in einer anderen Zeit.

Es brauchen keine Objekte verschoben werden innerhalb der World-Datei, nur wenige Zahlen wären zu ändern.

Dies ist lediglich als Anregung zu verstehen, was möglich ist.

Gruß Hehl