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


    Zitat von VacuumTube

    Scheinbar crasht es nur wenn man das X drückt

    Vielleicht mal unter Einstellungen das Tastaturlayout ändern.

    MfG elektronikfreak


    MB MSI MPG Z790 Edge WIFI - i7-14700K - Nvidia GeForce RTX 4080 Founders Edition 16GB - 192 Gb DDR5 Ram - 5x 2TB M.2 - Win11/64 - WsK - 60TB Ext. - TPF2 35732

    (Meine Screenshots dürfen weiter verwendet werden) - (Fixiert auf Berliner Mod's)

    VacuumTube

    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

    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 ;-)

    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:

    Code
    local elem = api.gui.util.getById(tb.id)
if elem then
...


    Die Events auf die zum Ausblenden gehört wird sind:

    Code
    elseif (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:

    Code
    urban_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

    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 :/ )

    Zitat von eis_os

    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.

BlueBrixx