Wollte hier mal meinen Senf beigeben.
Meine Hauptbeschäftigung ist Fehlerbehebung. Aus Erfahrung kann ich sagen, dass 99,9% aller Abstürze von fehlerhaften Blueprints kommen.
Eine grosse Fehlerquelle sind händisch bearbeitete xmls, da kann schon mal eine doppelte ID reichen um Fehlverhalten auszulösen (jede ID muss einmalig sein innerhalb eines Blueprints). Wer sich mal die Texturing.bin von Bessemer & Lake Erie ansieht dem kommt das Grausen, Copy Paste und mehrfach vergebene IDs. Erst nachdem ich die neugebaut hatte lief die Strecke absturzfrei.
Es exisitiert sogar eine template bin von JustTrains die beim unSerzen die festplatte füllt bis sie platzt oder man mit Ctrl+C abbricht. Das Fehlen einer klitzekleinen spitzen Klammer kann ausreichen. JustTrains ist ein eigenes (gut erforschtes) Thema - bitte nicht auf Steam kaufen. DTG haben da Mist gebaut - die packen die .aps, und es können sich mehrere .aps in einem Asset Ordner befinden mit identischen Inhalten, was nicht geht, weil der Cache Generator keine von beiden priorisieren kann und aussteigt. Wenn also der TS OHNE Fehlermeldung zum Desktop crasht, sucht nach einer blueprints.pak mit 0 bytes - löschen alleine reicht nicht, sondern schauen was in betreffendem Assetordner los ist. Das passiert leider auch bei Tehachapi wo die gleichen Assets zweimal (mit und ohne BNSF logo verschickt werden - es kann nur einen geben.) In dem Fall muss man die Unbranded ES44 per Steam DLC Manager deaktivieren.
Ich hatte mir letztens mal die ungarische MAV70 vorgeknöpft (nix spektakuläres, noch im Bau). Neben massenweise Fremdassets im Kuju Ordner (kann praktisch nur der Autor selbst spielen) hab ich mir dann auch die RouteProperties mal angeschaut. Näheres dazu im DTG Forum "'t Hart van Nederland & Freeware", hab mir die Finger wundgeschrieben.
Kurz gesagt, es ist extrem wichtig dass Assets korrekt preloaded werden. Wenn eine Route ewig lädt trotz SSD kommt das davon dass verwendete Assets nicht im <BlueprintSetPreload> tag der RouteProperties stehen. In diesem Fall lädt der TS scheinbar nicht die extrem wichtige blueprints.pak, sondern sucht jedes Asset einzeln als wenn es keinen Cache gebe. Habe mir von TSTools alle verwendeten Assets listen lassen und die RouteProperties.xml manuell restrukuriert. Ergebnis - keine Abstürze nach Erstellen eines Szenarios und Play klicken, und extrem reduzierte Ladezeit. Seht die Blueprints.pak als Equivalent und Mischung aus Unreal AssetRegistry.bin und uasset. Der Trick hier ist einen Index aller Assets zu haben so dass quasi Addressierung an einem Stück gelesen werden anstatt Header-Data-Header-Data (und blueprints.pak werden komplett in den Speicher gelesen, die Assets selbst nur wenn benötigt und wieder entfernt wenn nicht benötigt.)
Der oft verbreitete Mythos, eine .ap werde in den Speicher geladen stimmt nicht. Das ist ein virtueller Pfad den zlib.dll verwaltet und völlig transparent an TS weitergibt, der davon garnix weiss. Die .ap hat ihre Existenzberechtigung weil a) Moderne Dateisystem grosse Dateien lieben und zehnmal schneller verarbeiten als die gleiche Datenmenge in losen Files (ist wie Bierkasten holen statt jede Flasche einzeln zu kaufen, bezahlen und nach Hause bringen, dann das gleiche Spiel wieder.), b) ein Prüfsummencheck in Sekundenbruchteilen erfolgt und c) zerstörungsfreies Modden möglich wird (Override statt Overwrite). Ich brauche keine bak. Dateien da das Original geschützt im unkomprimierten .ap Container liegt und ich bloss die Mod löschen muss um zurückzugehen. Prinzip von John Carmack eingeführt in Doom, mit IWAD und PWAD Dateien.
Ebenso falsch ist der Mythos Steam würde Dateien löschen nach einer Überprüfung. Steam löscht niemals Daten die es nicht selbst angelegt hat, nicht mal durch eine komplette Deinstallation. Wer hier löscht ist eine Routine im TS die ausgelöst wird wenn die Überprüfung den Core (appid 24009) neu herunterlädt aufgrund von Unterschieden zum Originaldepot nach Verifikation - getriggert durch eine dort befindliche Datei namens verify_cache_key. Trifft TS auf diese, vergleicht es den Inhalt von .ap Archiven mit losen Dateien im gleichen Pfad und löscht Duplikate um dem Tech Support ein Werkssystem zum arbeiten zu geben. Steam selbst kümmert der Inhalt von .ap Dateien wenig, es kann sie gar nicht lesen. Nach der Löschung die sich durch eine lange Startphase deutlich macht, wird verify_cache_key auch wieder gelöscht.
Wer seine RailWorks Installation also im Steam Pfad hat (muss man nicht, läuft von überall sogar mehrfach Instanzen), kann sich eine .bat Datei schreiben die auf Vorhandensein dieser kleinen Triggerdatei prüft, ggf löscht und dann RailWorks startet. Nur soviel dazu.
Wenn QDs crashen, lasst mal LogMate mitlaufen - es finden sich zahlreiche korrupte consist preloads - alles was LogMate als INVALID DATA moniert muss gelöscht werden.
Fragwürdig aber vom TS verdaut werden immer noch falsche CabOcclusion blueprints von DigitalTrainModel (der nimmt Tunnel Occlusion blueprints und ist nicht lernfähig wie es scheint.).
Habe mittlerweile ne 1.6 TB Installation mit aller erdenklicher Freeware, und manches muss aussortiert werden und oder kann repariert werden. Ganz selten bleibt was "unerklärlich". Was bleibt sind Fehler im Streckenbau (wenn logmate haufenweise network ribbon synched meldungen ausgibt - der TS handelt dass jedoch ziemlich gut und macht oft noch das beste aus der Situation, bis es halt knallt.
Will sagen, der Grund kann meistens lokalisiert werden. An Hardware oder Pagefile rumzuspielen ist nicht der Weg. Es ist der Content.
Es sind ganze zwei DTG Szenarien bekannt die das Core Update nicht verdaut habe, für beide habe ich Patches (keine Klone, also Achievement und XP tauglich) auf trainsimcommunity hochgeladen. Grund sind striktere Assertions (Annahmen) beim Platz zum Rangieren, die den Editor und Szenarien stabiler gemacht haben. Mittendrinabstürze habe ich nicht mehr erlebt. Da Szenarios alle Dispatcher Berechnungen fertig in der scenario.bin haben, funktionieren diese nun nicht mehr. (Dispatching geschieht im Szenarioeditor, Signalisierung im Spiel).
Fast vergessen, Workshop: Immernoch passiert es, dass bei Mehrfachabos die ScenarioProperties.xml zerschossen wird.
Das läuft so. Du klickst den Abo Knopf, Steam lädt den Inhalt als .zip herunter nach steamapps\workshop\content\24010. TS kriegt nen Ping daß er da nachgucken soll. Er entpackt das zip und schiebt es nach RailWorks\temp. Dort fügt er drei Workshop Tags in die xml ein die den Inhalt als "Workshop" kennzeichnen. Danach kopiert er den Inhalt in den Content Ordner. Bei jedem Start werden die Inhalte des workshop ordners mit dem lokalen Inhalt verglichen und bei bemerkten Änderungen das Workshop file neu kopiert.
Das ganze funktioniert so lang, als TS nur eine Datei zu bearbeiten hat. Wenn hier aber mehrere hintereiander abonniert werden, versaut der TSC aus irgendeinem Grund die xmls. Da hockt man dann vor einem nicht mehr starten wollenden TS der nun eine korrupte SDBCache.bin hat und auch noch ständig die Abos abgleicht mit dem was auf der Platte ist.
In dem Fall: ALLES runter was Workshop ist. Deabonniert alles, löscht die zips aud RailWorks\temp und leert steamapps\workshop\content\24010.
Der geschickteste Weg ist auf diesen Workshop syncing Firlefanz zu verzichten (TS Workshop inhalte dürfen sowieso nach Finalisierung nicht geupdatet werden da es Szenarios inkompatibel machen könnte):
Lasst TS geschlossen, abonniert fröhlich so viel ihr wollt, klickt alle Coasty Szenarios an, was auch immer.
Dann mit nem gescheiten Allesfresser wie 7zip Filemanager in den steamapps\workshop ordner gehen, per Doppelklick durch die zips klicken bis ihr am Content folder angelangt seid und Railworks noch als zweite Ansicht aktivieren, dann könnt ihr direkt alles nach RailWorks kopieren ohne das der TSC was von mitkriegt, wie jedes andere heruntergeladene Szenario auch. Das bleibt dann auch bei euch auch wenn's der Autor löscht.
Danach leert ihr den Workshop folder und deabonniert alles wieder!
Der Daumen hoch / runter taucht nicht mehr auf, also dem Autor auf seiner Workshopseite direkt für den Spass oder Stress danken 
Edit: Zum Schluss noch dies: wer irgendwo fahrende schwarze riesige Wände sieht braucht nur in den Welteditor zu gehen und RSDL\IslandLine zu aktivieren (wer die nicht haben sollte der hat auch die Wände nicht). Grund ist hier der ScaleRail RoadTraffic der auf IslandLine Autos zugreift, diese aber nicht preloaded werden (verschachtelte Referenzierung.) Ein GeoPcDx das nicht preloaded wird UND sich bewegt erzeugt Polygonmüll. Das ging wohl zu KRS Anfangszeiten ohne Cache und Scenarioproperties als der TS sich beim laden halt alles zusammengesammelt hat, als absehbar wurde das man ein Konzept zum Handeln der Riesen Datenmengen braucht ging das so nicht mehr. Bei statischen Shapes ist es egal, deshalb muss die VegEP von AP auch nicht geladen werden. Die bins holen sich die statischen Geos aus dem AP Folder ohne Probleme.
