Zusi-Forum

Hallo Community,

kann mir bitte jemand erklären, was diese "dumps" sind?

Ich hatte nämlich ein Video von Zusi 3 auf youtube geschrieben - welches in den Kommentaren öfter mit TS2016 verglichen wurde, letzterer hätte wohl im Gegensatz zu Zusi nach jedem zweiten Szenario eben einen solchen "dump" - keine Ahnung was das ist, oder ob es auch im TS18 noch so ist, würde mich aber interessieren.

Wie immer, vielen Dank im Voraus!

Gruß,
Robin

Dump = das Programm kommt mit Fehlermeldung zum Stillstand und muss beendet werden. Beim Train Simulator passiert das gerne, weil die Addon-Autoren hoffnungslos verschwenderisch mit dem Arbeitsspeicher umgehen.

Das wird uns in Zusi auch irgendwann passieren. Sobald irgendjemand noch zwei oder drei Module an den Raum Kassel dranhängt, rechne ich damit dass der resultierende Knotenbereich Kassel mit dem jetzigen nicht LAA-fähigen Simulator nicht mehr im gesamten fahrbar sein wird, und zwar selbst dann wenn wir drakonische Sparmaßnahmen ergreifen wie die Rückkehr zu den alten Zusi-2-Füherständen und Sounds. Man wird dann Kassel halt nur in Teilstücken genießen können.

Gegenbeweis Raum Hagen-Schwerte. Der stellt Kassel aus meiner Sicht in den Schatten.
Ok, Vorhalle habe ich derzeit nicht auf der Agenda.

Grüße
Michael

hallo Alwin, ah jawoll, danke erstmal....
im Ernst jetzt?

Also ich ringe nach wie vor mit mir ob ich mir nun Zusi nun hole oder nicht, aber das ist irgendwie so...*schluck*

Deiner Antwort nach Michael, bist gehörst Du zu den Erbauern des Kasseler Raums und widersprichst der These, oder wie habe ich das zu verstehen?

(Sorry...kenne Euch ja noch nicht, keine Ahnung wer an welchem Projekt arbeitet und so... )

bzgl den Arbeitsspeicher der AddOns, naja, ohne mich auszukennen, habe ich mich ja schon etwas über die unterschiedlichen Angaben der Systemanforderungen zu den Strecken gewundert - insofern diese dann auch stimmen

RobinG hat geschrieben:Also ich ringe nach wie vor mit mir ob ich mir nun Zusi nun hole oder nicht, aber das ist irgendwie so...*schluck*

Bei vernünftigen Einstellungen des Simulators läuft Zusi Stand heute auch in Kassel, ohne dass er wegen Speichermangel den Core dumpt. Ich wollte nur drauf hinweisen, dass uns da aber in der Zukunft ein Problem ins Haus steht, wenn man ausgerechnet an dieser Ecke des Streckennetzes anbauen würde.

Wem die Möglichkeit zu zweieinhalb Stunden Fahrt am Simulator "in einem Rutsch" immer noch nicht ausreichen, der sollte aus meiner Einschätzung eh zum großen Vorbild wechseln und sich als hauptberuflicher Lokführer verdingen...

Grüße
Michael

Also im Moment ist das aber Spekulation. Hängt halt auch von der Zugdichte und deren Polygonbedarf ab.

Carsten

Das Problem bei Zusi ist nicht primär der Speicher- sondern der Adressraummangel



Sobald das Problem akut wird müsste man versuchen, Carsten zu überreden, den Speichermanager auszutauschen. Johannes hat dazu ja schon mal was grob angerissen. Eventuell lindert sich das Problem bereits dadurch, zudem hat man damit die Möglichkeit, das LAA-Flag serienmäßig einzuschalten. Insbesondere letzteres würde dann erst mal eine ganze Weile Reichen. Der Aufwand, den das bedeuten würde, ist schwer abzuschätzen, deswegen sind wir das alle etwas zurückhaltend.

Die Botschaft ist aber, dass du dir erst mal keine Sorgen machen musst, was den Adressraummangel betrifft, solange du bei moderaten Einstellungen bleibst. Wenn in Zusi Streckenbauer an die Grenze kommen werden sie zusammen mit Carsten schon nach einer Lösung suchen.

Zur Not hilft systematisches Ausdünnen oder Optimieren bereits vorhandenen Quelltextes (siehe Beitrag von F. Schn.). LAA als mittelfristige und 64 Bit als langfristige Lösung stehen auch noch irgendwo im Raum. Ist halt die Frage, wie effizient und zeitintensiv eine Umstellung ist und ob proprietäre Abhängigkeiten vorhanden sind, die z.B. nicht mit 64 Bit-Anwendungen kompatibel sind.

Letzteres war der Sargnagel für den Train Simulator. DTG hat nicht Zugriff auf den vollständigen Quelltext und zu viele proprietäre Programmabhängigkeiten wurden nicht weiterentwickelt und sind nicht in 64 Bit-Programmumgebungen lauffähig. Am Ende war ein Enginewechsel zur Unreal Engine 4 womöglich der wirtschaftlichste und effizienteste Weg - jedenfalls sieht DTG das so. Dazu kommen dann Streckenbauer, die gewinnoptimiert arbeiten (teilweise gezwungenermaßen) und eine gewisse Art der Selbstverwirklichung im 3D-Modellbau erreichen möchten. Gut sehen die Strecken aus, aber außer dem Spielerzug fährt dann eben nichts mehr ohne Absturz.

Michael_Poschmann hat geschrieben:Wem die Möglichkeit zu zweieinhalb Stunden Fahrt am Simulator "in einem Rutsch" immer noch nicht ausreichen, der sollte aus meiner Einschätzung eh zum großen Vorbild wechseln und sich als hauptberuflicher Lokführer verdingen...

Grüße
Michael

Wen meinst Du?

Die Überlegung habe ich allerdings schon in Betracht gezogen.

@Fabian...

mal abgesehn davon, dass ich passend zum Thema "nur Bahnhof" verstehe : ist das noch immer so beim TS? Oder haben die es mal auf die Kette bekommen? Apropos AddOns...gibts da seitens den Entwicklern eig. Unterschiede? Also in dem Sinn, dass manche technisch (ich meine nicht optisch, sondern eben zB das diskutierte Problem u.a.) "okay" sind und andere nicht?

Michael_Poschmann hat geschrieben:Wem die Möglichkeit zu zweieinhalb Stunden Fahrt am Simulator "in einem Rutsch" immer noch nicht ausreichen

Wir reden bei diesem Effekt gar nicht ausschließlich über Großfahrpläne mit mehrstündiger Fahrzeit. Das kann dann schon kleine Touren von kaum 20 km betreffen. Stell dir vor, Du willst von Ihringshausen über Wilhelmshöhe nach Guntershausen fahren, aber in Kassel Rbf macht dir jedesmal der Simulator die Grätsche, weil der Standard-Laderadius dazu führt, dass er den Adressraum komplett mit Streckenmodulen ausfüllen muss. Ich hatte das für den Raum Kassel schonmal grafisch dargestellt:

Carsten Hölscher hat geschrieben:Also im Moment ist das aber Spekulation.

Da Michael und Du ja so sicher sind, dass das noch kein Problem ist, habe ich den aktuellen Entwicklungsstand des Fahrplans Hagen - Warburg und des Streckennetzes (die Bauspitze steht aktuell in Hengstey) gerade probegefahren und ein Auge auf die Speicherauslastung gehabt. Ergebnis: Sowohl der Fahrplan 4-12 Uhr als auch der Fahrplan 12-23 Uhr stürzten mit einem Simulator auf Standardeinstellungen im Bahnhof Schwerte wegen Speichermangel ab. Vor ein paar Wochen liefen diese Fahrpläne noch, aber da war der Landschaftsbau in Hengstey auch noch nicht angefangen. Knapp war der Speicher auch damals schon. Soviel jedenfalls zur Spekulation.

Bin deutlich über den Standardeinstellungen unterwegs und hatte bislang noch keinen Absturz zu vermeldet. Dass mein angejahrter i5-Rechner ein High-End-Gerät sein soll, möchte ich mal verneinen. Und ein paar weitere Mitbastler und Tester sind ja auch im Boot - bislang gab es keine Rückmeldungen dieser Art. Bin also weiterhin entspannt.

Grüße
Michael

Michael_Poschmann hat geschrieben:bislang gab es keine Rückmeldungen dieser Art.

Dann sollten wir diesen historischen Moment festhalten. Zusi ist gerade mit 1400 MB Speicherauslastung bei Westhofen abgestürzt:


Wer Zugriff auf den noch unveröffentlichten Fahrplan hat und selber testen möchte: Ruhrtalbahn_Fahrplan1981_12Uhr-23Uhr.fpn, Zug 246 von Abzw Heide nach Hagen.

i5-7400, 16GB RAM, Geforce 1050

50% Chance...

Fahrt 1: Sichtweite 4000m, bis kurz vor Bahnsteig Schwerte
Fahrt 2: Standardwerte alle Kacheln, Höchstwert 1336 MB kurz vor Sbk74, heil in Hagen angekommen.



Michael

Alwin Meschede hat geschrieben:Zusi ist gerade mit 1400 MB Speicherauslastung bei Westhofen abgestürzt:

Zur Erklaerung, warum das 1400 MB sind und nicht 2 GB: Die Spalte "Arbeitsspeicher" auf der Uebersichtsseite des Taskmanagers ist die Groesse des "Private Working Set". Das ist der Speicher, den das Programm wirklich "verbraucht", weil er a) nicht einfach eine Kopie von etwas ist, was auf der Festplatte liegt (z.B. die Zusi-Exe) und b) nicht mit anderen Programmen geteilt ist (wuerde sonst doppelt gezaehlt). Bei Zusi ist das zu nahezu 100% der Heap, also der Speicher, den das Programm zur Laufzeit anfordert -- zum groessten Teil also 3D-Daten.

Wie von F.Schn. angesprochen, gibt es aber durchaus noch andere Dinge, die im Adressraum des Programmes liegen, also vom Programm adressierbar sind. Zum Beispiel diverse Windows-DLLs, deren Funktionen Zusi aufrufen muss. Von solchen Dingen ("Image") sind im Bild unten fast 200 MB adressierbar, aber nur 4 MB verbrauchen tatsaechlich Arbeitsspeicher.



Das Problem ist nun, dass Zusi derzeit nur mit Speicheradressen umgehen kann, die unterhalb von 2 GB liegen. Somit gehen ihm die Adressen frueher aus als der Speicher, was natuerlich eine ganz bloede Sache ist -- es liegt so viel Speicher herum, aber man kann ihn nicht nutzen.

Oh weh, da habsch ja was los getreten.......

aber interessant zu lesen und gut zu wissen.

RobinG hat geschrieben:Oh weh, da habsch ja was los getreten.......

Keine Angst, das ist hier schon laenger Thema. Es ist nur eine gute Gelegenheit, die alte Gebetsmuehle wieder hervorzuholen.

Gott sei Dank, hatte schon Schweißperlen auf der Stirn. 3 Tage hier und schon Unruhestifter.....

Ergänzung zu Johannes: Das mit dem Adressraum ist die Spalte "Virtual Size" im Prozess Explorer - wie gesagt zeigt der Taskmanager keine geeignete Größe zu diesem Thema an, erst recht nicht die erste Seite vom Taskmanager von Windows 10...

Und ich war auch der Meinung das a) die Fahrtdauer irrelevant ist, sondern nur die Örtlichkeit und maximal noch die Fahrplangröße und b) völlig irrelevant was man für einen Rechner hast, solange man nach dem Neustart mehr als 2GB Arbeitsspeicher frei hat.

Hallo Alwin,

ich gebe zu, Deine Meldung hat mich ein wenig nervös werden lassen. Nun kann ich aber beruhigt die Ankunftsmeldung für den Ost-West-Express kundtun. Nicht in Aachen, da fehlen noch ein paar Baujahre an Strecke, aber immerhin in Hagen Hbf. Laut Fahrtbericht einziges Vorkommnis: In den Schlafwagen ist das Fahrbier ausgegangen.

Die Probefahrt hat sich insofern gelohnt, als mir am Abzweig Heide noch zwei Bettungsfehler ins Auge gesprungen sind. Wird korrigiert.

Grüße
Michael

p.s.: Nebenbei hatte ich, um untypische Last zu erzeugen und einen Absturz zu provozieren, noch weitere Programme geöffnet.

Nachtrag: Sichtweite 7.000 m, LOD-Faktor 120%. Also anspruchsvoller als die Standardeinstellungen.