Modding-Tools für die NLT

[Hendrik]

Und hier ist sie, die neue Version. Die folgenden Punkte haben sich im Vergleich zur Vorversion geändert (grob nach Wichtigkeit geordnet):

• Es wird auf die Endianness des bei der Kompilation zugrundeliegenden Systems geprüft. Leider konnte ich diesen Schritt mangels 64bit-System nicht testen, hoffe aber, dass es nun auch auf x86_64-Systemen ohne Anpassung läuft.
  
• Für jedes Archiv wird nun eine Master-Datei benötigt, die noch einmal alle enthaltenen Dateien auflistet. Dieser Schritt liegt vor allem in meinen neuen Erkenntnissen zum DSA3-Archivformat begründet, dass in den Archiven von DSA3 nicht die Dateinamen, sondern die Reihenfolge zum Auffinden benutzt werden.
  Die Master-Datei muss das gleiche Präfix wie die Archivdatei haben und .FN als Suffix (SCHICK.DAT --> SCHICK.FN, RIVA.ALF --> RIVA.FN, u.s.w.). Außerdem müssen beide Dateien im gleichen Verzeichnis liegen.
  
• Da passende Master-Dateien nur für DSA2 beiliegen, müssen sie für DSA1- und DSA3-Archive erst erzeugt werden. Dies geschieht mit dem neuen "m"-Modus. Mittels
  
  Code:

  nltpack m DATA/RIVA.ALF
  wird beispielsweise die Masterdatei DATA/RIVA.FN für das Archiv RIVA.ALF erzeugt.
  
• Es werden nun auch DSA3-Archive voll unterstützt, d.h. es können Riva-Archive gepackt werden.
  
• Die DSAGEN.DAT aus DSA1 wird unterstützt. Die INTRODAT.DIR/INTRODAT.VOl werden weiterhin nicht unterstützt, das kommt in der nächsten Version.
  

[Rabenaas]

Hallo Hendrik,

nltpack V0.2 hat den Test SCHICK.DAT- und STAR.DAT-Test jetzt mit Bravour bestanden.

Leider zickt RIVA.ALF unter Linux x86_64 immer noch rum. Die nltpack.exe mit wine schafft aber auch das.

[HenneNWH]

Cool, neues Testzeugs.

Der 64bit Fehler ist leider immer noch. Mir ist bei DSA3::read() aufgefallen, dass die ausgelesenen Offsets astronomisch gros sind.

(gdb) print filetable_offset
$5 = 211809915700875863
(gdb) print data_offset
$6 = 211528440703090736
(gdb) print moduletable_offset
$8 = 18155131723965591

Ich denke daran könnte es liegen.

EDIT: BINGO! filetable_offset auf meinem 32-Bitter ist 21074519. Das stimmt schon eher.

EDIT2: Ändere bitte in fileutils.cpp in read32() "u32 c;" in "32 c=0;" dann klappts.

[Rabenaas]

Ja, mit HenneNWHs "u32 c = 0;" klappt's bei mir auch. Super!
(Könnte mir mal jemand den Unterschied zu vorher erklären?)

Damit kann auch unter 64bit alles entpackt werden.

[Hendrik]

EDIT2: Ändere bitte in fileutils.cpp in read32() "u32 c;" in "32 c=0;" dann klappts.

So was blödes, dass ich darauf nicht gekommen bin! Ein dickes Lob geht an HenneNWH und Rabenaas für die schnelle Rückmeldung und vor allem für das Beheben des Fehlers.

[Rabenaas]

Wie steht es eigentlich um das Verpacken von Dateien? Klappt es schon, eine alf zu entpacken und wieder verpacken? (Komme gerade nicht dazu, es einfach auszuprobieren.)

[Hendrik]

Siehe hier:

• Es werden nun auch DSA3-Archive voll unterstützt, d.h. es können Riva-Archive gepackt werden.
  

Man kann ein Riva-Archiv auspacken, wieder einpacken und das Spiel läuft ohne Probleme (zumindest habe ich bis jetzt keine festgestellt). Bei Sternenschweif habe ich auch schon ein wenig rumexperimentiert (Schick-Midis statt der originalen).

Edit: Was den Programmierfehler angeht: das u32 (=long int) wird vom C++-Compiler intern als Wort in Registerbreite gespeichert, ein u32 hat also auf einem 32-Bit-System 32 Bit, auf einen 64-Bit-System 64 Bit. Ich habe es vorher uninitialisiert verwendet, deshalb stand in c eine beliebige Zahl drin. Der code in read32 hat nur die niederwertigen 32 Bit verändernt, die höherwertigen blieben erhalten und haben das Ergebnis verfälscht. Durch das Initialisieren von c mit 0 verschwindet dieser Fehler.

[Rabenaas]

Wie packt man eine Datei?

Ich versuche gerade seqs.alf zu packen, mache aber irgend etwas falsch.

Code:

> nltpack c seqs.ALF
Running on little-endian system
File MODULEVAMPIRE/VAMPIRE.AAF is missing, archive creation impossible.

Die Datei MODULEVAMPIRE/VAMPIRE.AAF ist aber eigentlich vorhanden.

[Rabenaas]

Mit dem (etwas merkwürdigen) Befehl

Code:

nltpack c seqs.ALF -p MOD*/* MOD*1/*

hat es geklappt.

[modron]

Interessant, dann kann man demnächst mit Modifikationen rechnen?!

[Rabenaas]

Hi Modron

Naja, das hängt davon ab, was Du unter demnächst verstehst. Ich glaube, dass das gesammelte Wissen über die NLT in Kombination mit dem Packer zumindest für eine kleine Mod reicht. Bislang hat sich aber noch keiner konkret rangetraut. Du kannst ja den Anfang machen...

[Hendrik]

Mit dem (etwas merkwürdigen) Befehl

Code:

nltpack c seqs.ALF -p MOD*/* MOD*1/*

hat es geklappt.

Hmm, eigentlich sollte das hier reichen:

Code:

nltpack c seqs.ALF MOD*/*

Das Pattern (-p) wird eigentlich nicht benötigt, da bei Fehlen vom allgemeinsten Pattern "*" ausgegangen wird.

[Rabenaas]

Das Pattern (-p) wird eigentlich nicht benötigt, da bei Fehlen vom allgemeinsten Pattern "*" ausgegangen wird.

Das ist die intuitive Lösung, die ich denn auch zuerst ausprobiert habe...

Anscheinend globt "*" bei mir weder '/' noch '1'. Deswegen reicht das standardmäßige "*" alleine nicht. Komisch.

[Hendrik]

Wie bereits versprochen, habe ich mich an diesem Wochenende mal wieder an das Packtool gesetzt und ein paar Fehler behoben bzw. Erweiterungen gemacht.

Am wichtigsten ist wohl, dass es jetzt auch unter 64-Bit-Systemen läuft (bzw. laufen sollte - ich habe die Korrektur von HenneNWH eingebaut, habe aber keine Testumgebung hier). Außerdem werden nun auch die INTRODAT-Archive von Schicksalsklinge unterstützt.

Wie üblich stelle ich hier ein Zip-Archiv mit dem Quellcode und einer vorkompilierten Windows-Binary hoch. Außerdem habe ich den Packer in das SVN eingepflegt (svn://zwischenwelt.org/freedsa/trunk/modding/nltpack), damit auch andere an der Entwicklung mitarbeiten können.

[Obi-Wahn]

Leider läuft da noch irgendwas falsch, .. oder mach ich was falsch? Ist introdat.dir überhaupt die richtige Datei?

Code:

obi@dhcppc3:~/Documents/dsa/nltpack-beta1/introdat-schick> ./nltpack m introdat.dir
Running on little-endian system
obi@dhcppc3:~/Documents/dsa/nltpack-beta1/introdat-schick> ./nltpack x introdat.dir
Running on little-endian system
Fehler beim Lesen des Volumes introdat.VOL
Fehler beim Lesen des Volumes introdat.VOL
Fehler beim Lesen des Volumes introdat.VOL
Fehler beim Lesen des Volumes introdat.VOL
....

[Borbaradwurm]

Leider läuft da noch irgendwas falsch, .. oder mach ich was falsch? Ist introdat.dir überhaupt die richtige Datei?

Code:

obi@dhcppc3:~/Documents/dsa/nltpack-beta1/introdat-schick> ./nltpack m introdat.dir
Running on little-endian system
obi@dhcppc3:~/Documents/dsa/nltpack-beta1/introdat-schick> ./nltpack x introdat.dir
Running on little-endian system
Fehler beim Lesen des Volumes introdat.VOL
Fehler beim Lesen des Volumes introdat.VOL
Fehler beim Lesen des Volumes introdat.VOL
Fehler beim Lesen des Volumes introdat.VOL
....

Ich denke du brauchst INTRODAT.VOL und INTRODAT.DIR im gleichen Verzeichnis:

Code:

./nltpack x INTRODAT.DIR
Running on little-endian system

ls

CREDITS_    DUMMY        FNT32_2.ULI  I03_01.ULI  I05.ULI  I08.ULI  INTRODAT.DIR  REALMS.ULI   T02.ULI  T05.ULI  T08.ULI  TITLE.ULI   USLOGO.ULI
DSAART.ULI  FNT16.ULI    I01.ULI      I03_02.ULI  I06.ULI  I09.ULI  INTRODAT.VOL  SONGTIT.AWS  T03.ULI  T06.ULI  T09.ULI  TLOGO.ULI   nltpack
DSATIT.ULI  FNT32_1.ULI  I02.ULI      I04.ULI     I07.ULI  I10.ULI  LOGOMORP.ULI  T01.ULI      T04.ULI  T07.ULI  T10.ULI  UKLOGO.ULI

[Hendrik]

Ja, die INTRODAT.DIR ist definitiv die richtige Datei. INTRODAT.VOL funktioniert nicht. Ich hätte auch gerne noch ein paar Sanity-Checks eingebaut, allein, das Format des INTRODAT-Archive ist dermaßen "insane", da kann man nicht all zu viel tun außer ein paar asserts.

Dass der Packer bei dir die INTRODAT.VOL nicht lesen kann, hängt mit der unterschiedlichen Semantik von Groß-/Kleinschreibung unter Unix und DOS zusammen. DOS/Windows ist es egal, ob die Archivdatei INTRODAT.VOL/introdat.vol/introdat.VOL heißt, Unix/Linux nicht. In der INTRODAT.DIR steht jedenfalls als Dateiname "introdat.vol". Da meine dosbox-Dateien alle aus Großbuchstaben bestehen, musste ich in die Trickkiste greifen und nicht den Archivnamen aus der .DIR nehmen, sondern einfach den Dateinamen mit .VOL-Endung (INTRODAT.DIR --> INTRODAT.VOL). Was bei mir also gut funktioniert, führt bei dir zu (introdat.dir --> introdat.VOL) und somit zur Fehlermeldung.

Ein Umbenennen des Archives in "introdat.VOL" würde in deinem Falle zur Überbrückung helfen, bis mir dazu eine wirklich gute Lösung eingefallen ist. Eine "schmutzige" Lösung ist es, einfach nach der Schreibung der Dir-Endung zu schauen (.dir/.DIR) und die Vol-Endung entsprechend zu wählen (also .vol/.VOL). Eine entsprechend korrigierte Version hängt dran.

Das versagt aber in dem Moment, wo beide Dateien unterschiedliche Groß-/Klein-Schreibung haben. Ideal wäre eine Lösung, die für eine Datei x.dir nach der Datei x.vol in beliebiger Groß/Kleinschreibung sucht und ggf. auch aus mehreren Versionen die "passendste" heraussucht (Hamming-Abstand o.ä.).

[Obi-Wahn]

Ja, mit der neuen Version geht es.

[HenneNWH]

@Hendrik:

Leider geht jetzt das Entpacken der STAR.DAT (Diskettenversion) nicht mehr.
Der Entpacker identifiziert die Dateien von DSA2 als DSA3.

listing contents of DSA3 archive /home/henne/dosbox_work/SPIELE/DSA2/CD_C1.02/DATA/STAR.DAT

EDIT:

und DSA3 Dateien als DSA2.

henne@Henne01:~/dev/games/freedsa/trunk/modding/nltpack/test$ ../nltpack l ~/dosbox_work/SPIELE/DSA3/RIVA_1.12/DATA/RIVA.ALF
Running on little-endian system
nltpack: dsa2.cpp:43: virtual bool DSA2::read(std::istream&): Assertion `file_size >= oldentry->offset' failed.
Aborted

EDIT2:
Habs gefixt. filename.compare() gibt 0 zurück wenn der String gefunden wurde, ansonsten die erste unstimmige Postion.

[HenneNWH]

Hier ist die Beta2-Version von Hendriks NLTPack.
Es wurden 2 Fehler beim Entpacken des Intros von DSA1 behoben, sowie der Fehler,
dass DSA2 Dateien als DSA3 Dateien erkannt werden.
Die nltpack.exe wurde von mir mit mingw32 unter Linux gebaut.


  nltpack-beta2.zip (Größe: 251,73 KB / Downloads: 86)