Reverse Engineering der NLT II

[NRS]

Was die Änderungen der SCHICK.DAT anbelangt, existieren im Moment bei mir nur die geänderten Einzeldateien, die ich damals ganz pragmatisch mit Hex-Editor angegangen bin. Diese Änderungen kann man aber gewissermaßen mittels eines Änderungsskripts dokumentieren. Dazu müssten wir uns nur einig wären, wie das ganze aussehen soll.

Ausgangspunkt wäre die in Einzeldateien zerlegt SCHICK.DAT. Die Änderungen wären dreierlei:

1. Einerseits die Textdateien, die aus nullterminierten Strings bestehen. Bei denen werden nicht nur einzelne Bytes geändert, sondern mitunter Buchstaben eingefügt und ganze Strings hinzugefügt. Hier könnte man ein kleines CLI-Tool erstellen, welches zwei Kommandos kennt: "replace" und "add". Das Änderungsskript würde dann beispielsweise (kein "echtes" Beispiel) enthalten:
   Code:

   ltxtool ORVIL.LTX replace 57 "HIER STEHT DER NEUE TEXT FÜR STRING 57, WELCHER ERSETZT WIRD."
ltxtool SERSKE.LTX add "HIER STEHT DER TEXT FÜR DEN HINZUGEKOMMENEN STRING."
2. Andererseits Binärdateien, bei denen einzelne Bytes geändert werden, ohne die Dateigröße zu verändern. Hier beispielsweise das Ändern von Item-Flags oder die hinzugekommene Markierung eines Hauses in Clanegh als Wohngebäude von Treborn Kolberg. Ich weiß nicht, ob es hierfür ein portables Tool schon gibt. Aber das Änderungsskript hätte dann solche Zeilen wie:
   Code:

   changeFile CLANEGH.DAT at 42A with 04 00 00
3. Die FIGHT.LST ist ein Spezialfall: Hier sind zunächst die zusätzlichen Nachtlagerkämpfe an die bestehende Datei hintendran zu kopieren (das geht einfach mit COPY /B FIGHT.LST + FIGHT.NEW FIGHT.LST) und danach die Anzahl der Kämpfe in den ersten zwei Bytes mit "changeFile" oder wie immer das Tool heißt zu erhöhen. Die neuen Kämpfe kann man dann einfach als feststehende Binärdatei auf github hochladen. Alternative: Man schreibt ein kleines C-Programm, welches die neuen Kämpfe als gepackte structs beschreibt und dann speziell die FIGHT.LST patcht, das heißt hinten dran tackert und den Kampfzahlzähler am Dateibeginn erhöht. Dann wären die neuen Kämpfe besser "dokumentiert". Wäre allerdings extrem aufwändung und vielleicht trotzdem nicht so informativ.
   

Mit SCHICKM.EXE selbst hat das eigentlich nichts zu tun, weshalb das m.E. eigentlich aus BrightEyes ganz raus sollte. Allerdings bestehen Abhängigkeiten zwischen den Bugfixes in SCHICKM.EXE und SCHICK.DAT: eine ungepatchte SCHICKM.EXE funktioniert mit einer gepatchten SCHICK.DAT, aber nicht umgekehrt, denn wenn die neuen Nachtlagerkämpfe referenziert werden, müssen sie natürlich auch in SCHICK.DAT enthalten sein; dasselbe mit neuen Textstrings.