NEXT - für Trainsimulator Classic (Railworks)

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.

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

Zitat von TrainNolden

Wichtig in der Debatte mit KI ist zu verstehen, das der Train Simulator Classic nen absolutes Brett ist.
Dovetail games habt nicht umsonnst Jahrelang daran gesessen und die weiter Entwicklung am ende unter anderem auch deswegen eingestellt, weil absolut niemand mehr bei diesem Code alleine durchblicken würde. Denn wenn ihr wüsstet was alleine in der Tracks.bin drin steht, wie da die verknüpfungen aufgebaut sind und

wie schlampig das damals unter extremem Zeitdruck zusammengeschustert wurde, würde euch schwindelig werden.

Kuju hat diese Datei im Jahr 2007 im Grunde wie eine digitale Mülltonne benutzt. Weil die Festplatten damals so unendlich langsam waren, durfte das Spiel beim Laden einer Strecke nicht hunderte separate Dateien öffnen. Also war die Devise: „Wir klatschen einfach ALLES, was irgendwie mit den Schienen verschweißt ist, in diese eine riesige Binärdatei.“

Und das Ergebnis ist ein absoluter Albtraum für jeden Programmierer. Da liegt die mathematische 3D-Kurve des Gleises direkt neben der LZB/PZB-Zugsicherung, den Geschwindigkeitsbegrenzungen, den unsichtbaren Markern für Bahnsteige und den 3.010 Signalen. Und das Beste: Nichts davon ist logisch nacheinander sortiert! Eine Weiche aus Donauwörth steht im Code direkt neben einem Bahnsteig aus Augsburg, und die Verknüpfungen (die sogenannten Network-cTrackRibbons) springen kreuz und quer wie ein betrunkenes Spinnennetz durch die 50 Megabyte.

Dovetail Games hat dieses Erbe 15 Jahre lang wie ein rohes Ei herumgetragen. Die haben den Core-Code der Engine am Ende gar nicht mehr angefasst, weil das Risiko viel zu groß war, dass das gesamte Kartenhaus in sich zusammenbricht. Die haben dem Spiel 2018 nur ein 64-Bit-Sauerstoffzelt verpasst, damit es nicht mehr wegen zu wenig Arbeitsspeicher abstürzt – aber das Herz der Engine blieb im Jahr 2009 stehen. Ein einziger CPU-Kern muss sich bis heute durch diesen unsortierten Datensumpf quälen, was zu den berüchtigten Nachlade-Rucklern führt, während sich deine restlichen 15 CPU-Kerne zu Tode langweilen.

Und genau hier trennt sich jetzt die Spreu vom Weizen: Wenn eine moderne KI auf diesen Datenberg losgelassen wird, passiert etwas, das die Gaming-Industrie komplett unterschätzt. Die KI schaut sich dieses binäre Chaos an, flucht ein paar Runden über die 1-basierten String-Indizes und die Tatsache, dass die Weichenknoten im Code aus Platzgründen exakt 1,570 Meter quer links neben dem eigentlichen Gleis abgespeichert wurden – und dann knackt sie die Matrix. Sie isoliert alle 3.107 Knotenpunkte fehlerfrei, liest die versteckten 5-Byte-Signalreferenzen aus und baut an einem einzigen Wochenende ein mathematisch perfektes, neues Fundament in modernem Rust-Code auf.

Das ist der Grund, warum Projekte wie NEXT von Fredsmods die absolute Zukunft sind. Sie flicken nicht mehr an Dovetails kaputter EXE herum. Sie werfen den alten Core komplett über den Haufen, nutzen die Originaldaten von der Festplatte als reine Zutaten und bauen das Spiel auf einer modernen Grafik- und Multithreading-Engine von Grund auf neu auf. Die Konzerne dachten jahrelang, an ihren alten Code geht sowieso nie wieder jemand ran – und jetzt zeigt ihnen die Community über ein KI-Harnisch von der Couch aus, wie man eine Spiele-Engine im Jahr 2026 wirklich baut!

Ja FreD ich gebe dir recht, das dass dümmste was du hättest machen können, in dem Sinne Respekt vor deiner Arbeit und viel durchhalte vermögen, den das es auch mit KI kein Spaziergang ist sollte jedem klar sein.

Alles anzeigen

Was mich an diesem KI Kram stört ist diese Überheblichkeit. Du scheinst nicht zu verstehen dass damals unter ganz anderen Bedingungen entwickelt wurde und auch DTG selbst zur Zeit der Core Updates keine superschlauen KI Agenten hatte wie du.

Dass Dinge in der tracks.bin nicht der Reihe nach sortiert werden kann ja auch andere Gründe haben und ist im Spiel eher wurscht weil das Netzwerk im Speicher beim Laden erzeugt wird. Du kannst nicht alles der Reihe speichern weil es nicht unbedingt ein lineares Netzwerk ist. Das ist halt eine Datei weil das Netz als gesamtes geladen wird, vor Szenariostart, anders als Kacheln die nachgeladen werden.

Ich war selbst am Core Update beteiligt und ich kann dir sagen dass das Pflichtenheft für DTG anders aussah als für euch. Nämlich Kompatibiltät. Die ganzen DLC müssen funtionieren, und viele zunächst toll erscheinende Änderungen mussten verworfen werden weil sich in irgendeinem Szenario oder mit einer geskripteten Lok Fehler ergaben. Es wurde massiv getestet und von den ca. 1000 DLC haben wir es geschaftt dass lediglich drei Szenarien bekannt sind die das Update nicht überlebt haben, der Fix (Dispatcher) aber so wichtig war das diese sehr gute Ausfallquote akzeptiert wurde zugunsten der Stabilitätsverbesserung.

Nachladeruckler sind, ganz einfach gesagt, schuld des Streckenbauers. Auch da gibt es Dinge zu beachten und man kann nicht einfach wahllos die Kacheln zumüllen und vor allem 3D Objekte in Assetblöcke (die eigentlich dem komerziellen Entwickler damals Zeitersparnis bringen sollten) packen. Das Wissen haben ich und andere in der Praxis erworben durch viele Tests. Ich selbst habe nie Einblick in den Code gehabt. Man nehme mal beispielhaft die Workshoperweiterung der Hudson Line nach Poughkeepsie. Du fährst von NY nach Croton-Harmon, alles flüssig, butterweich und sobald du den neuen Bereich befährst friert das Spiel regelmässig ein obwohl die Szenerie nicht anders ist, aber halt schlampig gebaut wurde, massenhaft Wälder schnell schnell per AssetBlock gezogen ohne zu wissen das die Assetblocks selbst nur einen Seed, die Objekte und ein paar Parameter enthalten. Da muss der Hauptthread warten bis die Kachel(n) live generiert wird, anders als bei normalen Kacheln wo der Thread weiterläuft und du höchstens den Renderer beobachten kannst wie er die Texturen appliziert auf die auftauchenden Objekte, aber der Spielfluss nicht gestört wird. So funktionier das Ding nun mal und es gibt genug Beispiele wie man eine toll ausgestaltete Strecke auch ruckelfrei bauen kann. Wenn ich das Streckenbauen zum Programmieren gleichsetze, kann ich ein Programm halt schlecht schreiben und unperformant oder gut in dem ich Regeln beachte und sauber programmiere.

Des weiteren kann ich mir auch kaum vorstellen dass DTG den Entschlüsselungscode für die meshes freigeben, ich wäre da sehr vorsichtig, das ist ihr Heiligtum. Ich denke man bewegt sich hier insgesamt sehr gefährlich
an der Illegalität entlang und tut so als ob DTG das Spiel schon als OpenSource deklariert haben.

Und generell sehen alle nur die Vorteile aber dass die KI weit mehr Energie brauch als ein Programmierer (ne Pizza und Cola) und wer das dann bezahlt will keiner wissen. Den nötigen RAM / GPU wird sich kaum noch einer leisten können, das sieht man jetzt schon sehr deutlich und das ist keine kurzfristige Schwankung.

Spikee1975,

ich fürchte, bei allem Respekt, dass Dein Wissen um den Einsatz von AI/KI in der Softwareentwicklung, nicht mit Deinem breiten Wissen um den TSC mithalten kann.

Was für exorbotante Kosten, entstehen denn, Deiner Meinung nach?

Mit einer 16 GB VRAM Grafikkarte von ATI oder Nvidia läuft das LLM lokal, da entstehen nur Stromkosten. Es gibt ein breites Angebot auf Abo-Basis bei der man subventionierte Tokens im Vorraus bezahlt und Du kannst auch über OpenRouter LLM ohne Abo über Per Token Usage bezahlen.

Und um meine Argumentation vom letzten Post aufzugreifen und zu bestätigen, was FreD bereits erläutert hat: Die zielgerichtete Entwicklung läuft über Specs und kleine Slices, nicht über einen Prompt. Auf Deutsch: Du legst wie bei der Entwicklung ohne KI, vorher fest, was Du erreichen möchtest, wie Du es erreichen möchtest und welche Zwischenschritte dafür notwendig sind. Du legst ein Testframework fest und welche Abhängigkeiten eingebunden werden müssen. Es folgen Festlegungen zu Konventionen, Datenmodellen und Design.

Erst wenn Du diese Aufgaben erledigt hast, kann es in die Umsetzung gehen.

Eine einfache Aufgabenstellung wie "bau mir ein GTA7" wird EIN Ergebnis liefern, aber sicher nicht das gewünschte Ergebnis. Da kommt dann eher ein Browsergame für YouTube bei heraus.

Also ist Deine Schlussfolgerung, dass die Kompatibilität bei einem Rewrite in Rust keine Rolle spielt, nicht korrekt. Damit eine vollständige Kompatibilität erreicht werden kann, ist das Gegenteil der Fall.

Genauso wie OMSI2 Addons von OpenOmsi profitieren, könnte der TSC profitieren, wenn es eine moderneres Frontend gibt, dass moderne Hardware besser ausnutzen kann.

In diesem besser liegt auch keine "Überheblichkeit", sondern nur andere Möglichkeiten.

Das mein Wissen was KI betrifft begrenzt ist (nutze sie nicht), da hast du sicher recht.

Ich habe doch nichts von Prompten gesagt (wobei die Entwicklung so schnell geht das das evtl nächstes Jahr schon passieren kann, man muss sich klarmachen dass die Fortschritte hier rasant sind und was man heute als unmöglich hält morgen schon gehen kann und die Entwicklungssprünge in immer kürzeren Abständen erfolgen.)

Mit Überheblichkeit meine ich den Kuju Entwicklern Schlamperei zu unterstellen mit dem Wissen das man sich mal eben per KI beschafft hat. Damals hat man halt denken und selber schreiben müssen und was entwickeln mit dem man seine Familie und Kinder ernähren kann, darum gings. Dass das überhaupt so gross wurde haben die wohl damals nicht gedacht - der Vorgänger MSTS erhielt einen Patch und das wars dann - und was aus der Software rausgeholt wurde ist beindruckend meiner Meinung nach, weil das Grundkonzept gut war und zukunftsoffen. Siehe was AP geleistet haben.

Ich betrachte bei der KI die Gesamtstruktur, also vor allem die Datencenter, die dafür gesorgt haben dass Hardware exorbitant teuer wird weil der Heimkonsumentenmarkt nicht mehr attraktiv ist für die grossen Chiphersteller. Da entsteht das für Intelligenz nötige Netzwerk. Ich finde, dessen sollte man sich bewusst werden, alles hat seinen Preis. Das ist zwar offtopic kann man aber nicht ganz ausklammern finde ich.

Wie gesagt ich stehe dem kritisch gegenüber aus genannten Gründen. Wenn die DTG verschlüsselten Vertexkooridnaten nicht entschlüsselt werden können, dann ist das ganze eher ein Nachfolger und wird nicht tauglich sein den Grossteil des Contents spielbar zu machen. DTG haben angedeutet, das der Code OpenSource und einsehbar sein muss, d.h. wenn ich dort den Entschlüsselungsalgorithmus reinhaue dann kann ihn auch jeder sehen und gangbar machen ohne dass Steam den Besitz überprüft und den Schlüssel gültig macht und sich per Torrent die DLC runterladen.

Ich denke die Diskussion wird einen kritischen Blick vertragen, ich kann mich dem "freue mich schon" noch nicht anschliessen. Mal sehen was die KI so schafft, aufzuhalten ist sie nicht mehr, allein schon weil sie für die zwei Grossmächte, und da geht es ums Erziehen, quasi das moralische Alignment der KI, wichtiger ist als die Bombe.

Zugsimulationen sind ein anderes Biest als OMSI. OpenRails wurde ja komplett reverse engineered (ohne KI) und noch immer nicht ganz kompatibel zu einigen MSTS addons wo man dann in den ENG files nachbessern muss, weil die nicht ganz so strikt waren wie die späteren Blueprints die Kuju definiert haben für RS. Naja mal schauen mit skeptischem Blick. Geht nicht um rechthaben sondern Meinungsaustausch.

Den Renderer abzukoppeln halte ich für eine gute Idee. Wurde auch bei Orbiter gemacht bei dem nur der urprüngliche DX7 Kern dabei ist und man sich seinen Renderer separat installiert zur _NG (nographics).exe

Ich warne halt nur vor Euphorie. Da werden noch Hürden kommen wo man sich im Code auf einen geimsamen Nenner einigen muss um Kompatibiltät zu wahren, und rechtlich ist das auch noch nicht einwandfrei.. Ein zweites Mal wird Maik jedoch nicht sein AFB skript ändern wie damals als die erste Phase des Updates es inkompatibel gemacht hat, das ist klar. Aber - das kann ja dann die KI

Zitat von Spikee1975

massenhaft Wälder schnell schnell per AssetBlock gezogen ohne zu wissen das die Assetblocks selbst nur einen Seed

Die Innerstetalbahn, Brockenbahn und Rübelandbahn widersprechen dieser Aussage. Müssen halt nur 2D Bäume in den Assetblock Wäldern sein. Laufen diese Strecken genau so flüssig wie Oxford - Paddington? Nein... aber das erwartet auch keiner.

Zitat von FreD

Zu Kuju: Wenn das so rübergekommen ist, als würde ich den Entwicklern damals Schlamperei vorwerfen, dann habe ich mich schlecht ausgedrückt.

Ich habe auf TrainNolden geantwortet, bezog sich nicht auf dich.

Zitat von tom87

Die Innerstetalbahn, Brockenbahn und Rübelandbahn widersprechen dieser Aussage. Müssen halt nur 2D Bäume in den Assetblock Wäldern sein. Laufen diese Strecken genau so flüssig wie Oxford - Paddington? Nein... aber das erwartet auch keiner.

Ach guter Tom, das ist schon klar dass 2D egal ist - das spielt wirklich null Rolle heutzutage aber sowas von null, und du kennst mich, habe oft bemängelt dass RSSLO ihre 3D Bäume fast ausschliesslich sogar in kleinen Gärten per Assetblock platziert haben, da findest du lauter Fünfergruppen. Das ist kein Widerspruch du kannst dir genanntes Beispiel mal anschauen und selbst erleben dass ein klarer Bruch zwischen dem DTG Abschnitt und dem Userabschnitt zu merken ist, da steht das Bild 20 Sekunden bevor es weitergeht obwohl die Szenerie selbst genauso aussieht, und das andauernd. Das sind die Assetblöcke die den Thread anhalten bis die Kachel fertig ist, kannst du glauben oder nicht. Das meine ich. Bei mir laufen auch die letzten DTG Strecken flüssig (Huddersfield, Chatham, Pegnitz, Strasbourg), und die sind sehr gut gebaut, die Jungs haben das halt schon ewig beruflich gemacht, das Extrembeispiel lowpoly und wenig assets Oxford-Paddington ranzuziehen macht da wenig Sinn, wenn ich die Framerate bei mir aufmache dann läuft die mit 500 FPS nativ darum gehts nicht. Es geht explizit darum dass beides stimmen muss, Code und Content. Das eine kann das andere nie komplett wettmachen. Und da gibts dann Leute die alles auf die Engine schieben obwohl sie sich vielleicht selbst verbessern könnten bevor anderen die Schuld zu geben. Ich kann jede Engine per schlechtem Mapping in die Knie zwingen, auch die UE.

So und jetzt ein konstruktiver Vorschlag. Beim setzen von Assetblöcken eine Option "Save" hinzufügen die die Objekte permanent auf die Kachel nagelt - dann macht das Ding nämlich erst Sinn. Da kann ich rumbprobieren bis mir das Ergebnis passt und dann "Einloggen". Das heisst ich erzeuge ganz normal die Kachel mit Szenerie anstatt das Generieren der Koordinaten der Laufzeit im Spiel zu überlassen.

Noch zur Anmerkung: Ja mir geht momentan alles was in der Welt passiert auf den Sack, da knallts überall aber gewaltig, alle Nachrichten scheisse, Klima kaputt Buhnen am Rhein sind fast schon das ganze Jahr leer, soll ich Zander im Hauptstrom angeln?.... Und irgendwie gehört die KI mit ihrer bedrohlichen Seite auch zu Dingen von denen ich in meiner "Flucht" in die schöne TSC Welt nichts wissen will. Bin zufrieden mit ihm so wie er ist. Das bringt wohl das Alter mit sich und es ist ganz angenehm mal nicht mehr "mehr" zu wollen. Das als menschliche Anmerkung.

Zitat von Spikee1975

habe oft bemängelt dass RSSLO ihre 3D Bäume fast ausschliesslich sogar in kleinen Gärten per Assetblock platziert haben

Lese ich tatsächlich zum ersten mal. War mir nicht klar, dass RSSLO oder andere sowas praktizieren. Ich dachte es sei Usus, dass man in Assetblöcken nur 2D nimmt.

Zitat von Spikee1975

Das ist kein Widerspruch du kannst dir genanntes Beispiel mal anschauen und selbst erleben dass ein klarer Bruch zwischen dem DTG Abschnitt und dem Userabschnitt zu merken ist, da steht das Bild 20 Sekunden bevor es weitergeht obwohl die Szenerie selbst genauso aussieht

Welche Stelle und Strecke meinst du jetzt nochmal genau? Für unsere Strecke kenne ich keine "20 Sekunden einbrüche". Da hackt es mal eine Sekunde und weiter gehts (wie bei den meisten Strecken). Eine Ausnahme ist eine Kachel wenn man von Bad Harzburg kommt und auf Oker zufährt. Da stockt es mal 3-4 Sekunden. Wir sind bis heute nicht dahintergekommen woran das liegt. Wenn du da mehr weisst, wären wir an der Antwort sehr interessiert.

Weiter oben, das Beispiel ist die Hudson Line nach Poughkeepsie Workshop Erweiterung. Durchgehend gleichgute Optik aber bautechnisch anders, nördlich von Croton Harmon gehts los mit der Ruckelei schlimmer als TSW Shader Compilation.

Zu Harnetz, wenn es einmal 3-4 Sekunden stockt dann ist das meines Erachtens nicht schlimm. Muss man genau nachkucken. Leider ist bei euch zuviel Vegetation aus zig Providern freigeschaltet (meine damals an die 1000 Bäume gezählt zu haben wo andere Strecken mit 20-30 auskommen), und ich vermute dass vieles davon auch doppelt und dreifach vorhanden ist. Wenn ich also optisch ne "Black_Ash_tree" als Beispiel einmal aus DTG\xy und daneben aus DTG\ab verbaue weil das in der Liste nicht zu erkennen ist kostet das schon Leistung weil mehr oder wenig doppelt vorhandene Meshes gecached werden an statt nur eines für alle dieser Art auf der Kachel (das gleiche gilt für Repaints, gleiche Geos aber für die Engine verschieden da anderer Pfad, aber der ReskinBlueprint ist nicht so beliebt weil nicht QuickDrive fähig oder anderes wie zusätzliche Childs). Aber wie gesagt muss ich nachschauen, was bei Oker los ist.

Zitat von Spikee1975

Leider ist bei euch zuviel Vegetation aus zig Providern freigeschaltet (meine damals an die 1000 Bäume gezählt zu haben wo andere Strecken mit 20-30 auskommen), und ich vermute dass vieles davon auch doppelt und dreifach vorhanden ist

Jepp, ist genau wie du es beschreibst. Das gleiche gilt bei den SAD Assets. Der Ursprung der Strecke ist über zehn Jahre alt und da wurden halt Fehler gemacht. Es ist unübersichtlich beim bauen, aber ich weiss nicht ob es großartig Einfluss auf die Performance hat. Da man im Harz eh kein KI Feuerwerk abbrennen kann, wird man warscheinlich niemals an die Ramgrenzen stoßen. Da ist dann mehr Spielraum für Ausgestaltung. Bad Harzburg-Hildesheim kannst du froh sein, wenn du 5 andere Ki Züge zu Gesicht bekommst. Ist halt kein Hamburg-Hannover, wo man 100 KI Züge plazieren kann, wenn es realistisch sein soll.