Neuer Fehler: Assertion failure
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
-
-
den fehler hat ich auch schon. gesucht und gesucht, aber nichts gefunden.
-
Moin, könntet ihr bitte auch noch die in der Fehlermeldung angegebenen .dmp-Dateien hochladen? Da drin könnte evtl mehr zu Ursache zu finden sein.
-
Die Fehlermeldung hatte ich auch mal als ich beim bearbeiten eines Freestyle Bahnhofs zu schnell den Bahnhof wieder angewählt habe nachdem ich ausersehen das Bearbeiten Menü mit Esc geschlossen hab.
-
Hier der Crash Dump.
Bei mir ist es aktuell noch nicht nachvollziehbar. Ich bewege mich über die Map, während der Verkehr rollt, bis irgendwann der Absturz passiert. Mein Verdacht liegt mal wieder auf dem Verhalten eines Fahrzeugs. Ich hatte so etwas schon mal bei landenden Flugzeugen (da war es ein Mod-Flughafen) und bei einem bestimmten PKW.
Ich vermute aktuell eine Bahn oder einen Bahnhof, kann aber total daneben liegen. Vor allem weil da bis dato nichts Probleme machte.
-
Hat jemand anhand der stdout und der dmp Files vielleicht noch eine Idee? Ist ein echt nerviger Fehler und das Spiel dadurch komplett instabil.
-
Ja, dass ist die Mod NAB von steam vielleicht fehlt ein Segment beim Bau, Brücke nicht geschlossen oder so.
Roter Kasten ist die Mod.
-
Dank Dir!
Komisch ist nur, dass ich diese Mod gar nicht abonniert habe. 🤔 -
Komisch ist nur, dass ich diese Mod gar nicht abonniert habe.
Vielleicht hattest Du diese mal Abonniert, entladen und vergessen

-
Hm...nein. Ich sah in Steam nach, im Modverzeichnis und im spielinternen Modmanager.
Zudem ist die Nummer im Screenshot achtstellig. Die Modnummern hingegen sind zehnstellig.
-
Ok, hab mir gerade mal angeschaut.
- Es ist Tpf2, schätze mal das ist ein Fehler, dass es in Tpf1 gelandet ist? @Mods könnt ihr den Thread bitte an den richtigen Ort verschieben?
- Bei dem Vergleich in der Assertion in der Fehlermeldung wird, so wie ich das verstehe, von der Lua-API auf eine Speicherstelle zugegriffen, die eigentlich nicht zum dem Array (wahrscheinlich components, "it" steht vermutlich für iterator) gehört.
- Das ganze findet in einem Extra-Thread, nicht dem Haupt-thread des Spiels statt. Aufgrund der Nr 69 des Threads gehe ich mal davon aus, dass die problematische Mod sehr gerne neue Threads erstellt. Wenn man in dem Code der von dir installierten Mods nach Mods die Threads erstellen sucht, kann man die Menge der zu verdächtigenden Mods evtl eingrenzen.
- Außerdem solltest du im Code auch nach dem in der Fehlermeldung angezeigten Code-Schnipsel it != components.end() suchen. Evtl ist das ja nur bei 1 oder 2 Mods enthalten.
Auszug aus dem Beginn des dumps:
Code
Alles anzeigenOperating system: Windows NT 10.0.26100 CPU: amd64 family 25 model 97 stepping 2 16 CPUs Crash reason: EXCEPTION_NONCONTINUABLE_EXCEPTION Crash address: 0x0000000000000000 Crashing instruction: `cmp qword [rdi + 0x18], 0x0` Memory accessed by instruction: 0. Address: 0x0000002fa02fee78 Size: 8 Process uptime: 2202 seconds Thread 69 (crashed) 0 TransportFever2.exe + 0x26aee9e rax = 0x0000002fa02fe8b0 rdx = 0x0000002fa02fee60 rcx = 0x0000002fa02fe8b0 rbx = 0x0000000000000027 rsi = 0x000001f276818ed0 rdi = 0x0000002fa02fee60 rbp = 0x0000002fa02feea0 rsp = 0x0000002fa02fe7d0 r8 = 0x00000000000004d0 r9 = 0x0000000000000000 r10 = 0x000001ec71b60000 r11 = 0x0000002fa02fe8b0 r12 = 0x00007ff766bd2150 r13 = 0x00007ff7657b834c r14 = 0x0000002fa02ff080 r15 = 0x0000000000000000 rip = 0x00007ff764f4ee9e Found by: given as instruction pointer in context 1 ntdll.dll + 0x1be85 rbp = 0x0000002fa02feea0 rsp = 0x0000002fa02fe7f0 rip = 0x00007ffb2a5dbe86 Found by: stack scanning ....Ich hab mal bei mir in den Mods gesucht, it != components.end() ist bei allen von mir abonnierten oder heruntergeladenen Mods nur in Freestyle Stations enthalten. https://steamcommunity.com/wor…iledetails/?id=2363493916
-
-
Wow! Vielen Dank!! Sehr hilfreich und tatsächlich: Die Freestyle Stations müsste ich auch installiert haben. Ansonsten suche ich auch mal verzeichnisweit nach dem Eintrag.
Danke auch für den Hinweis aufs Verschieben. Da wählte ich wohl versehentlich TPF1 aus.
*EDIT* Ok, besagte Mod habe ich nicht installiert. Und eine verzeichnisweite Suche sowohl im lokalen Modverzeichnis, als auch im Workshop-Verzeichnis lieferte kein Ergebnis. 🤔
Zu merkwürdig. -
Das ist ausgeschlossen. Mit welchem tool hast du gesucht? Ich habe ripgrep benutzt. Mit den 2 Befehlen rg 'it != components.end()' mods und rg 'it != components.end()' 1066780. Das es wahrscheinlich nicht Freestyle Stations ist, habe ich schon wegen dem 69. Thread vermutet. Dass F. S. so viele Threads aufmacht, ist mir nicht bekannt.
-
Ich suchte per Explorer und Notepad++- "ripgreg" kenne ich gar nicht, versuche es aber gerne mal auch damit.
Auffällig jedenfalls ist, dass die Abstürze nur passieren, wenn ich das Spiel vom "Pause" Modus in den "Play" Modus umschalte. Nach einer gewissen Weile kommt dann der Absturz. Daher tippe ich auf ein Fahrzeug oder eine Station, die den Absturz verursacht, sobald sie angefahren wird. Wüsste jetzt aber von keiner neuen, die ich setzte und das Problem verursachen könnte. Die, die ich zuletzt platzierte, "liefen" bisher ohne Absturz. Von daher tippe ich auf ein Fahrzeug und versuche mal eben, die zuletzt verwendeten zu entfernen. Aber auch die sind von mir schon einige Male problemlos verwendet worden. 🤔
-
Es ist sinnvoll es auch mit ripgrep versuchen, da ich weiß wie die Volltextsuche von dem Tool funktioniert, was ich ja auch schon getestet habe. Außerdem ist ripgrep extrem schnell, Explorer verglichen mit ripgrep nicht einmal eine Schnecke.
Auffällig jedenfalls ist, dass die Abstürze nur passieren, wenn ich das Spiel vom "Pause" Modus in den "Play" Modus umschalte.
Das triggert dann wohl die Race Condition in der Mod die zum Use-After-free führt.
Ich würde eher auf eine Skript-mod tippen. Außer es gibt Fahrzeuge mit Lua-Code, der permanent in einer Schleife ausgeführt wird.
-
Kann es sein, dass Du das unter Linux nutzt? Kein Plan, wie ich das unter Windows zum Laufen bekommen soll.
Muss ich dafür vielleicht noch erst "Git for Windows" installieren und weitere Plugins? So jedenfalls, mit der Version von Github, kann ich irgendwie nichts anfangen. -
Ja, ich nutzte Linux. Aber ich nutze das Tool (und viele andere) genauso auch unter Windows. Scheinbar hatte ich beim Post-Kreieren den Downlad-Link zu ripgrep vergessen anzugeben. Du solltest auf Github ripgrep-14.1.1-x86_64-pc-windows-msvc.zip herunterladen können, die zip-Datei entpacken und dann direkt mit der enthaltenen rg.exec <argumente> loslegen können. Das Programm in the PATH packen, etc. macht nur Sinn wenn du es regelmäßig benutzen möchtest.
-
Ja, genau die Version zog ich mir inzwischen und ließ sie über die Powershell laufen.
Ich durchsuchte damit jetzt (zusätzlich mit dem Parameter "-i") das lokale Modverzeichnis sowie das von Steam, aber fand nichts, das dem gesuchten Argument entspricht.
So werden halt nur Einträge gefunden, die einen Teil des Arguments beinhalten, so wie das hier: -
Kann es sein, dass du die Single Quotes weggelassen hast? Mein Befehl war rg 'it != components.end()' <optional Ordnername in dem gesucht werden soll, sonst ab hier überall>. Wenn Powershell Single Quotes nicht macht, woran ich mich nicht erinnern kann, dann probiere es doch bitte einmal mit Double Quotes: rg "it != components.end()" <optional Ordnername in dem gesucht werden soll, sonst ab hier überall>
-
Wie schon so oft geschrieben, das ist das Spiel, das sagt, beim Zugriff fehlt eine Komponente, sprich ein ecs::component::* Du wirst ne Zeile "it != components.end()" nie in LUA finden. LUA funktioniert nicht im Prinzip wie STL C++ Containern...
Haben wir aber auch im Lexikon:
stdout.txt - Erklärung & typische Fehlermeldungen
Und natürlich passiert das wenn man die Simulation wieder startet, dann werden alle noch "aufgestauten" Befehle abgearbeitet...
Weitere Informationen wie Entity ist 0 ist auch nicht hilfreich, das ist die World Entity
Vom ecs::component Type wäre es ein Asset, aber das passt halt nicht zu einer World Entity, da diese nie eine Asset Komponente hat.
Code
Alles anzeigenACCOUNT = 0, AIRCRAFT = 1, ANIMAL = 2, ASSET_GROUP = 3, ASSET_GROUP_AUTOREMOVE = 4, AUDIO_EMITTER = 73, BASE_EDGE = 5, BASE_EDGE_STREET = 6, BASE_EDGE_TRACK = 7, BASE_NODE = 8, BASE_NODE_TRAFFIC_LIGHT = 9, BASE_PARALLEL_STRIP = 10, BOUNDING_VOLUME = 56, BRIDGE = 76, BUILD_COST = 11, COLLIDER_LIST = 12, COLOR = 64, CONSTRUCTION = 13, EMISSION_GRID = 14, FIELD = 57, GAME_SPEED = 15, GAME_TIME = 16, LINE = 65, LOG_BOOK = 74, LOT_LIST = 17, MAINTENANCE_COST = 18, MODEL_INSTANCE_LIST = 58, MODEL_PERSON = 19, MOVE_PATH = 66, MOVE_PATH_AIRCRAFT = 20, NAME = 63, PARCEL = 71, PARTICLE_SYSTEM = 72, PERSON_CAPACITY = 47, PLAYER = 21, PLAYER_OWNED = 75, RAILROAD_CROSSING = 22, RAIL_VEHICLE = 68, ROAD_VEHICLE = 67, RUNWAY_LIST = 23, SCAFFOLD = 48, SHAPE_LIST = 24, SHIP = 25, SIGNAL_LIST = 26, SIM_BUILDING = 27, SIM_CARGO = 29, SIM_CARGO_AT_TERMINAL = 38, SIM_ENTITY_AT_BUILDING = 30, SIM_ENTITY_AT_STOCK = 31, SIM_ENTITY_AT_TERMINAL = 32, SIM_ENTITY_AT_VEHICLE = 33, SIM_ENTITY_IDLE = 34, SIM_ENTITY_MOVING = 35, SIM_PERSON = 28, SIM_PERSON_AT_TERMINAL = 36, SIM_PERSON_AT_VEHICLE = 37, STATION = 59, STATION_GROUP = 60, STOCK_LIST = 39, TERRAIN = 40, TERRAIN_ALIGNMENT_LIST = 41, TERRAIN_TILE = 42, TERRAIN_TILE_BRUSH = 43, TERRAIN_TILE_HEIGHTMAP = 44, TICK_EPOCH = 45, TOWN = 46, TOWN_BUILDING = 49, TOWN_CONNECTION = 61, TP_NET_LINK = 50, TRAIN = 69, TRANSPORT_HISTORY = 51, TRANSPORT_NETWORK = 52, TRANSPORT_VEHICLE = 70, VEHICLE_DEPOT = 62, VEHICLE_ORDER = 53, WATER_MESH = 54, WORLD = 55