Vermutung, dass Speicherleck die Spielstand-Datei (game save) vergrößert

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


    Mein Spielstand wird auch größer nach dem Abreißen von vielen Assets 4

    1. Ja (3) 75%
    2. Nein (1) 25%

    Es sind nur Indizien, basierend auf Symptomen, die ich beobachtet habe.


    Ja, es kann™ an Mods liegen - diese jedoch basieren auf dem API. Und das ist "core game".


    Auf einer Hauptstrecke hatte ich vor einiger Zeit eine Menge "retaining wall assets" platziert, da die Trasse am steilen Hang entlang verläuft.

    Es waren hunderte dieser Assets, weil ich viele kurze nehmen musste, wegen Kurven und Gefälle (die Assets sind statisch, nicht neigbar).


    Nun hatte ich was anderes mit der Trasse vor und musste erstmal alle Assets löschen. Davor hatte ich gespeichert.

    Das Spiel war im Pausemodus.

    Nachdem ich hunderte von (gleichen) Assets entfernt hatte, habe ich wieder gespeichert.

    Der Spielstand war mehrere MB größer.

    1. da Spiel hat eindeutig ein Speicherleck, schau auf den RAM-Verbrauch nach mehreren Stunden, speichere, beende, lade. RAM-Verbrauch ist deutlich weniger.
    2. aber:lasse das Spiel im Pausemodus mehrere Stunden offen, bis der RAM-Verbrauch wieder deutlich höher ist. Speichere. Schau nach dem Größenunterschied der Spielstanddatei.


    Es ist nicht so eindeutig, dass es in den Augen blendet. Es ist aber auch nicht von der Hand zu weisen. Da rumort ein Speicherleck.

    Keine Ahnung was du genau machst ich spiele derzeit sehr groß 1:2 mit 378 Mods, die Karte ist gut bebaut, hat einiges an Einwohner und ich liege nach dem frischen alden bei 10,4GB Ram und nach ca. 4h gerade mal bei 11,6GB also rund 12GB wenn ich mal nett bin.

    auch mein Savegame wird nicht abartig groß. nach mittlerweile 96h Spielstunden auf der Karte ist die Karte von 32MB am Anfang komplett leer jetzt bei 35,6MB

    also ich finde das recht normal.

    Die Größe der Spielstand-Datei ist schlecht optimiert. Ich habe den Eindruck, egal was man macht, sie wird größer.


    Zitat von KarlCharlson

    ach mittlerweile 96h Spielstunden auf der Karte ist die Karte von 32MB am Anfang komplett leer jetzt bei 35,6MB

    Also irgendwas scheine ich falsch zu machen. Auf meiner mittleren Karte sind es 1850 41MB. 1950 sind es 90MB und 2020 161MB.



    Aber der Vergleich mit dem RAM hinkt. Der sollte ja nicht ins Savegame mitreinspielen.

    Der RAM Verbrauch von TPF ändert sich ja ständig. Einmal woanders hingescrollt, schon werden neue Daten reingeladen.

    Ein Durchlauf eines Jahres sollte den Speichernutzung wieder reduzieren.

    Nicht Savegame relevant, aber ich bin seit 10 Tagen die CommonAPI2 am durchforsten warum es mit UG Code zu einem Speicherleck kommt. Ergebnis, ich hab ein winziges Stackproblem in der UG Konsole gefunden das nicht CommonAPI2 relevant ist ;(

    Das Spiel basiert auf der C++-SDL, unter anderem Listen. Da ständiges Anfordern und Freigeben von Speicher ineffizient ist, wird Speicher nicht frei gegeben sondern nur die Verkettung der Liste geändert und das entfernte Listenelemente in eine Liste leerer Elemente eingefügt. Wenn die komplette Liste in das Save geschrieben wird, dann erklärt es auch das Verhalten nach dem Löschen von Elementen. Erst wenn genug leere Elemente bereit stehen, ändert sich gegebenenfalls der Umfang einer Liste. Das Verhalten optimiert den Zugriffsoperator auf eine linear Laufzeit und optimiert auch Suchanfragen in der Liste.

    Zitat von Marcolino26

    Wenn du viel änderst muss auch mehr gespeichert werden ;)

    War das ironisch gemeint? Denn wenn ich was entferne, was ich selbst früher gebaut hatte, sollte der Spielstand nach Adam Riese und Eva Zwerg kleiner werden.


    Zitat von VacuumTube

    Einmal woanders hingescrollt, schon werden neue Daten reingeladen.

    Schon klar. Aber wenn man wieder wegscrollt und da verweilt (Bauabschnitt), könnten diese Daten auch wieder freigegeben werden.

    Technisch jein. TPF2 nutzt für die jede ecs::Component Typ ein lineares std_vector.

    TPF(2) speichert für jede Entity eine Liste(kann man in Debug Tools sehen) mit type id -> index in das std_vector des types.


    Darüber hinaus kann TPF2 nun auch noch Revisionen eines Entity speichern.


    Bitte bedenkt, ich schaue da von außen drauf. Also nein, es nicht einfach ein linked list... (Inwiefern TPF2 ein std_vector aufräumt, keine Ahnung)

    Es gibt API Aufrufe die Logs zurück gibt aus der Vergangenheit. Hier werden sämtlich ein und Ausgaben geloggt. Schon mal jemand überprüft, ob diese einfach nur immer länger werden? Genau so könnte das mit anderen Daten sein. Das jede Aktion ein SaveGame dann größer werden lässt ist nur logisch.


    Das Problem von eis_os ist dagegen ein anderes Thema. ?(


    MFG PMV

    Genau, die ganzen Finanzen, die Diagramme für die Stationen brauchen Daten aus der Vergangenheit. Trotzdem sollte mit dem Löschen von Objekten die Dateigröße auch wieder kleiner werden können.


    Den Punkt, dass nicht nur der Jetzt-Zustand, sondern alle Änderungen gespeichert werden, hatte ich mal beim (wenig optimierten) Terrain vermutet. Womöglich werden da alle Terra Veränderungen überlagert gespeichert.


    Ich habe ja nach 100h eine Erhöhung um 290% und benutze öfter mal das Terrain-Angleichen-Werkzeug. Interessant wäre, wie das bei anderen mit geringer Änderung ist, z.B. KarlCharlson mit nur 11%.

BlueBrixx