Modding-Tools für die NLT

[Hendrik]

In der Hoffnung, dass hier noch viel folgen möge, habe ich gleich mal einen neuen Faden angefangen. Um es kurz zu machen: Hiermit veröffentliche ich die Alpha-Version meines NLT-Universal-Packers. Wie bereits beim Dosbox-Patch gibt es den Quellcode und eine vorkompilierte Binary für Windows-User.

Das Programm läuft auf der Kommandozeile und hat bisher nur wenige Optionen. Man kann für alle drei Teile der NLT (hoffentlich ) die Archive anschauen, entpacken und wieder einpacken. Der Haken dabei: Neu gepackte DSA3-Archive (.ALF) funktionieren derzeit nicht im Spiel. Den Packer für die dsagen.dat reiche ich ebenfalls später nach.

Ich werde demnächst den Quellcode auch ins Repository einpflegen und mich auf der Developerseite über die Archivformate und meine Arbeit auslassen. Und natürlich den Packer verbessern.

Zur Bedienung:
Das Tool kann mit

Code:

nltpack Modus Archiv Optionen

gestartet werden. Dabei ist Modus entweder "l" (das ist ein kleines "L") für das Auflisten der Dateien im Archiv, "x" für das Entpacken und "c" für das Erstellen eines neuen Archives. Archiv ist einfach der Name der Archivdatei. Der Packer erkennt am Dateinamen, um welches Archivformat es sich handelt.

An Optionen gibt es derzeit nicht viel. Für das Erstellen eines Archives folgt an dieser Stelle die Liste der zu packenden Dateien. Im Moment müssen diese Dateien im aktuellen Verzeichnis liegen. Beim Auflisten und Entpacken kann man mit -p Pattern ein Suchmuster Pattern angeben, so dass nur die diesem Muster entsprechenden Dateien berücksichtigt werden. Pattern funktioniert dabei wie die bekannten Wildcards: Ein Fragezeichen (?) steht für einen beliebigen Buchstaben, ein Sternchen (*) für eine beliebige Buchstabenfolge.

Besonderheiten zu den einzelnen Archivformaten
- Die schick.dat/blade.dat hat eine feste Liste von Dateien. Fehlt beim Packen eine dieser Dateien, kann nltpack das Archiv nicht anlegen und bricht ab.
- Für DSA2-Archive gehört zu jeder .DAT eine .FN, die im gleichen Verzeichnis liegen und das gleiche Präfix haben muss (also z.B. STAR.DAT --> STAR.FN).
- Über die Schwierigkeiten mit DSA3-Archiven werde ich mich noch im Developer-Tagebuch auslassen.

Ich hoffe, das das Tool nützlich ist und hier bald die ersten Mods auftauchen

[Rabenaas]

Hey, danke! Das wird gleich mal ausprobiert.
Jetzt kann ich hoffentlich mit meinem "Möglichst wenig Platz"-Projekt weiter machen.

[Obi-Wahn]

Na, dann freu ich mich schon auf die Sources, das wird natürlich auch unter Linux ausprobiert.

[Borbaradwurm]

Man kann für alle drei Teile der NLT (hoffentlich ) die Archive anschauen, entpacken und wieder einpacken.

Dir fehlt das INTRODAT.VOL/INTRODAT.DIR-Archiveformat. Frag aber nicht wie man INTRODAT.DIR wieder so zusammenpackt das es vom Introprogramm akzeptiert wird.

[Rabenaas]

Wie entpackt man eine ALF-Datei?

Bei mir hat's bislang nicht geklappt, und bevor ich ggf. unnötig gdb anschmeiße, frage ich lieber noch mal nach.

[Hendrik]

Dir fehlt das INTRODAT.VOL/INTRODAT.DIR-Archiveformat. Frag aber nicht wie man INTRODAT.DIR wieder so zusammenpackt das es vom Introprogramm akzeptiert wird.

Danke für den Hinweis. Da ich das Intro schon auswendig kenne, starte ich die Schicksalsklinge immer gleich über die SCHICKM.EXE und habe daher gar nicht mehr an die Introdaten gedacht.

Wie entpackt man eine ALF-Datei?

Bei mir hat's bislang nicht geklappt, und bevor ich ggf. unnötig gdb anschmeiße, frage ich lieber noch mal nach.

Für die RIVA.ALF reicht beispielsweise:

Code:

nltpack x riva.alf

Das Resultat sind eine Reihe Verzeichnisse, deren Namen den Modulnamen entsprechen, und die alle Dateien in diesem Modul enthalten.

[Rabenaas]

Für die RIVA.ALF reicht beispielsweise:

Code:

nltpack x riva.alf

Das Resultat sind eine Reihe Verzeichnisse, deren Namen den Modulnamen entsprechen, und die alle Dateien in diesem Modul enthalten.

Ich habe das mal mit riva.alf probiert. Mein PC ist eigentlich nicht langsam, aber es dauert Minuten, bis "Creating Module Directory" erscheint. Bei spex.alf habe ich nach ein paar Minuten ziemlich oft denselben Zeichensalat bekommen (Einzelheiten per PM). Bei riva.alf warte ich noch auf ein Ergebnis.
Ich glaube, da hat sich noch ein Bug verschanzt. (Ich benutze übrigens Linux. Vllt. hängt das mit den Systemfunktionen zusammen?)

[Boneman]

Bei mir unter XP geht's ganz flott.

[Obi-Wahn]

Bei mir gehts unter Linux auch ganz flott.

Code:

obi@dhcppc0:~/Documents/dsa/nltpack-alpha1> ./nltpack x riva.ALF
Creating module directory MODULEFIGHT
Creating module directory MODULESPELL
Creating module directory MODULEGEN
Creating module directory MODULEFIANIS
Creating module directory MODULEFIFX
Creating module directory MODULECHARAC
Creating module directory MODULEOPTION
Creating module directory MODULEFINAL
Creating module directory MODULETOWER
Creating module directory MODULESEWERAG
Creating module directory MODULEFISPEEC
Creating module directory MODULECHEST
Creating module directory MODULEFISCEN
Creating module directory MODULECMASK
Creating module directory MODULEMASK
Creating module directory MODULEITEM
Creating module directory MODULESHOP
Creating module directory MODULEBORON
Creating module directory MODULEALCHEMY
Creating module directory MODULEDIARY
Creating module directory MODULEDISKMEN
Creating module directory MODULEDOOR
Creating module directory MODULEHEALER
Creating module directory MODULEIMPORT
Creating module directory MODULEINN
Creating module directory MODULECITY
Creating module directory MODULETEXT
Creating module directory MODULEPOPUP
Creating module directory MODULEDIALOG
Creating module directory MODULESMITH
Creating module directory MODULETAVERN
Creating module directory MODULETEMPLE
Creating module directory MODULETIME
Creating module directory MODULEUSE
Creating module directory MODULEBROTHEL
Creating module directory MODULEGLOBAL
Creating module directory MODULEITEMDIS
Creating module directory MODULELOCATIO
Creating module directory MODULEMARKETH
Creating module directory MODULECASTLE
Creating module directory MODULEMINE
Creating module directory MODULEAUTOMAP
Creating module directory MODULEPANEL
Creating module directory MODULECHAPTER
Creating module directory MODULEFEATURE
Creating module directory MODULEANIMATI
Creating module directory MODULEDUNGEON
Creating module directory MODULESTAR
Creating module directory MODULESHIP
Creating module directory MODULEMOSAIC
Creating module directory MODULEBATH
Creating module directory MODULENPC
Creating module directory MODULEENVIRON
Creating module directory PATCHDUMMIES
Creating module directory MODULESTREET
Tobias@dhcppc0:~/Documents/dsa/nltpack-alpha1>

Edit: Wie man sieht, gibts da den Ordner MODULEAUTOMAP und da sind Dateien mit der Endung *.AIF enthalten. Zum Beispiel "RI_MAP.AIF". Hat jemand ne Ahnung was für eine Datei-Endung das ist? Oder wie man die entpacken könnte? Ich hab nur ein Audio-Format namens *aif(f) gefunden, und Audio ist ja vermutlich im Map-Order eher nicht zu finden.

[Boneman]

Bei mir unter XP geht's ganz flott.

Oder sagen wir so: Die DUNGEON.ALF zu extrahieren, ging ganz flott. Gerade versuche ich es mit der SCHICK.DAT und da dauert es auch ewig bis irgendeine Meldung erscheint. Im Verzeichnis sind aber sofort 307 extrahierte Dateien vorhanden.
Dafür frisst das Programm anscheinend meinen Festplattenspeicher. Gerade waren noch ein paar GB frei und jetzt will Windows alte Daten löschen. Ich seh auch schon den Grund dafür: Die Datei FX18.VOC hat so um die 2,5 GB (zum Zeitpunkt, an dem ich das Programm abgebrochen hatte). Vielleicht sollte Rabenaas mal seinen freien Festplattenspeicher prüfen.

[Rabenaas]

Ok, meine speziellen Probleme kommen vielleicht daher, dass ich ein 64bit-Linux benutze. Wenn ich die vorkompilierte nltpack.exe mit wine verwende, dann ist die Situation genau so, wie von Bones beschrieben (ALF funktioniert, DAT macht noch Probleme).
Meine selbst kompilierte Version schafft bei genauerer Betrachtung weder noch.
(Wird in ALF eigentlich little- oder big-endian bei Zahlen verwendet?)

Vielleicht wäre ein Sanity-Check der Header-Daten sinnvoll, solange low-level I/O nicht überall funktioniert?

[HenneNWH]

Hey Hendrik,

klasse Sache das mit dem Entpacker.
Ich hatte genau dieselben Probleme wie Rabenaas, aber das sind wirklich _nur_ 64bit Geschichten welche sicher leicht behoben werden können.

Jetzt bin ich grad unter 32bit und teste ein bissl rum....

...bei Riva hat alles ausser die RIVA.ALF aus der Demoversion:

nltpack: nltpack.cpp:277: virtual bool Header_DSA3::read(std::istream&): Assertion `entry != 0' failed.

Btw, Bei Schweif funktioniert NLTpack auch in der 64bit Version. Ich habe da auch schon viele _alte Bekannte_ aus Schick gefunden

An Schick hab ichs noch gar nicht getestet.

Jetzt brauchen wir nur noch jemanden, der sich mit 3D Modellen auskennt.

[Borbaradwurm]

Dumme Frage: Wo hab ihr denn den Sourcecode von nltpack her?

Jetzt brauchen wir nur noch jemanden, der sich mit 3D Modellen auskennt.

Aus aktuellen Anlass, so geht 3D Format Reverse Engineering:
http://events.ccc.de/congress/2008/Fahrp...42.de.html
http://events.ccc.de/congress/2008/wiki/...Recordings
... muss ich mir auch noch ansehen :]

[Rabenaas]

Wo hab ihr denn den Sourcecode von nltpack her?

Siehe 1. Beitrag in diesem Thread.

[HenneNWH]

Der Sourcecode ist aus dem Anhang aus Beitrag 1 dieses Threads.

Danke für die Links Schön das es mal nichts zum lesen, sondern was zum hören ist.
Das werd ich mir morgen in aller Ruhe mal anhören.

[Borbaradwurm]

Der Sourcecode ist aus dem Anhang aus Beitrag 1 dieses Threads.

Hm da war er aber als ich das zum ersten mal runtergeladen habe noch nicht.

Ich hab nltpack zwar selber noch nicht auspropiert aber ich habe es schon mal kompiliert
Erstens hier mal ein besseres Makefile (zumindest für Linux/gnu make/g++):

Code:

CXX=g++
CXX_CFLAGS=-W -Wall -Wextra -pedantic
CXX_LFLAGS=
.PHONY:clean
CMD_RM=rm -rf

nltpack_OBJ=nltpack.o fileutils.o
nltpack:$(nltpack_OBJ)
        $(CXX) $(nltpack_OBJ) -o $@ $(CXX_LFLAGS)

%.o:%.cpp
        $(CXX) -c $< -o $@ $(CXX_CFLAGS)

clean:
        $(CMD_RM) *.o nltpack

Zweitens: was mir damit aufgefallen ist: wenn du Variablen vergleichst solltest du dafür sorgen das du für deine lokalen Variablen den richtigen Datentyp verwendest (Wertebereich bei signed vs. unsigned, das könnte auch an dem x GB Fehler schuld sein).

[HenneNWH]

Hm, bei mir klappt zwar das kompilieren mit dem Makefile, aber es wird nicht gelinkt.
Scheint so, als wäre $(nltpack_OBJ) leer.

[Borbaradwurm]

Mein Fehler, versuchs nochmal, da war ein typo im meinem Post: da muss natürlich "nltpack_OBJ=nltpack.o fileutils.o" und nicht "nltpack_OBJ:nltpack.o fileutils.o" stehen. Ab jetzt werden auch noch so kurze Texte durch die Katze gejagt...

[HenneNWH]

Danke, jetzt klappts

[Hendrik]

Gerade versuche ich es mit der SCHICK.DAT und da dauert es auch ewig bis irgendeine Meldung erscheint. Im Verzeichnis sind aber sofort 307 extrahierte Dateien vorhanden.
Dafür frisst das Programm anscheinend meinen Festplattenspeicher. Gerade waren noch ein paar GB frei und jetzt will Windows alte Daten löschen. Ich seh auch schon den Grund dafür: Die Datei FX18.VOC hat so um die 2,5 GB (zum Zeitpunkt, an dem ich das Programm abgebrochen hatte). Vielleicht sollte Rabenaas mal seinen freien Festplattenspeicher prüfen.

Das dürfte an der 308. und letzten Datei im Archiv liegen, der OUTRO.XMI, die ein ungültiges Offset hat und daher ignoriert werden muss. Wird sie es nicht, versucht NLTPACK astronomische Mengen an Bytes zu kopieren, die gar nicht da sind. Das wird in der kommenden Version behoben.