Spiel stürzte bei Autospeichern ab. Nun kann kein Spielstand mehr geladen werden!

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


  • Hi,


    ich hoffe mir kann jemand weiterhelfen.


    Das Spiel ist während einer Bauorgie beim automatischen Speichern abgestürzt. Danach konnte ich keinen Speicherstand mehr laden, weder automatische, noch manuel erstellte.
    Er hängt sich immer bei 60% auf.


    Die letzte stdout.txt habe ich im Anhang, falls das hilft.



    Vielen Dank


    CountMOPS

    Dateien

    • stdout.txt

      (15,42 kB, 255 Mal heruntergeladen, zuletzt: )

    Sir, wir sind umzingelt!
    Sehr gut! Dann können wir in jede Richtung angreifen!!!

    • Ein neues Spiel lässt sich starten?
    • Lässt sich das speichern?
    • Lässt sich dieser neuer Spielstand laden?

    Xubuntu 18.04 64bit – MSI Z170A GAMING PRO Carbon – Intel Core i7-6700K – ZOTAC GeForce GTX 970 OC (Treiber 384.90) – 40GB DDR4 RAM Transport Fever Build 15434

  • Nein, es wird nur festgestellt, dass die Verkehrszeichen und noch andere nicht in einem Cache vorhanden sind.


    Was TpF zerhaut ist dieses:
    c:\build\transport_fever\steam\transport_fever_release\src\game\urbansim\buildingsimulation.cpp:349: void __cdecl BuildingSimulation::PrepareThreadData::<lambda_87e59e9f007a9ebfd14207518b7d9aa7>::operator ()(const class ecs::Entity &) const: Assertion `it != destination2sp.end()' failed.


    Diese Fehlermeldung habe ich bisher noch nie gesehen...

  • Ein neues Spiel lässt sich starten?


    Lässt sich das speichern?


    Lässt sich dieser neuer Spielstand laden

    Hi,


    war ne gute Idee Atomic Dad. Das hatte ich noch gar nicht ausprobiert.
    Das neue Spiel konnte gestartet werden, es lies sich speichern und neu starten.


    Leider kann ich den eigentlichen Speicherstand immernoch nicht laden.



    Diese Fehlermeldung habe ich bisher noch nie gesehen...

    Dann lohnt es sich doch bestimmt diesen Fehler an UG zu senden, oder?


    Ps:
    Laut Gigabyte Sound Code hatte ich an diesem Tag einen "Memory Error". Das Mainboard hatte ca. eine Stunde lang immer mal wieder zwei Mal kurz gepiept. Dann irgendwann war es weg. Abends hatte ich dann den Absturz in TpF. Könnte beides irgendwie zusammenhängen?


    LG

    Sir, wir sind umzingelt!
    Sehr gut! Dann können wir in jede Richtung angreifen!!!

  • Guten Abend alle zusammen,



    Was TpF zerhaut ist dieses:
    c:\build\transport_fever\steam\transport_fever_release\src\game\urbansim\buildingsimulation.cpp:349: void __cdecl BuildingSimulation::PrepareThreadData::<lambda_87e59e9f007a9ebfd14207518b7d9aa7>::operator ()(const class ecs::Entity &) const: Assertion `it != destination2sp.end()' failed.

    gibt es bereits eine Lösung dazu? Leider hat es heute einen Speicherstand eines Spielstands von mir zerschossen. Die vorherigen lassen sich allerdings laden.
    Die stdout.txt-Datei spuckt mir eben diese Zeile aus. :/



    Vielen Dank im Voraus. :)

  • Die Simulation der Gebäude (buildingsimulation), vorallem bei einer hohen Einwohnerzahl, ist eine sehr aufwendige Angelegenheit. Kann es sein, dass diese Aufgaben von mehreren Threads wahrgenommen werden (PrepareThreadData) und das Zusammenführen im Hauptthread (desstination2sp) scheitert? Nur eine Idee, habe wenig Ahnung.

  • Klingt ganz gut und ergibt von der Erklärung her Sinn, aber:


    Ich habe anfangs alles abgerissen, was abreißbar ist, um ganz frei eigene Städte zu bauen. Die Anzahl der Gebäude, die ich bis dato neu gebaut hatte, entsprachen gerade einem kleinen Ort. Ich habe danach den vorherigen Speicherstand geladen und ordentlich weitergebaut, gespeichert und neu geladen und siehe da: der neue Spielstand lädt...


    Vielleicht habe ich etwas platziert, das alles zum Absturz bringt. Abwarten. :)

  • Dieser Fehler scheint in der Abbruchbedingung eines Loops seinen Ursrpung zu haben. Dabei wird überprüft ob der iterator "it" schon am Ende eines Datensatzes "destination2sp.end()" angekommen ist. Nun scheint irgendwo während der Ausführung des Programms der iterator oder der Endpunkt des datensatztes korrumpiert zu werden. Daraus resultiert dann "Assertion `it != destination2sp.end()' failed", gleich bedeutend mit: das Programm konnte "it" und "destination2sp.end()" nicht vergleichen. Als @CountMOPS in seinem Fall gleichzeitig einen Memoryfehler feststellte, dachte ich, dass dort darin die Ursache verborgen sei. Denn falls einer der beiden zu vergleichenden variablen im RAM korrumpiert wurde, würde ich genau einen Fehler dieser Art erwarten. Allerdings wäre es sehr Unwahrscheinlich, bei zwei von einander unabhängigen Memoryfehlern die selbe Fehlermeldung zu erhalten. Sowas würde sich eher als eine Art Fehlermeldungszufallsgenerator entpupen, als immerwieder dasselbe Resultat zu generieren.


    Daher würde ich einen Memoryfehler als eigentliche Ursache dieses Errors ausschliessen und eher auf einen seltenen Bug im Spiel tippen. Z.B. könnte es sein, dass mehrere Threads gleichzeitig auf den Iterator oder den Datensatz "destination2sp" zugreifen können. Wenn nun ein Thread gerade dabei ist am Datensatz eine Änderung vorzunehmen und glechzeitig untersucht ein anderer Thread diese Abbruchbedingung, dann könnte genau dieser Fehler auftauchen.


    @CountMOPS hatte damals das Pech, dass dieser Fehler gerade während des Speichervorgangs auftrat. Darum hat der folgende Programmabsturz auch dazu geführt, dass am Ende der Spielstand unbrauchbar wurde. @Nordoron hatte da mehr glück. Ich würde daher empfehlen, jeweils zwei Autosaves pro Karte zuzulassen.

  • Heisst das, dass der Zeiger dann am falschen Ort steht? Das wäre wirklich ein Bug. Wird denn die Liste nicht blockiert, solange ein Thread darauf zugreift? Besser wäre es dann, wenn jeder Thread eine eigene Kopie der Liste verwendet.

  • Heisst das, dass der Zeiger dann am falschen Ort steht?

    Könnte sein, falls der Datensatz in seiner grösse verändert wird, während die funktion end() ausgeführt wird. Allerdings ist es nicht einfach den genauen hergang einer Race Condition zu rekonstruieren. Dazu müsste man schon den ausgeführten Maschienencode im detail analysieren.


    Das wäre wirklich ein Bug. Wird denn die Liste nicht blockiert, solange ein Thread darauf zugreift?

    In C++ ist kein Datentyp automatisch thread-sicher, das muss der Programmierer mit Atomics oder Semaphoren schon selbst lösen. Falls es sich beim genannten Absturtz um eine Race Condition handelt, könnte man das Problem durch atomizieren des Datensatzes beheben. Aber man muss auch noch erwähnen, dass der Bug sehr selten aufzutreten scheint und dass atomisieren auch immer eine Leistungseinbusse mit sich bringt. Es gilt also abzuwägen, ob man eine behebung des Bugs einen wesentilchen Mehrwert bringt.



    Besser wäre es dann, wenn jeder Thread eine eigene Kopie der Liste verwendet.

    Kann man so nicht generell sagen. Denn vielleicht will der Programmierer ja, dass zwei Threads ihre Daten austauschen. Das würde dann bedeuten, dass Daten hin und her kopiert werden müssten, was wiederum sehr resourcen intensiv sein kann. Nicht nur, dass man damit den Zwischenspeicher mit redundanten Daten zumüllt, sondern man muss während des Kopiervorgangs alle voneinander abhängigen Threads anhalten. Die berühmten "Endmonatsruckler" aus alten Train Fever Tagen dürften dagegen ein Kindergeburtstag gewesen sein. Atomisieren, ist da wesentlich schaluer.

    Einmal editiert, zuletzt von chrigulix ()

  • Vielen Dank für die Erklärungen! :)


    Um das noch einmal aufzugreifen: Fehler im RAM bzw. Memory-Fehler oder anderweitige Ungereimtheiten sind mir nicht aufgefallen.
    Ich habe den alten Speicherstand noch weiter ausgebaut und er lädt einwandfrei.


    Auf jeden Fall ältere Savegames behalten, gerade bei der Verwendung von Mods bzw. wenn man neue Mods hinzufügt. Man weiß ja nie, was passiert. ;)

BlueBrixx