Fatal Error: Assertion Failure: Assertion failed

Willkommen in der Transport Fever Community

Welcome to the fan community of Transport Fever and Train Fever, the economic simulators of Urban Games. The community is free for you to share and inform yourself about the game. We cultivate a friendly and objective interaction with each other and our team will be happy to answer any questions you may have.

 

Registration and use is of course free for you.

 

We wish you a lot of fun and hope for active participation.

The Team of the Transport-Fever Community

  • Hallo zusammen,


    vielleicht habt ihr eine Idee. Ich habe ein Savegame, welches seit 02/2020 existiert und eigentlich bis vor kurzen bis auf die Performance fehlerfrei lief. Vor ein paar Wochen fing es an, dass wenn ich über die Karte gehe, dass dann plötzlich das Spiel mit dem Fehler "Assertion Failure: Assertion `src.numComp == dst.numComp || (va == 2 && src.numComp == 3 && dst.numComp == 4)' failed." abstürzt. Festgestellt habe ich es nach einer Stunde Bauen udn dann beim Überflug über andere ältere Stellen, als plötzlich dieser Fehler auftrat.


    Der Fehler ist reproduzierbar und war vor dem Update mit der Stable Build 35049 bereits existent. Mit dem Update besteht das Problem weiterhin. Das Mod-Set habe ich mit einer neuen freiem Spiel getestet, da tritt der Fehler nicht auf.


    Hat jemand Ideen, wo dieser Fehler herkommen könnte oder kennt jemand diesen Fehler eventuell? Die stdout ist zum hochladen zu groß, gibt aber auch keine Informationen zu einer Mod preis.



    Hier einmal der ganze Auszug:


    urban_games/train_fever/src/Lib/renderer/model/StaticBuffer.cpp:106: void __cdecl `anonymous-namespace'::Transform(const class ITechnique *,const struct CMat4f &,const struct Mesh *,int,class std::vector<struct `anonymous namespace'::MaterialBuffer,class std::allocator<struct `anonymous namespace'::MaterialBuffer> > &,float): Assertion `src.numComp == dst.numComp || (va == 2 && src.numComp == 3 && dst.numComp == 4)' failed.

    Attempting to write crash save to "crash_Leipzig-2023-03_2023-03-11_13-02-13"

    available disk space: 104352 MB

    [2023-03-11 13:02:13] Saving to file D:/Programme/Steam/userdata/72851213/1066780/local/save/crash_Leipzig-2023-03_2023-03-11_13-02-13.sav

    Saving...: 20960.6 ms

    Additional info extracted from the previous state:

    GC Called

    Destroying failback ui done

    Uncaught exception while in class UI::CSelector

    End of redirect Buffer to StdOutBuffer

    Restoring as we are still responsible for stdout

    End of redirect Buffer to StdOutBuffer: done

    Exception type: Fatal error

    Details:

    Assertion Failure: Assertion `src.numComp == dst.numComp || (va == 2 && src.numComp == 3 && dst.numComp == 4)' failed.

    Minidump: D:/Programme/Steam/userdata/72851213/1066780/local/crash_dump/f1c2b4b4-edc2-4da3-ae73-742ffab7c8ef.dmp

    In file: urban_games/train_fever/src/Lib/renderer/model/StaticBuffer.cpp:106

    In function: void __cdecl `anonymous-namespace'::Transform(const class ITechnique *,const struct CMat4f &,const struct Mesh *,int,class std::vector<struct `anonymous namespace'::MaterialBuffer,class std::allocator<struct `anonymous namespace'::MaterialBuffer> > &,float)

    __CRASHDB_CRASH__ struct AssertException: urban_games/train_fever/src/Lib/renderer/model/StaticBuffer.cpp:106: void __cdecl `anonymous-namespace'::Transform(const class ITechnique *,const struct CMat4f &,const struct Mesh *,int,class std::vector<struct `anonymous namespace'::MaterialBuffer,class std::allocator<struct `anonymous namespace'::MaterialBuffer> > &,float): Assertion `src.numComp == dst.numComp || (va == 2 && src.numComp == 3 && dst.numComp == 4)' failed.

    Exception type: Fatal error

    Details:

    Assertion Failure: Assertion `src.numComp == dst.numComp || (va == 2 && src.numComp == 3 && dst.numComp == 4)' failed.

    Minidump: D:/Programme/Steam/userdata/72851213/1066780/local/crash_dump/f1c2b4b4-edc2-4da3-ae73-742ffab7c8ef.dmp

    In file: urban_games/train_fever/src/Lib/renderer/model/StaticBuffer.cpp:106

    In function: void __cdecl `anonymous-namespace'::Transform(const class ITechnique *,const struct CMat4f &,const struct Mesh *,int,class std::vector<struct `anonymous namespace'::MaterialBuffer,class std::allocator<struct `anonymous namespace'::MaterialBuffer> > &,float)

    Goodbye.

  • Moin!


    Ich denke, ich habe mein Problem gelößt. Hoffe ich mal. :S

    Im Steam-Workshop unter 'Durchsuchen' -> 'Abonnierte Objekte' gabe es zwei nicht richtig deabonnierte Mods (Mods die von Steam, wegen Illegal, gelöscht wurden) und zwei gleiche Bahnhofs-Mods (Bahnhof Liège-Guillemins Version 1 und Version1.2).

    Die eigendlich geglaubten deabonnierten Mods, habe ich noch mal unter 'Abonnierte Objekte' deabonniert und den Bahnhof (beide Versionen) ebenfalls deabonniert.

    Der erste Savegame-Testlauf sah schon mal gut aus. Keine Abstürze im Bereich rundum den Bahnhof.

    Auch bei einer anderen Karte (Savegame) keine Abstürze.

    Ich hoffe wirklich, nach drei Tagen suche, das die Abstürze nicht mehr auftauchen. Wenn noch, spiele ich nur doch Brettspiele. ^^

  • const struct Mesh *,int,class std::vector<struct `anonymous namespace'::MaterialBuffer,

    Oder irgendwas mit einem Mesh und den zugeordneten materials? Leider kein Hinweis auf den Verursacher.

  • Im Hauptmenü, CommonAPI2 crashdebug anschalten. (Vorsicht stdout.log Datei wird sehr sehr groß, 500MB sind keine Seltenheit),

    Sehr nah Reinzommen, so wenig Ausschnitt wie möglich, sogar im Fenster Modus laufen lassen und das Fenster stark verkleinern) und sich auf die Crashstelle hin bewegen.


    Die Idee dahinter:

    Seit dem Update lädt TPF2 Meshes und Texturen während des Spiels nach.

    CommonAPI2 schreibt alle Dateizugriffe ins log mit Crashdebug.
    Wenn man also nur einen kleinen Ausschnitt hat, wird TPF2 da die gerade sichtbaren Teile nachladen. (Mods sind nicht im Zip gepackt, sprich man hat Dateinamen)

    Dies sollte dazu führen, das die letzten Dateien wahrscheinlich dazu führen das TPF2 Probleme bekommt.

  • Da der Assert String in StaticBuffer::Add ist, wäre ich versucht zu sagen, das es auch bei OpenGL auftritt, und ja es kann auch ein Mesh sein.

    Wenn ich in CommonAPI2 alles bis auf Render Static abschalte, bleiben eigentlich nur noch Straßen, Teile von Schienen (unterbau) und Vegetation (Sprich Büsche, Steine und co) übrig.

    Ok, ne Bahnstation zeigt mir je nach Kamerawinkel auch noch was, scheinen Gleise zu sein


    Also bei Vegetation, Büsche anfangen, dann Straßenmods abschalten, wieder versuchen usw.


    PS: Aber ohne Mithilfe deinerseits, sprich Mods testweise abzuschalten wird es nicht gehen...


  • Hallo zusammen,

    sorry für die späte Rückmeldung, aber da die Ladezeiten halt lang sind, fehlt mir hin und wieder die Zeit. Ich starte jetzt mal mit aktivierten CrashDebug den Spielstand. Werde die Hinweise und Tipps durchgehen. Melde mich wieder, wenn ich weitere Erkenntnisse habe.

  • Der erste Test ist erfolgt mit aktivierten CrashDebug und Logging-Level 99 in der CommonAPI. Stdout-Datei ist 250 MB groß (Link)


    Die Typische Meldung kommt wegen Materialien und Bodentexturen, die fehlen:


    Auffällig ist folgender Eintrag in der stdout.txt, wobei ich nicht weiß, ob das nicht sogar normal ist, der sehr häufig am Ende 1000x wiederholend auftritt:


    Code
    Opening file: res/scripts/serialize.lua

    Während des nahen Überflugs ist kein Fehler aufgetreten, erst, als ich dann herausgezoomt habe nach ganz oben und mich dann bewegt habe, tritt der Fehler aus. Er trat noch nicht auf, als ich noch etwas tiefer mit der Kamera-Ansicht war.

    Ende der stdout.txt:


    Ich habe den Überflug einmal zur Verdeutlichung aufgenommen und zu Youtube hochgeladen, wird allerdings gerade noch von Youtube verarbeitet.

    Grafikeinstellungen:



    OpenGL wurde auch bereits getestet. Gleiches verhalten vom Spiel.


    Links:
    Video: https://www.youtube.com/watch?v=ZmJWL2KFrR8

    Dump und stdout.txt Download: https://drive.google.com/drive…13BxzUZrDJ?usp=share_link


    Die Mods prüfen wäre dann der nächste Step. Bei 1348 Mods mühsehlig. Da brauch ich etwas Zeit zu.

    Kann das denn noch immer eine Mod oder Mesh sein, wenn es offensichtlich nur von ganz oben abstürzt?

  • Wenn man schaut was so als letzte Texturen geladen wurden, würde diese Mods mal abschalten:


    staging_area/mz_markierung_1

    steam_1942103484_1

    siri_ekz_2

    wk_tramtrack_texture_changer_1


    Sprich, das mittendrin ist die Fehlermeldung.

    Die serialize calls kommen daher, da TPF2 unbedingt noch ein crash Savegame herstellen möchte...

    (Frag mich aber was leichteres warum ständig serialize neu geladen werden muss von der Platte)

BlueBrixx