[DTG] Train Simulator 2019

..also die letzte Meldung, nach dem Access Violation Fehler läuft der TS weiter. Bei Win 7 muss ich nur den entsprechenden Prozess über den Task Manager killen, nix Neustart. Macht Ihr da etwas falsch? Außerdem, der früher bekannte Dump kommt im 32bit-Modus nicht mehr, dafür der der Access Violation Fehler, trotzdem, ich kann bei meinen Strecken im 32 bit-Modus deutlich mehr machen, als in der Vorgänger-Version. Diverse Funktionen im Editor sind deutlich problematischer und lassen den Speicher schneller vollaufen: Höhenpfeil, Bodentexturen pinseln sind solche. Ich lasse den Task Manager nebenher mitlaufen, den Access Violation Fehler bekomme ich nur, wenn ich zu optimistisch war, oder das Zwischenspeichern mal vergesse.

Gruß Bernd

Für die letzte Meldung habe ich eine Batch Datei die den TS Prozess killt. Nutze ich auch gerne im Editor.

Ich baue gerade ein Szenario für HH Deluxe und bekomme momentan auch immer die Access Violation Meldung, wenn ich mich nach Hamburg Hbf teleportiere. Allerdings schließt sich der TS dann von selbst und ich kann den PC normal weiterbenutzen.

Nutzt ihr den Szenario Editor im Fenster oder Vollbildmodus?! Und in welcher Auflösung?! Wenn würde ich es immer in Fenstermodus ausführen, ich nutze dafür 1400x900 bei einen 1920*1080 Monitor. Vielleicht hilft das ja etwas?! Zudem evtl. mit Sichtweite rumprobieren?! Oder Szenerie Qualität. Normal kommt der Acces Fehler nur, wenn er Probleme hat, auf den RAM / Virtuellen RAM zu speichern.

@Mumpfi2010

Bei mir ist der Fehler in letzter Zeit nicht mehr aufgetreten, ich nutze Win7 Home Premium. Ich war die Tage noch am Donner Pass unterwegs. Habe mehrfach gespeichert und bin ein paar Tage später weiter gefahren, es gab keine Probleme. Nach Beendigung des Szenarios habe ich den TS minimiert um ein paar Bildchen zu bearbeiten. Als ich ihn dann wieder auf Vollbild umstellen wollte, ist er abgestürzt mit der Meldung "Vertex buffer, etc..." Tragisch war das jetzt nicht, a) ich wollte eh schlafen gehen, b) kommt es nicht so oft vor.

Seems like a fix for the 64bit editor problems is on the way.

Na, dann bleibt zu hoffen, dass WENN das Update kommt, es auch wirklich besser wird (ich hab bei so Sachen irgendwie immer Schiss, dass es hinterher schlimmer wird).

Arbeite selbst übrigens mit 32er-Editor im Fenstermodus. Mal kommt öfters der AV Fehler mal nicht. Und oft kommt er auch erst, wenn ich aus dem Editor rausgeh.
Der Dump ist tot, hoch lebe der Access Violation

@Tilmann Beim Szenariobau nutze ich den Editor im Vollbildmodus (2560x1440).

Hey Tilmann, ich nutze im Editor den 32bit- Modus aus bekannten Gründen. Einstellung: siehe Bild
Gruß Mumpfi2010

Beim bauen nehme Ich die Szeneriequalität zurück, seitdem hatte ich keinen Absturz mehr.

mihu65

@Gsonz

Ich würde dir echt empfehlen beim Szenario bau, auch gerade wenn man die LUA Scripts verwendet und zwischendurch aus dem train Simulator rausgehen muss, den Fenstermodus zu verwenden. Ist ja auch eine recht hohe Auflösung, da kann es evtl. dazu kommen, je nach Szenarie Qualität, das der Editor schon schneller voll läuft bzw auch schneller Probleme mit der Adressierung der RAM bekommt, bzw Doppeladressierung. Was läuft denn alles im Hintergrund, und wie sind deine Einstellungen für virtuellen RAM?! Mindestens sollte der virtuelle RAM auf "Automatisch - System abhängig" eingestellt sein und auf keinen Fall ausgeschaltet sein. Nur wenn man sich da etwas auskennt, kann man natürlich das manuell vergeben und die jeweilige Festplatten mit freien Speicherkapazitäten wählen ...

Wichtig dafür ist eben auch der Speicherplatz auf Festplatten, woher das System den virtuellen RAM nutzt. Und noch wichtiger, nicht so viel Programme im Hintergrund laufen lassen, die selbst stark den RAM ausbremsen. Ich habe den Defender bspw auch ausgeschaltet und kein AntiViren Programm am laufen, der teils in Programmen eingreift und prüft. Beim Spielen ist es natürlich nicht notwendig, wenn man im Netz surft sollte man natürlich wieder einschalten, je nachdem wie man sich mit dem PC auskennt ....

@Mumpfi
wenn dein PC das schafft und du so großen Monitor hat, ist es ja auch gut, da kann man durchaus auch höhere Auflösung nehmen. Denke aber wenn einige eben nur "normal" diese Monitor Einstellung haben, können diese das Fenstermodus nur aktivieren, wenn die Rahmenlos nehmen, aber würde für den Szenario bau auch nicht vom vorteil sein.
Im Szenario bau würde ich keinen 32 Bit Editor nehmen, oder man verzichtet auf mehr Fahrzeuge und muss immer die RAM Auslastung im Auge behalten. Da kann man bei hohen Details und guten Texturen schon sehr schnell auf über die 3,7 GB Marke kommen. Zudem würde ich da das Programm Process Explorer 64 verwenden, wie AbsolutesChaos mal mir auch erklärt hatte, da dort die wirkliche RAM Auslastung in Form vom "Virtuellen Size" abgebildet wird.
Im Welteditor natürlich nur mit dem 32 Bit Editor arbeiten. Da hast du recht.

Nur nochmal zum Hinweis, ich arbeite mit 4 GB RAM und hab eher selten bzw nur bei wirklich hohen RAM Verbrauch im Virtual Size diese Fehlermeldung, wie eben damals DUMP. Fängt bei mir mit 11 GB Virtual Size an zu knacksen ...

Hallo,

ich hab auch gute Erfahrungen den Editor im 32bit Mode zubetreiben, da ist es wichtig wie schon geschrieben im Fenstermodus zu sein und in den Grafikeinstellungen die Sceneriequalität auf 50% runter zudrehen, Gleiches habe ich auch bei der Schatten- und Wasserqualität getan und der Editor wurde wesentlich stabiler, da der RAM nun nicht so voll gepumpt wird mit Daten.

Von Editor im 64bit Mode sollte man die Finger ganz lassen, sowohl im Streckenbau wie auch im Scenariobau - dieser manipuliert in beiden Fällen die Tracks.bin und der SuperGAU ist ausgelöst - tagelange Arbeit ist dann zum Teufel und man kann wieder von vorn beginnen.

Ich habe 2 TS Installaionen auf verschiedenen Platten (SSDs) auf einer fahre ich ausschließlich und die andere ist meine "Bauinstallation" so umgehe ich eine ständige Umstellung der Grafikeinstellungen.

Um die Access Violation zu mindern, arbeite ich zusätzlich mit dem Tool Razer Cortex, dies schließt alle Windows Dienste und Anwendungen, die während des Betriebs des Spiel nicht benötigt werden und schafft somit Platz im RAM, im leeren RAM kann somit keine Zugriffsverletzung (Access Violation) stattfinden, nur beim Versuch der erneuerten Zuteilung.

Zur Zeit kann ich zumindest relativ stabil am Projekt arbeiten, nach 1 Stunde mache ich meist einen Neustart des TS und fahre bis jetzt damit eigentlich gut, einschließlich eines Backup nach jeder Session.

@rschally Daß der 64bit Editor beim Bearbeiten von Szenarien die Tracks.bin oder irgendetwas an der Strecke ändert bezweifle ich ernsthaft !!! (Mit 3 Ausrufezeichen, weil es so gemeint ist).
Man kann das doch einfach überprüfen indem man das Datum der letzten Änderung der Dateien im Routenordner ansieht.

Ich bin seit einem halben Jahr jeden Tag öfters im Szenarioeditor, seit der TS2019 herauskam ab dem ersten Tag im 64 Bit Editor für Szenarien.
Bei mir gab es praktisch nie ein Problem (nur ein einziges Mal einen von diesen 0x000...5 Access Violation Meldungen).

Da hast du eben einfach Glück gehabt. Ich habe nun schon mehrfach Fehler entdeckt. Gerade erst wieder, wo ich dran bin in jeder Kachel der Rollbahn diverse Änderungen außerhalb des TS mit XML-Tools vorzunehmen. Es passiert also sogar beim bearbeiten von Scenery. Die Fehler sind selten und entstehen scheinbar auch aus unterschiedlichen Situationen heraus. Genau ist das nicht zu erkennen. Aber sie passieren und zerstören zumindest diverse Szenarientypen inkl. QDs und eben auch Tracks und Scenery. Wobei das bei der Scenery nicht auffällt, da der TS nicht ladbare Knoten einfach übergeht, also verwirft. Bei Dingen die von der Track-Infra abhängen aber geht das nicht und er stürzt sofort ab. Alles meine Beobachtungen seit es die 64bit Version gibt. Er zerschießt sogar quasi on the fly Gleisanlagen, die im TS2018 erstellt wurden und nie im TS2019 bearbeitet worden sind.

So es gibt angeblich Neuigkeiten, sie testen einen Fix nach einer gefühlten Ewigkeit ...

"Just to update you on where we are with this. So further to Luke's post, after extensive investigation, we think we have a fix that's in testing right now. If all goes well with that testing, we will roll this update live. Once I get a definitive date/time, I'll update everyone. Apologies it has taken us so long to get here."

Sorry war weiter open schon geposted, mal sehen, ich glaubs auch erst wenn es funzt.

Die Access Violations durch repaints und gefummelt fixt das aber leider nicht.
Wohl nur den 64 Bit editor zum Streckenbau

Hoffentlich kommt bald ein Bugfix Patch.

@120

der TS hatte ja immer schon ein Speichermanagement Problem was sich damals eben durch die SBH Meldungzum großen Teil äußerte (natürlich nicht nur eine Zugriffsverletzung), ich möchte aber meinen das dies mit eine Hauptursache der Abstütze war / ist. Durch begrenzten Adressraum im 32bit Mode ist die Auffälligkeit nicht ganz so hoch wie im 64bit Mode (dort potenziert sich ja der Fehler, sprich größerer Adressraum und somit die Wahrscheinlichkeit einer Zugriffsverletzung wesentlich höher ist).

Fakt ist, durch eigene Experimente zumindest auf meinen System, das Abspeichern im 64bit Mode die Tracks.bin dahingehend manipuliert wird, egal ob World oder Scenarioeditor, ein geänderter Datumseintrag der Datei ist nichtsaussagend dieser wird auch gesetzt wenn die Einträge der Tracks.bin korrekt geschrieben werden.

Wenn Du Dir sicher bist, das die Tracks.bin im Scenarioeditor nicht angefasst wird, dann kannst ja mal folgendes probieren, verschiebe mal die Tracks.bin der Strecke in der Du ein Scenario erstellst. Ich wette wenn Du ein Scenario erstellst dies speicherst und danach die Tracks.bin wieder zurück schiebst wird das Scenario nicht laufen bzw. wenn doch bestimmt fehlerhaft, weil der Scenarioeditor alleine schon für den Dispatcher die Tracks.bin braucht, auch wenn keine Scenariodaten in der Tracks.bin selber abgelegt werden.

Die reine 64bit Speicherroutine scheint ein Problem zuhaben, beim Schreiben der Daten in die Tracks.bin und dies Problem ist übergreifend sowohl im World wie auch im Scenarioeditor, daher wohl auch von @Maik Goltz seine Beschreibungen nicht von ungefähr kommen.

Erst mal abwarten was kommt, das arbeiten im 64bit World Editor "war" und wird dann auch wieder ein Genuß im Gegensatz zu 32 bit. Aber nochmal es kommt auch so viel auf die Konfiguarion an, im 32er zu bauen war/ist mit neuem System mal abgesehen vom extrem störenden Speicherlimit, wie beschrieben, durchaus passabel, klar hin und wieder Abstürze, gelbe Höhenpfeile und Bodentexturen sprühen, man kennt sich aber aus und "weiß" wann man zwischenspeichern muss (oder benutzt das Autosave tool, was bei mir nicht geht trotz neustem Java update, kurzes Aufpoppen der schwarzen batch box und dann nix). Ich fand das alles nicht dramatisch. Dann kam der kaputte 64bit, erstmal begeistert ... bis zum ersten Abspeichern ... ist ja alles dazu gesagt. Wenn die das jetzt geschafft haben dass es nicht die track.bin zereißt wird doch alles gut, jedenfalls in Anbetracht wenn man einer Mittsiebziger Dame eine neue Hüfte verpasst. Da zu erwarten dass es gar keine Abstürze mehr gibt wäre einfach vermessen, ist auch ne 30 Euro software, was solls muss man entspannt sehen.

@rschally Meinst Du ich soll die Dateien Tracks.bin und das Verzeichnis Track Tiles\ während der Arbeit im Szenario-Editor per Dateimanager sagen wir mal nach c:\tmp\ verschieben ? Das wäre allerdings ein Vorgehen, das so nie vorgesehen ist und wäre von daher kein Fehler der Software.