*hüstel* ...mit ESC geht das auch? Ist mir bisher entgangen!
Build with Collision
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
-
-
Scheinbar crasht es nur wenn man das X drückt
Vielleicht mal unter Einstellungen das Tastaturlayout ändern.
-
Es ist das konstruktions X gemeint, nicht die Taste glaub ich xD
-
Das X oben rechts im Fenster ...
-
Es läuft ja wieder gut in Game aber nun habe ich CTD regelmäßig, vermutzlich mit dem Trotzdem Bauen Mod.
Wenn es asset über Wasser oder andere Objekte kommt erscheint ja der Button Trotzdem Bauen und zack. Bei Gleisen ist das nicht der Fall.
Eine Stdout für den Crash wird nicht angelegt, weil es richtig ein Hardcrash ist, also mit Programm reagiert nicht.
Wie kann ich dem mal folgen ob es dieser oder doch ein anderer Mod ist.
Vor der Korrektur der Standard.lua ist das nicht einmal passiert
-
Eine stdout wird immer angelegt, schau nochmal nach.
Welche Version von BwC hast du?
Wie kann ich dem mal folgen ob es dieser oder doch ein anderer Mod ist.
naja einfach mod deaktivieren und wieder testen?
-
OK, es ist wohl so wie hier beschrieben, wenn man das Baufenster schleißt also auf das X von Fensterschließen klickt und es hängt noch ein Objekt an der Maus, welches unter sich rote "hier kann ich nicht bauen " Objekte erzeugt dann crasht das.
Natürlich gibt es eine Stdout aber die ist ohne Crash .
Also hier oben wird das ja auch beschrieben.
Ich muß das erst wieder provozieren .
Die Version Deines Mods ist die neueste nach common API, 2023-02-11: v1.3
Ich benutze nicht die Beta von TpF2
Ohne Deinen Mod spiele ich das Spiel nicht
-
Ja genau. Ich habe bisher weder eine Erklärung noch eine Lösung dafür.
UG ist informiert. Keine Rückmeldung bisher. Ich weiß nicht ob das bis nächste Woche noch was wird.
Solange die v1.2 nutzen.
---> Build with Collision
-
Ich denke Dein Mod bekommt den Abbruch nicht mit und versucht Trotzdem Bauen mit einem nicht mehr ausgewählten also keinem Objekt durchzuführen.
Daher müßte man den klick abfangen können und zwar als vorclick Ereignis um den Button trotzdem bauen verschwinden zu lassen .
Im Grunde ist es ja egal, mit ESC kommt man klar, wenn man es weiß, aber die neue Version des neuen Upgardes, da geht der Mod gar nicht, sobald es unter dem Objekt rot wird der Button erscheint, CTD
Ich kann nur etwas C# da kann man natürlich leicht so ein VorKlick Ereignis abfangen...
Für mich ist es so ohne den Mod ist das Spiel nur ein Spiel und ist nach einer Karte langweilig
Vollzitat direkt unter dem Beitrag entfernt (eis_os)
-
Ne das Bauen kann ja nur durch den Klick auf den Button ausgelöst werden. Wenn man bei Collision aufs Terrain klickt, kann man soviel klicken wie man will, es passiert nichts.
Es wird auf eine Reihe von Events gehört, die andeuten, dass das Menü gewechselt oder ausgeblendet wird. Darauf hin soll der Button wieder entfernt werden. Das klappt in allen anderen Fällen wunderbar, nur bei dem X crasht es ohne Fehlermeldung.
-
na ja eben, Das X beendet die Auswahl entfernt also das Object, Dein Button bleibt aber. Somit, ich meine wenn es geht, das X auch zum beenden des Button verwenden.
Also ich bin da auch nicht der Richtige, ich hab keine Ahnung wie das Spiel da was bereit stellt. Vielleicht ein Windows Mouse down event auf dem X.
-
Also wenn du deinen Bugreport in Steam meinst, - Mutex Fehler bei destroy-, ich vermute das Du in einem onIrgendwas Handler versuchst ein UI Element zu löschen (destroy) oder ein schon gelöschtes Objekt zu entfernen.
UGs UI Code ist da zeitweise recht eigenartig und bei jeder zweiten Release verhält sich der Code etwas anders...
-
Danke für den Tipp, das kann sein, dass es zu schnell doppelt gelöscht wird.
Wobei ich eigentlich vor dem löschen natürlich folgendes checke:
Die Events auf die zum Ausblenden gehört wird sind:
Codeelseif (id=="menu.construction.railmenu" and name=="visibilityChange" and param==false) or (id=="menu.construction.roadmenu" and name=="visibilityChange" and param==false) or (id=="menu.construction.rail.tabs" and name=="tabWidget.currentChanged") or (id=="menu.construction.road.tabs" and name=="tabWidget.currentChanged") or (id=="menu.construction.terrain.tabs" and name=="tabWidget.currentChanged") or (id=="menu.construction" and name=="tabWidget.currentChanged") or (id=="menu.bulldozer" and name=="toggleButton.toggle")
sonst würde der Button noch dauerhaft angezeigt werden.
Es wird auch destroy aufgerufen wenn die collision im proposal wieder verschwindet. Aber auch hier wird direkt elem:destroy() aufgerufen, und nicht api.gui.util.destroyLater(elem) was nur beim onClick auf den Button benutzt werden muss. Ein Fehler wegen der gleichzeitigen Nutzung dieser 2 destroy Methoden kann es also auch nicht sein.
-
Mit dem Update gibts endlich mehr Fehlerinformationen, hatte ich vorher nicht selbst so bekommen:
Codeurban_games/train_fever/src/Lib/UI/Component.cpp:1819: void __cdecl UI::CComponent::RemoveChild(class UI::CComponent *): Assertion `!m_childMutex' failed.
Bringt mir das jetzt was....
Ich hab nachgeschaut, menu.construction tabWidget.currentChanged ist das einzige Event was passiert, sowohl bei X als auch mit ESC
Code
Alles anzeigenDestroy toolbutton guiHandleEvent: menu.construction tabWidget.currentChanged { id = "menu.construction.terrain", index = 4, } Destroy toolbutton guiHandleEvent: menu.construction tabWidget.currentChanged { index = -1, } urban_games/train_fever/src/Lib/UI/Component.cpp:1819: void __cdecl UI::CComponent::RemoveChild(class UI::CComponent *): Assertion `!m_childMutex' failed. 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: Lua exception This error is usually caused by modding. Some game resources contain incorrect data. Details: Error message: File name: C:/Program Files (x86)/Steam/userdata/382485722/1066780/local/staging_area/Build_with_collision_1/res/config/game_script/build_with_collision.lua Key: game/res/gameScript/build_with_collision.lua_guiHandleEvent Minidump: C:/Program Files (x86)/Steam/userdata/382485722/1066780/local/crash_dump/cbf09f22-6bf9-485a-95ad-50ec31542731.dmp UI Component Hierarchy: type: class UI::ToggleButton, id = "menu.construction.terrain", name = "ConstructionMenuIndicator", styleClasses = {} type: class UI::TabWidget, id = "menu.construction", name = "TabWidget", styleClasses = {} type: class UI::CComponent, id = "menu", name = "wrap", styleClasses = {} type: class UI::CComponent, id = "mainMenuTopBarBG", name = "wrap", styleClasses = {} type: class UI::CComponent, id = "", name = "UI_root", styleClasses = {} type: class UI::CComponent, id = "", name = "RendererComponent::Layer2", styleClasses = {} type: class UI::CRendererComponent, id = "mainView", name = "RendererComponent", styleClasses = {"action-constructionbuilder"} type: class UI::CGameUI, id = "", name = "CGameUI", styleClasses = {"top-gamebar-visible"} type: class UI::CMenuUI, id = "", name = "MenuUI", styleClasses = {} type: class UI::CComponent, id = "", name = "wrap", styleClasses = {"platform-desktop", "ui-classic", "input-mouse", "gamepad-type-xbox"}
-
Da UG ja anscheinend doch einiges umgebaut hat grad mit UI, schon mal die Idee gehabt das evt. die Logik von TPF2 bereits das Element an der Stelle schon gelöscht hat oder es trotzdem anschließend selbst versucht, selbst wenn du es schon sauber entfernt hast?
Hat UG eigentlich je bestätigt, dass der Aufruf von api.gui.util.getById tatsächlich verlässlich ist? Es gibt ja eigentlich ne extra Funktion api.gui.util.check zum prüfen, ob Componenten noch existieren, siehe dazu hier: https://transportfever2.com/wi…ponent:addLifeTimeChecker
Aber genau das ist es, was meine Mod aktuell hindert am Update ... der check ist nämlich aktuell leider kaputt in der bis jetzt verfügbaren Beta.
MFG PMV
-
api.gui.util.getById ist verlässlich. Entweder ist gibt das Element noch oder nicht mehr.
Das Problem liegt ggf. in Elementen die ne Id haben, aber in keinem Layout stecken, das mag UGs API gar nicht. Versucht man dann ein destroy gibt es meist eine Katastrophe...Das Element kann natürlich via destroyLater schon zum entfernen markiert sein..
PS: Das ein Element schon gelöscht wurde, hab ich oben schon geschrieben.
Der Lifetime Checker ist dafür da, wenn du ein Pointer zum Element hast und schauen musst ob es noch existiert...
-
Ich weis was du geschrieben hast, das hat ihm ja bisher nicht geholfen, also hab ichs noch mal anders formuliert. Wenn ich mir schon die Mühe mach den Code anzuschauen kann man ja auch mein Vorredner bestätigen. Lass dich von meinen Formulierungen nicht irritieren, du weist doch das ich nicht der beste bin wenns darum geht auszudrücken, was ich denke.
Im Code von VacuumTube wird explizit das Element vorher vom Layout entfernt, bevor er es dann löschen will. Wenn du das so schreibst, könnte das in diesem Fall das Problem sein und das Element darf vorher nicht vom Layout entfernt werden.
Die Frage, die sich mir stellt wäre auch nun, ob es überhaupt nötig ist selbst das Element sauber zu entfernen, oder ob UGs Logik nicht automatisch das Element selbst mit entfernen würde.
Ansonsten schreibst du nun einerseits, das api.gui.util.getById() verlässlich sei, anderseits vermutest du selbst, dass das Element beim anschließenden Aufruf von destroy() schon gelöscht wurde ... das passt nicht zusammen. Im zweitem Fall wäre es per Definition dann schlicht nicht verlässlich und es wäre eine andere verlässlichere Methode nötig.
MFG PMV
-
Es ist ein Unterschied ob du ein Element entfernst so:
- element holen per Id. element = api.gui.util.getById("irgendwat")
- element aus Layout entfernen, nun gehört das Element der Lua Runtime
- element:destroy()
oder
- element holen per Id oder erstellen
- element aus Layout entfernen, Lua gehört das Objekt
- Crash nun LUA oder element wird durch Runtime versucht zu entfernen
- später:- element holen per Id = api.gui.util.getById("irgendwat") (Element ist nicht an Layout gebunden)
- element:destroy() *Katastrophe* Crash
Beispiele für wenn ein Element schon gelöscht wurde aber man hat noch eine Lua Objekt (dafür gibt es das Connection Teil):
- element erstellt- element an Layout binden
- später:- parent von Element wird durch UG UI Code gelöscht, Element bekommt dann auch ein destroy als child. Aber Lua hält noch eine Referenz!
- später im UI Code mit LUA:
- element:destroy() ich bin fertig mit meiner UI, *Katastrophe*
Auch darf man niemals ein Layout in ein Layout packen. Das mag UGs Code auch nicht.
Ich bin der Meinung das die letzte Windows Build mehr UI Crashes in Line Destination produziert.Der selbe Code läuft gerade eigentlich unter Linux stabil... (und das ist eigentlich komisch, bis jetzt war Linux immer sehr anfällig für soetwas) keine Ahnung was los ist. Vielleicht ist da doch mehr Kaputt... (Bei mir crasht es aber beim beenden des Spiels )
-
Auch darf man niemals ein Layout in ein Layout packen.
Genau das habe ich aber gesehen beim mainButtonsLayout
UG hat mir ein Beispiel geschickt mit setMouseListener. Sieht so aus, als wäre build with collision sogar ohne umwege möglich. Muss ich mir morgen genauer anschauen.
-
Zitat
Sieht so aus, als wäre build with collision sogar ohne umwege möglich.
Sag bloß, der MouseListener wäre nur wegen BwC reingekommen. Das wäre sensationell, kann ich nur hoffen, dass es klappt.