.DSC (Textdatei):

Ganz wichtig, um an die Namen der Animationstexturen zu kommen, und die Auflösung eines Frames.
Nur damit kann man korrekt die entsprechende .PIX parsen.
Animierte Objekte habe ich implementiert, was fehlt sind noch "bewegte" Objekte. Diese haben nur die Felder Höhe und Speed, aus denen ich noch nicht schlau wurde. Muss man mal mit dem Spiel abgleichen. Außerdem sind noch manche Animationen (Zwergenbinge wo die Orks am Esstisch schlafen) kaputt, da muss man noch forschen.

.3DM (3D Modelle und Texturierung im Binärformat)

Objektheader:

Größe Inhalt
int     Name als String-Verweis (siehe String-Tabelle)
short Anzahl der Vertices im Objekt
short Anzahl der Faces im Objekt
short NEU: Anzahl der Vertex-UV Mappings.
short NEU: Anzahl der Zeichenaufträge
short ??? noch unbekannt, oft Anzahl der Vertex-UV Mappings oder etwas größer, aber selten auch kleiner
short NEU:  Anzahl der (Materialgruppen?). Ich weiß noch nicht, was da genau steht.
int Bounding-Box: X-Komponente des Mittelpunkts
int Bounding-Box: Y-Komponente des Mittelpunkts
int Bounding-Box: Z-Komponente des Mittelpunkts
int NEU:  Distanz vom Mittelpunkt zu den Ecken, dh. eine halbe Diagonale
int Bounding-Box: X-Komponente des 1. Punktes
...
int Offset für die Faces
int GEÄNDERT: Offset für UV Mappings
int GEÄNDERT: Offset für Zeichenaufträge
...

"Die unbekannten Integer-Einträge in der Mitte des Blocks könnten vermutlich Platzierungsinformationen darstellen. So hätte jedes Objekt ein eigenes Koordinatensystem, unter dem es seine Vertices speichert, und einen Wert in Form von Weltkoordinaten in der Karte. Dies ist aber bisher nur eine Vermutung." - Stimmt also nicht. Alle Koordinaten in den Objektdaten sind immer Weltkoordinaten.

Unbekannter Datenblock:

Weiterhin unbekannt. Meine Vermutung ist, dass jeder 88 Byte Eintrag, (der nicht komplett aus Nullen besteht), mit einem Int beginnt, der einen String-Index darstellt. Der Wert liegt nämlich fast immer in dem Bereich. Außerdem könnte manchmal auch das letzte Byte ein String-Index sein (aber deutlich seltener). Die Mitte ist mir vollkommen unbekannt. Vermutung aus der Vermutung: Könnte "Weltveränderungen" wie Objekt1 verschwindet bei Event 1, Objekt3 ersetzt Objekt2 bei Event2, Objekt4 bewegt sich um X,Y,Z bei Event3, etc. darstellen. Außerdem fehlen noch die Positionen der Lichtquellen, die irgendwo kodiert sein müssen. Könnte natürlich auch direkt im Material stehen.
Der vierte Wert "Meistens 0x0000, aber manchmal 0x1000 (nur bei sichtbaren Objekten)" ist auch manchmal 0x1000 bei nicht-sichtbaren Objekten.

Objektdaten:
1. Erstmal Vertices (wie im Wiki mit XYZ Weltkoordinaten). Größe: Anzahl der Verticesim Objekt * 12 Byte

2. Dann Faces. Größe: Anzahl der Faces im Objekt * 12 Byte. Wahrscheinlich Normalen. Habe ich bisher nicht benutzt.

3. Dann eine Liste von Vertices auf UV Mappings. Auf diese wird im nächsten Block verwiesen. Größe: 16Bytes * Anzahl der Mappings. Aufbau: short VertexIndex, short IrgendeineGruppierung(War ein Red Herring), signed int U, signed int V
U und V muss man durch 256 teilen um zu Pixelkoordinaten zu kommen (vom Ursprung rechts unten), und nochmal um 256 für Koordianten zwischen 0 und 1. Das erste Byte würde also 1/256el Pixel zählen, was irgendwie komisch ist, aber wahrscheinlich so ist. Vielleicht steckt hier aber noch eine weitere Info drin, (was auch komisch wäre, weil dann U V 12 Bit lang wären). U V Koordinaten können übrigends oft auch negativ sein! Die Texturen werden standardmäßig alle "gewrapped"

4. Jetzt kommen die Zeichenaufträge:
Die fangen zB. so an: [0, 4, 0, 0, 1, 0, 2, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 3, 0, 0, 0, 0, 0, 0, 0]
Habe das Pattern erst ganz spät entdeckt (siehe der Red Herring oben, dem hatte ich erst diese Bedeutung gegeben), aber das ist eine fixed-length Liste von Indices. Genauer gesagt zeigen diese auf verschiedene UV-Mappings. Hier soll ein 4-seitiges Polygon aus den UVMappings 0,1,2,3 gemalt werden. Das Material steht danach. Genauer: Länge: 48 Byte * Anzahl der Zeichenaufträge. Aufbau: Byte Unbekannt(oft 0 oder 16), Byte Anzahl der Elemente im folgenden Array, 15 Shorts: Jeweils ein Short für eine UVMappingIndex. (Am Ende steht komischerweise eine redundante Kopie der Indices..), es folgen 8 unbekannte Bytes, dann ein Int als Offset (in die Datei) auf das verwendete Material. Dann schließlich noch 4 unbekannte Bytes.

5. Jetzt kommen komische Materialgruppen: Größe: Anzahl Materialgruppen * 12 Byte. Int WohlIrgendeineAnzahl, int Materialoffset (vom Dateianfang), dann (vermutlich) ein Offset auf die UV-Mappings(vom UV-Mapping Offset), könnte aber (jetzt wo ich drüber nachdenke) ein Zeiger auf jede 16 Byte große Struktur sein. UV-Mappings hatten irgendwie wenig Sinn ergeben..

.PIX

Wichtig ist das 24. Byte. Dessen Wert + 40 ergibt den Start der Texturdaten. Dann width * height Byte Texturdaten (Referenz auf Pallette), immer 256*256, außer bei den Animationen. Bei denen sollte man vorher die Height und Width aus der .DSC kennen, um so die Frameanzahl (aus der Gesamtgröße - Header - Footer) und schließlich die Breite der Gesamttextur (Width * Frameanzahl). Animationsframes sind nämlich immer nebeneinander platziert. Der Footer ist immer 8 Bytes lang und genullt.

.PAL

Hier ist das  24. Byte + 41 interessant. Hier startet die Palette aus RGB0 byte Quadrupel. Das letzte Byte ist immer 0.
Wobei, wo ich das schreibe, wahrscheinlich startet es bei 24. Byte + 40 (wie .PIX) und es sind 0RGB Quadrupel.

So, das wars. Sollte man wirklich noch mal übersichtlich ins Wiki übertragen. xD

1,6,21
2
3,30
4,25
5,23
6,1
7,32
8,33
9,28
21,1,22
22,21,23,24
23,22,24,5
24,25,26,23,22
25,4,24,26
26,27,25,24
27,28,29,8,26
28,9,29,27
29,30,31,28,27
30,3,31,29
31,30,32,29,32,33
32,7,33,31
33,8,32,31