Train Fever Savegame Format

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


  • Hallo


    Wegen des Nordic DLCs musste ich mal wieder in der EXE Datei herum wühlen da man die FileFilter nicht ändern kann.


    TF Savegames sind "heute" zwei mal mit LZ4 komprimiert.
    http://code.google.com/p/lz4/ (Ist mittlerweile auf Github, ich nutze noch eine alte Version, lz4.exe sollte die Daten verarbeiten können)


    Um ein Savegame zu laden müssen diese auch wieder doppelt komprimiert werden!
    Die Header Daten+Config Dict scheinen keine Checksumme zu haben, das restlichen Daten wohl aber!


    Header 4 Bytes: tf**, danach Savegame Version.
    Strings werden als Dword Länge + Char*länge ohne terminierende Null gespeichert = <tfstring>
    Beispiel: 0x04 0x00 0x00 0x00 Test



    Header Daten

    • ?
    • Mod Strings <dword> <tfstring>
    • Mod Liste <dword Einträge>

      • <dword ?> <tfstring>


    Config Dict: <dword Einträge>

    • Eintrag: <tfstring key> <tfstring value>

      • fileFilters: werden an LUA setActiveFileFilter weitergereicht beim Laden

    Modell Liste:

    • Einträge der Modelle, die Array Position eines Eintrags darf sich nicht ändern, neue Einträge werden hinzugefügt.
    • Es wird kein Alt-Eintrag gelöscht, dies würde das Savegame unbrauchbar machen! TF referenziert sehr viel mit einen einfachen Array Index
    • <dword refCount?> <tfstring>



    Eine Grobe (und sehr alte Übersicht der Daten der Release Version)
    http://www.bytetransfer.de/projects/tf/TFSavegameParts.txt

  • Hallo



    Wer mag kann sich ein Build meines Savegame Codec herunterladen, es entpackt, zerlegt und kann auch wieder Savegames komprimieren.
    Zurzeit leider nur die ersten Headerdaten....


    Code
    Usage: tfsavcodec <options> file
     -x            extract file
     -c directory  compress directory
     -v            verbose
     -vv           extra verbose
     --forcedir    force reusage of dir


    VORSICHT: ES IST UNGETESTETE SOFTWARE, NUTZUNG AUF EIGENE GEFAHR!


    www.bytetransfer.de/projects/tf/tfsavcodec_2016_03_06.zip


    Wer ein Nordic Savegame reparieren möchte bezüglich FileFilter muss die settings.json auswechseln, d.h. von einem funktionierenden sprich neuem Savegame nutzen und das alte wieder mit -c komprimieren...



    PS: Ich hab das Posting mit der Struktur geändert (sprich es wird nun als std::vector definiert)

  • Es wäre toll, wenn man die Koordinaten der Städte aus dem Savegame extrahieren könnte.
    Dann könnte man mit AutoHotkey viele Savegames mit unterschiedlichen Seeds erzeugen und anschließend die Savegames auf die Platzierung der Städte hin untersuchen.
    Das wäre insbesondere für selbst erstellte Karten sehr praktisch.


    Denkt ihr, das ist möglich?

  • Hallo


    Theoretisch ja, praktisch nein. Da ein TrainFever Savegame keinen Index hat, - man stellt sich das einfach mal als Buch ohne Seitenzahlen vor -, dann wird das heraussuchen von Daten recht schwer. Wer mag kann ja einfach mal versuchen die Rest Daten zu Entschlüssen. TFSavegamePart.txt (siehe oben) sind das Ergebnis einer Analyse der Debugdaten der ersten Linux Version, genauer gesagt die Calls zu den Subroutinen der Savegame Ladefunktion. Damit hat man aber leider noch keine Größe der Datenblöcke.


    Tipp: Die nächsten Daten sind vermutlich die Größe der Heightmap bzw. Kartendaten.


    Ob sich die Arbeit lohnt ist dann noch eine andere Frage, zwar ist Urban Games recht offen, aber ich werde Sie wohl nicht dazu bewegen können den Quellcode zu veröffentlichen. Dann wäre das gar kein Problem.


    -edit-
    Das Interesse scheint außerdem sowieso nicht sehr hoch

  • Muss das Thema mal abonnieren, sonst geht die Hälfte unter :D


    Hab grad mal geguckt. Die Ortsnamen sind derart weit hinten im Savegame gespeichert. Es ist also sehr schwer da überhaupt ranzukommen. D.h die Daten zu finden bedeutet, man muss alles vorher entschlüsseln / parsen, da man nicht weiß ab wo diese anfangen (gibt keine Sprungmarken etc.)

  • Zu den Städtenamen, diese sind in der Mitte der Städtestruktur.


    Das ist dann wie immer: <dword count> <stadtDaten> * count
    Aber damit hast Du immer noch keinen Offset dorthin.
    Man wird Sie wohl per Hex Editor ändern können. (die Länge muss dann eventuell auch angepasst werden)


    Wie gesagt das ist alles fieser C++ Code in mehrere Lagen. Die eigentlichen Teile haben keinen Header um die Größe anzugeben, man muss das also wirklich alles lesen um die Struktur zu erhalten...


    Eine Lösung, die ich aus Zeitmangel aber nicht umsetzen kann:
    Dem Linux Binary eine eigene libstdc++.so.6 per LD_LIBRARY_PATH unterjubeln.
    libstdc++.so.6 dann bei jedem Read Call eine Debugausgabe machen lassen mit der (Stream/File)Position, TF starten, Debugger dran klemmen und dann bei jedem Subcall einen Breakpoint, dann hat man erst mal die groben Größen

BlueBrixx