Earthproject Forum

Wenn wir eine Möglichkeit hätten die WD-Archive vom Orginalspiel zu lesen, könnten wir die Spieldaten direkt aus dem Orginalspiel holen (naja, das Mesh Format usw. brauchen wir auch noch, aber da ist Surrim wohl schon recht weit).

Ich habe mich mal bisschen ran gesetzt, um das Format zu verstehen, kam aber nicht sehr weit.

Was ich bisher rausgefunden habe:

Die ersten 10 Bytes sind wohl immer die selben:
0x78 0x9C 0xFB 0xBF 0xF0 0x82 0x61 0xB8 0x0B 0x03

Dann folgt eine GUID in einer Länge von 39 Bytes.

Ab Offset 0x31 scheint dann der Inhalt anzufangen, wobei hier alles komprimiert wird, also sowohl die Verzeichnisstruktur als auch die Daten selbst.
Ab hier wird es damit auch kompliziert womit ich momentan nicht weiter komme.

Würde dir der WD-Entpacker bei deinem Problem helfen?

Notfalls verzichtet man erst mal auf die WD Files und nutzt die Daten entpackt.
Earth kommt damit auch klar.

Das WD Pack Programm nutze ich schon.

Surrim kennt sich damit besser aus, wird wohl daran weiter arbeiten.

EDT: Sieht so aus, als wäre ich noch nicht ganz fertig. Habe bisher nur eigene, mit WDPacker erstellte Dateien und ein paar Originaldateien("Textures.wd" & mehr) getestet. Mein Programm scheint aber mit "Update22.wd" Schwierigkeiten zu haben. Habe in einem Moon-C Dokumentation gelesen, das man Dateien auch unkomprimiert in einem WD speichern kann. Das könnte sowas in der Art sein. Mal sehen, was ich machen kann.

Hey Trayshar.
Muss erst mal sagen: Cool das du dich da ran gesetzt hast!

Ich habe eben angefangen ein kleines Programm zu schreiben, welches deiner Dokumentation folgt und den ersten Header entpackt.
Funktioniert soweit und ich kann deine Angaben über die 8 "immer gleichen Bytes" sowie de UUID über alle .wd Dateien bestätigen, die in The Moon Project enthalten sind.

Was mir aber noch nicht so ganz zu sagt ist der "2te Header". Ich sehe da das Problem, diesen zu finden.
Du hast beschrieben, dass man diesen anhand der zlib Header Bytes erkennen kann und damit suchen soll.
Das funktioniert zwar bestimmt, aber da gibt es mit großer Wahrscheinlichkeit eine bessere Lösung.

Hast du mal geschaut, ob es irgendwo in der Datei (vermutlich direkt nach dem ersten Header?) einen Integer gibt, der den Offset
des zweiten Headers angibt? Das wäre dann viel zuverlässiger, als diesen selbst zu suchen und mögliche false positives zu umgehen.

Als Erstes: Ich glaube jetzt, das Format vollständig verstanden zu haben. Mein kleines Programm liest jetzt alles, was ich an wd - Dateien im Originalspiel finden konnte, und entpackt es auch.

Um den Fehler zusammenzufassen: Die "erste Dokumentation" war recht unvollständig. Ich habe geschrieben, das nach dem String im Index immer dasselbe Byte 0x01 steht. Das ist falsch, den dieses Byte gibt an, wie die Datei komprimiert wurde und was für zusätzliche Daten sie enthalten soll. Es gibt 12 dieser Modi, die meisten treten nur 1 - 3 mal in allen Dateien auf. Alles steht zusammengefasst im neuen Doc.

Zitat

. Die Checksumme am Ende ist aus dem unkomprimierten Inhalt berechnet wurden. Heißt: Einfach solange von unten nach oben lesen, Daten entpacken und Checksummen vergleichen, bis man eine Übereinstimmung hat. Hat in meinem Programm funktioniert.


Noch kurz zu meinem Programm: Ich habe das mal ein bisschen speichoptimierender geschrieben, braucht nicht mehr als 100 Mb Ram auf meinem PC. Wenn man ein Log mit allem drumundran(Zeitstempel, Gelesene Dateien, komprimierte Größe usw. ) lesen will, muss man es aber über die Kommandozeile ausführen. Sonst reicht ein Doppelklick. Vielleicht mache ich auch mal eine ausführliche GUI.