NEXT - für Trainsimulator Classic (Railworks)

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

    Ich weiß, wie TSC seine Daten verarbeitet, weil ich mich seit Langem praktisch damit beschäftige. Mit meinem TSC Visual Framework habe ich mich zunächst in die laufende 64-Bit-Version eingeklinkt und über einen D3D9-Proxy Shader, Renderzustände und Zeichenaufrufe untersucht. Danach habe ich den RenderCore der GameManagerVC64.dll analysiert. Dabei wurde klar: Ein Grafik-Proxy ersetzt nicht die Engine. Deshalb lese ich für NEXT die vorhandenen Spieldaten selbst und stelle sie mit einem eigenen Renderer dar – ohne Originalshader.


    Die Tracks.bin ist komplex, aber die Beschreibung als Datei, in der wahllos alles steckt, ist falsch. Sie enthält wichtige Netzwerkdaten und Verknüpfungen; die Gleiskurven liegen beispielsweise in den Track Tiles und werden über IDs zugeordnet. Signal- und Fahrzeugskripte sind weitere Bestandteile.


    64 Bit bezeichnet bei TSC die Architektur des Programms und den größeren adressierbaren Speicher. Es macht weder das Streckenformat neu noch sorgt es automatisch für einen neuen Renderer oder Multithreading. Dovetail sagte 2018 selbst, dass die Inhalte unverändert bleiben und die Grafik weiterhin DirectX 9 nutzt. Auch die Behauptung, DTG habe den Core danach nie wieder angefasst, stimmt nicht: 2023 wurde er überarbeitet. 2025 erklärte DTG, vorerst bei dieser Codefassung zu bleiben.


    KI hilft mir bei der Analyse. Ob meine Engine eine Originalstrecke korrekt darstellt, muss ich trotzdem an Geometrie, Signalen, Fahrwegen, Skripten und im laufenden Szenario prüfen.

    Kurz gesagt - ich kenne die gesamte Renderpipeline, ich kenne die Worker die alles verarbeiten und weitergeben. Ich mach das alles nicht ohne know-how.

    Gut, bringen wir es auf die rein technische Ebene. Die detailreiche Ausführung zur Architektur ist korrekt und deckt sich mit den Ergebnissen, die hier im lokalen Reverse-Engineering auflaufen.

    Der Einwand zu den Track Tiles ist absolut berechtigt: In der zentralen Tracks.bin liegen die topologischen Graphen-Netzwerkdaten (Knoten, logische Kanten/Ribbons), die Höhenprofile (cHeight) sowie die via 5-Byte-Referenz (0xE7) eingewobenen Instanzdaten der Signale und PZB-Magnete. Die tatsächliche zweidimensionale, hochauflösende Kurvengeometrie und die physikalischen Splines streamt die Kuju-Engine separat aus den binären Kacheln des Track Tiles-Ordners über GUID-Referenzen.

    Dass ein einfacher D3D9-Proxy den Single-Core-Flaschenhals der GameManagerVC64.dll nicht behebt, ist logisch. Genau deshalb ist das radikale Parsen der unverschlüsselten Assets und der Neuaufbau in einer modernen Umgebung der einzig valide Ansatz, um das System vom alten Core-Unterbau zu befreien.

    Die Diskrepanzen bei der 64-Bit-Einführung 2018 und den nachfolgenden Core-Anpassungen (2023/2025) sind bekannt: Mehr adressierbarer RAM ändert aber im grunde nichts an der fehlenden parallelen Thread-Nutzung und dem starren DirectX-9-Renderpfad.

    Was den Einsatz von KI betrifft: Sie ist ein hocheffizienter Werkzeugkasten für die binäre Mustererkennung und beschleunigt das Schreiben nativer Parser massiv. Die mathematische Validierung der Geometrie (Ecken-Snap-Klemmen, Bounding-Boxen-Abgleich) und die logische Fahrstraßen-Prüfung im Szenario bleiben natürlich die harte Kontrollinstanz des Entwicklers.

    Das Know-how ist also auf beiden Seiten vorhanden. Spätestens wenn die ersten automatisierten Generatoren die Datenstrukturen fehlerfrei beschreiben, erübrigt sich jede theoretische Debatte.

    Im Kern sind wir uns einig. Ich würde zwei Details präzisieren: Tracks.bin liefert bei den Gleisen unter anderem Topologie, Eigenschaften und Höhenprofile; die X/Z-Kurven lese ich aus den Track Tiles und ordne sie über die RibbonID zu. Erst zusammen ergibt das die räumliche Gleistrasse. Auch 0xE7 würde ich nicht als allgemeines Referenz-Opcode bezeichnen: In SERZ kann ein solches Byte ein dateispezifischer Eintrag im Zeilen-Cache sein; die referenzierte Element-ID folgt dann als 32-Bit-Wert.

    Bei der Engine-Geschichte sollten wir ebenfalls präzise bleiben. Die 64-Bit-Version von 2018 brachte vor allem mehr adressierbaren Speicher, keine neue Grafikarchitektur. Dovetail hat aber 2023 ausdrücklich Core-Code überarbeitet und einen experimentellen DX12-Build angeboten. „Seit 2009 unangetastet“ oder „ausschließlich DirectX 9“ wäre deshalb zu absolut. Dovetails Erklärung zur 64-Bit-Einführung bestätigt zugleich, dass 64 Bit allein keine sichtbare Grafik- oder FPS-Verbesserung versprach.

    Mein Ansatz ist weiterhin, die Originaldaten unabhängig vom alten Runtime-Core zu lesen und in meiner eigenen Engine zu verarbeiten. Vom Visual Framework über RenderCore bis zum jetzigen Rust-System war der Parser nur der erste Schritt. Entscheidend ist die Übereinstimmung im laufenden Szenario: Gleisgeometrie, Weichen, Fahrstraßen, Signalzustände, Fahrzeuge und Anzeigen müssen sich wie im Original verhalten. Genau daran messe ich die Implementierung – und genau dort werden die verbleibenden Fehler sichtbar.

    Mich würde interessieren, wie weit die Entwicklung von NEXT bei der tatsächlichen Nachbildung des Train Simulator Classic inzwischen fortgeschritten ist. Die Idee, eine vollständig eigenständige Engine in Rust zu entwickeln, die vorhandene Strecken, Fahrzeuge, Szenarien und Lua-Skripte direkt aus der bestehenden TSC-Installation lädt und mit einer modernen Grafikengine darstellt, ist zweifellos ein sehr ambitioniertes Projekt.


    Besonders interessant finde ich dabei die Frage, wie die Kompatibilität mit den zahlreichen unterschiedlichen Inhalten von Dovetail Games, Drittanbietern und der Freeware-Community gewährleistet werden soll. Die Originaldateien einzulesen und ihre Strukturen zu interpretieren, ist schließlich nur ein Teil der Aufgabe. Entscheidend ist aus meiner Sicht, dass die darin enthaltenen Informationen auch korrekt verarbeitet werden und sich die Inhalte anschließend im laufenden Betrieb so verhalten wie im ursprünglichen Simulator.


    Gerade bei komplexen Strecken dürfte das eine erhebliche Herausforderung darstellen. Die Gleisgeometrie muss beispielsweise nicht nur aus den vorhandenen Daten rekonstruiert werden, sondern auch hinsichtlich Höhenprofilen, Kurven, Weichen und Gleisverbindungen korrekt sein. Hinzu kommen die Signaltechnik, Fahrstraßen, die Fahrdienstleitung und die Interaktion zwischen KI-Zügen und Spielerzug. Es reicht nicht aus, dass ein Signalmodell korrekt dargestellt wird oder sein Lua-Skript ohne Fehlermeldung startet. Das Signal muss auch abhängig von der tatsächlichen Betriebssituation den richtigen Zustand anzeigen, und die zugehörigen Fahrstraßen sowie die Zugbeeinflussung müssen entsprechend funktionieren.


    Ähnliche Fragen stellen sich bei den Fahrzeugen. Viele Lokomotiven und Triebzüge besitzen individuelle Skripte, eigene Bedienlogiken und teilweise sehr komplexe Systeme wie PZB, LZB, AFB, Sifa oder herstellerspezifische Funktionen. Dazu kommen die Fahrphysik, Bremsmodelle, Zugkraftkennlinien, die Steuerung der Stromabnehmer sowie die Kommunikation zwischen Fahrzeug und Strecke. Wie wird sichergestellt, dass solche Funktionen nicht lediglich grundsätzlich ausgeführt werden können, sondern sich auch im Zusammenspiel mit anderen Fahrzeugen, Signalen und Szenarien genauso verhalten wie im Original?


    Du hast in deiner Vorstellung bereits Zahlen zur Überprüfung von Fahrzeugen und Lua-Skripten genannt. Mich würde interessieren, wie diese Tests konkret durchgeführt werden. Bedeutet ein fehlerfrei gestartetes Skript zunächst nur, dass es syntaktisch beziehungsweise technisch ausgeführt werden kann, oder wird auch überprüft, ob seine Funktionen im Simulator tatsächlich korrekt arbeiten? Gibt es hierfür automatisierte Vergleichstests mit dem TSC oder werden die Ergebnisse überwiegend durch praktische Testfahrten überprüft?


    Ein weiterer Punkt ist die ursprüngliche Engine selbst. Der Train Simulator Classic hat über viele Jahre zahlreiche Funktionen, Schnittstellen und Besonderheiten angesammelt, auf die Entwickler von Strecken und Fahrzeugen zurückgreifen. Manche Inhalte funktionieren möglicherweise nur deshalb, weil die ursprüngliche Engine bestimmte Abläufe, Daten oder Fehler auf eine ganz bestimmte Weise behandelt. Wie gehst du mit solchen Abhängigkeiten um, insbesondere wenn eine Funktion nicht vollständig dokumentiert ist oder sich das Verhalten nur durch Tests mit dem Original nachvollziehen lässt?


    Mich würde deshalb interessieren, nach welchen Kriterien du den Entwicklungsstand von NEXT bewertest. Gibt es bereits ausgewählte Strecken und Szenarien, die vom Laden der Welt über die Fahrstraßensteuerung bis hin zum Abschluss einer Fahrt vollständig und reproduzierbar funktionieren? Und welche Bereiche bereiten derzeit die größten Schwierigkeiten: die Interpretation der Originaldaten, die Nachbildung der Engine-Funktionen, die Signaltechnik, die Fahrphysik oder die Kompatibilität mit individuellen Lua-Skripten?


    Ich finde den Ansatz interessant, die vorhandene TSC-Sammlung nicht durch einen völlig neuen Simulator mit eigenen Inhalten zu ersetzen, sondern sie mit einer modernen Engine weiter nutzbar zu machen. Gerade deshalb wäre es spannend zu erfahren, wie du den Übergang von einer grundsätzlich funktionierenden Darstellung der Originalinhalte zu einer möglichst vollständigen und zuverlässigen Simulation des ursprünglichen Betriebsverhaltens angehst.


    Mit besten Grüßen

    Peter

    Deine Unterscheidung zwischen „Datei geladen“ und „im Betrieb korrekt“ trifft den Kern des Projekts. NEXT ist inzwischen ein funktionierender technischer Prototyp, aber noch kein vollständig kompatibler Ersatz für den Train Simulator Classic.


    Die Engine liest Inhalte direkt aus einer vorhandenen TSC-Installation, darunter Archive, Blueprints, Streckenkacheln, Geometrie, Texturen und Szenarien. Sie stellt die Welt mit einem eigenen Renderer dar und führt originale Lua-Skripte in einer eigenen Laufzeitumgebung aus. Die Originalshader werden dabei nicht verwendet; ihre Materialinformationen werden für den neuen Renderer interpretiert. Dass eine Strecke sichtbar ist und ein Zug geladen wird, sagt allerdings noch wenig darüber aus, ob eine komplette Fahrt wie im TSC abläuft.


    Die genannten Prüfzahlen beziehen sich vor allem auf technische Abdeckung. In einer Bestandsaufnahme wurden 901 Fahrzeug-Blueprints und 887 davon mit Skripten erfasst. 2.661 Testprofile prüfen unter anderem Initialisierung und Bedienreaktionen. Dabei traten bei 56 Fahrzeug-Blueprints Laufzeitfehler auf. Ein fehlerfrei gestartetes Skript gilt für mich deshalb ausdrücklich nicht als Nachweis, dass PZB, Bremsen oder Fahrzeugfunktionen korrekt arbeiten.


    Für das Betriebsverhalten nutze ich gezielte Fahrversuche und vergleiche Daten und Abläufe mit dem Original: etwa gespeicherte Fahrwege aus den jeweiligen Saves, Signalstellungen, Skriptzustände und Bremsdrücke. Einen durchgehend automatisierten Live-Vergleich, der dieselbe Fahrt parallel in TSC und NEXT ausführt, gibt es derzeit nicht. Auch ein erreichbares Ziel im Gleisgraphen beweist noch nicht, dass der Zug denselben Fahrweg nimmt: Bei einer Prüfung von 475 gespeicherten Originalwegen waren 471 Ziele erreichbar, doch die Prüfung zeigte auch konkrete Abweichungen im Verlauf.


    Undokumentierte Besonderheiten der alten Engine gehe ich daher fallweise an: Ich lese die Originaldaten und Skripte, beobachte nach Möglichkeit das Verhalten im TSC und baue für eine bestätigte Abweichung einen reproduzierbaren Test. Wo das Originalverhalten noch nicht belegt ist, kennzeichne ich die Umsetzung als Annahme.


    Mein Maßstab für eine belastbare Kompatibilitätsaussage wäre eine benannte Strecke mit benanntem Szenario und Fahrzeug, die vom Start über KI-Verkehr, Fahrstraßen, Signale und Fahrzeugbedienung bis zum Szenarioabschluss wiederholt korrekt funktioniert – mit dokumentiertem Vergleich zum TSC. Eine solche allgemeine Freigabe kann ich heute noch nicht geben.


    Die größten Schwierigkeiten liegen inzwischen weniger beim bloßen Lesen der Dateien als beim Zusammenspiel von Gleisgraph, Dispatcher, Signalen und den sehr individuellen Fahrzeugskripten und Bremsmodellen.