Seit dem neuen Update friert TPF2 regelmäßig ein. Hab die Steam-Version 35905 für Linux. Die Systemüberwachung zeigt an, dass der RAM-Verbrauch stetig anwächst, bis der gesamte 64 GB RAM plus die 32 GB Auslagerungsspeicher komplett aufgebraucht sind. Danach friert das OS (Linux Mint 21.3 Cinnamon mit Kernel 6.8.0.45 generic) ein und lässt sich nicht mehr bedienen. Ich vermute mal eine Wechselwirkung zwischen einer MOD mit der neuen Spielversion. Es deutet vieles auf die Fahrplan/TimeTable-Mod hin. Wenn ich die ausschalte, kann ich länger spielen ohne dass das Spiel komplett einfriert.
Ungewöhnlich hoher RAM-Verbrauch von TPF2 führt zum Absturz des Spiels / OS
-
- ungelöst
- MarkMcWire
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
-
MaikC
Hat das Label ungelöst hinzugefügt -
Ich hatte in dieser Hinsicht nie Probleme mit der Timetable-Mod. Wobei sie aber leider vor sich hindümpelt, und es inzwischen etliche Versionen gibt, von denen jede ihre individuellen Macken hat, und von den Autoren dieser an sich tollen Mod kaum noch was kommt.
Es wäre also erst einmal gut zu wissen, welche Version bei dir läuft. Klar dürfte auch sein, dass diese Mod relativ viele Daten hin- und herschaufelt. Kann von daher, gerade bei einer Riesenmap, auch ein quantitatives Problem sein. Mehr kann ich leider auch nicht dazu sagen, und zu Linux sowieso nicht. 
-
Definitiv ist zumindest für mich die LUA Runtime unter Linux etwas mehr anfällig wenn sol seine Pointer nicht im Griff hat.
Technisch sollte es keinen Unterschied geben zwischen Windows und Linux, aber die Compiler übersetzen den Code halt sehr unterschiedlich. GCCs Ergebnis ist auch bei jedem Build sehr unterschiedlich.
Die CPU Register Nutzung wird sehr stark optimiert, daher ist das Verhalten eines Mods sehr unterschiedlich von Build zu Build.
In "ea0530e9" haben wir das hier:
PANIC: unprotected error in call to Lua API (stack index 1, expected string, received sol.UI::Window*)
ist sehr ungewöhnlich.
Wenn etwas ein string sein soll aber ein sol.UI::Window ist muss etwas sehr falsch sein, da man in der Regel in eine Variable für string nicht für ein UI Element benutzt.
Auch wenn du sehr viele Daten durch die Gegend schaufelst, ist da wo ein string sein sollte nachher kein sol.UI::Window.
Die "Schaufel" ist ein Stück C++ Code und serialisiert dann bei jeden Frame die Game Script Daten und kann kein sol oder userdata...Wenn so etwas mit UI Elementen öfters vorkommt, würde ich sagen das der Teil mit UI ein Problem hat..
Der Fehler kann natürlich auch von einem früheren "Out of Memory" kommen und der LUA Stack ist schon kaputt.
Im Endeffekt heißt das:
Alle LUA->SpielAPIs anschauen. Nutzung von temporären nur auf dem Stack liegende Objekte vermeiden.
api.bla(api.blub.new()) vermeiden und daraus:local blub = api.blub.new()
api.bla(blub)
Und ja, ich nutze normalerweise Linux aber noch nie Timetables, daher hab ich keine Erfahrung mit den Mods...
-
Zitat
Wenn so etwas mit UI Elementen öfters vorkommt, würde ich sagen das der Teil mit UI ein Problem hat..
Die UI ist bei Timetables ohnehin ziemlich buggy. Aber damit muss man leben, wenn keine Bugfixes mehr kommen. Wahrscheinlich müsste der Teil ganz neu geschrieben werden, weil allein schon das Thread Management (zugegebenermaßen eine nicht ganz einfache Angelegenheit) mächtig knirscht. Aber ob das die Ursache von Speicherproblemen ist ...?
-
Im Endeffekt heißt das:
Alle LUA->SpielAPIs anschauen. Nutzung von temporären nur auf dem Stack liegende Objekte vermeiden.
api.bla(api.blub.new()) vermeiden und daraus:local blub = api.blub.new()
api.bla(blub)
Ich habe den Code dieser Mod entsprechend modifiziert. Löst natürlich nicht das zugrundeliegende Problem. Aber eine Änderung hat sich ergeben. Die RAM-Auslastung steigt nicht mehr linear mit der Spielzeit. Man hat einen RAM-Anstieg für einige Minuten, bis eine Art Plateau erreicht wird und erst wenn man das GUI für die Fahrpläne öffnet, fängt das Spiel wieder an neuen RAM zu belegen. Allerdings geht der Anstieg auch dann weiter wenn das GUI gleich wieder geschlossen ist.
Ich vermute mal, dass ein Problem im Code vorliegt, der bei kleinen Änderungen an den Fahrplänen oder dem öffnen des GUI neue Fahrplan-Instanzen für sämtliche Züge und Stationen erzeugt ohne die alten Instanzen zu löschen. So wird der Speicher nach und nach mit LUA-Objekt-Instanzen zugemüllt. Aber alleine schon das Vorhandensein dieser Mod im Spielstand erhöht die RAM-Auslastung von ca. 15 GB auf über 40 GB nach dem Laden des Spielstandes. -
In der Praxis kann man eigentlich sowas nur erzeugen, indem man entweder immer mehr neue Daten in eine Tabelle schreibt oder regelmäßig auf Daten zugreift, die man eigentlich nicht mehr braucht. Denn der alte Datenmüll würde ansonsten intern über eine Garbage Collection regelmäßig aus dem RAM gelöscht. Hast du das mal an die Autoren gemeldet? Könntest du deine Änderungen evtl. auch hier veröffentlichen? Mich z.B. würde das auch interessieren, da ich ebenfalls die Fahrplan-Mod benutze und meine, ebenfalls so ein Verhalten beobachtet zu haben.
Das sorglose Zumüllen von Ressourcen ist übrigens auch in der .sav.lua zu bemerken.
Wenn du z.B. Einträge löschst, bleiben sie hier trotzdem drin. Abgesehen davon, dass du bei Änderungen an der Anzahl der Haltestellen manuell Einträge verschieben musst, am besten auch direkt in der .sav.lua, weil die UI leider auch buggy ist und Tastatureingaben ignoriert. Aber das ist wieder ein anderes Thema. -
Du brauchst keine Zustimmung, der Code steht unter GPL3 (Dein neuer Code muss nur halt auch unter GPL3 stehen)
https://github.com/IncredibleH…bles/blob/develop/LICENSE
Es gibt ja auch genügend Forks, aktiv ist der hier:
-
Wenn ich es richtig sehe, hat sich da seit Monaten nichts mehr getan, nicht einmal Bugfixes. Schade für ein so bravourös gestartetes Projekt. Ja, ich sehe das auch so, man wird es komplett neu schreiben müssen. Vielleicht ist das der Nachteil des gitHub-Konzeptes: Du bist gezwungen, fremden Code, in den du dich mühsam einarbeiten musst, zu übernehmen, weiterzuentwickeln und vor allem zu pflegen. Das schafft Reibungsverluste.
Am besten wäre es gewesen, wenn UG selber die Fahrplan-Idee aufgegriffen hätte, naja, da werden wir wohl auf TpF3 warten müssen, wenn überhaupt. -
Also wenn du die Haupt Linien UI meinst, die ist sehr speziell.
CommonAPI2 nutzt die UG Linien UI und hab den Code dafür schon 3 mal neu gemacht, ich muss den Liniennamen suchen, damit ich die richtige Linie herausfinden konnte.
Grundsätzlich bindet UG keine Spezialelemente, bedeutet, du hast dann zwar ne Tabelle aber keine Funktion um herauszufinden welche Line der Nutzer gewählt hat.
Es kann sein das UG das mittlerweile geändert hat...
(Wegen der ständigen UI Änderungen hab ich ja meine UI Inspector geschrieben, damit kann man dann die UI zur Laufzeit erkunden)
-
Ich habe wohl keine Ahnung, aber Intuition habe ich.
Könnte es an diesem "alles muss in eine Sandbox, um Sicherheitslücken zu vermeiden" - Prinzip liegen, dass es viel einfacher ist, Code zu erzeugen, der Speicherlecks erzeugt, als Code ohne?
Nach dem Motto; jeder ausgebildete Programmierer weiß jetzt, wie am besten Speicherlecks zu erzeugen sind. Nach der Ausbildung muss dann noch erlernt werden, diese zu vermeiden ...
