Reverse Engineering der NLT II

[siebenstreich]

Ein potentieller Makel ergäbe sich, wenn es viele Code-Stellen gibt, die auf denselben fehlerhaften Eintrag in der SCHICK.DAT zugreifen, denn dann muss man den Hot-Fix an jeder solchen Stelle vornehmen.

Dann definiert man halt eine Funktion, die man an jeder solchen Stelle aufruft. Das halte ich jetzt für keinen besonders großen Aufwand.

Hatte mir fast gedacht dass das kommt.
Ich will eigentlich mit dem Code möglichst nahe am Original bleiben, nachdem es sich ja nicht um was Eigenständiges handelt, sondern um einen Bugfix von bestehendem Code. Und da hab ich irgendwie eine Blockade, wegen einem fehlenden Buchstaben eine neue Funktion einzubauen. Aber letztlich ist das natürlich allemal besser als an 10 Stellen im Code synchron dieselbe Ergänzung einzufügen.
Und trotzdem werde ich das dumpfe Gefühl nicht ganz los: Konsequenterweise sollte das Übel an der Wurzel gepackt werden, und die liegt nunmal in der SCHICK.DAT und nicht im Code, der die (mit dem Rechtschreibfehler behafteten) Daten nur weiter verarbeitet.

Wenn es nur um Text geht, braucht man kein lesbareres Format, weil der Text ja schon so lesbar ist. Du kannst dir ja mal die SCHICK.DAT mit einem Hex-Editor anschauen. Der Text ist bis auf ein paar Sonderzeichen direkt lesbar.

Stimmt natürlich. Was mich halt etwas stört ist, dass ich da nichts kommentieren kann und keine Präprozessor-Maschinerie zur Verfügung habe.

Solche Patches könnte man mit diff und xxd erstellen. Gemessen an allen Beispielen, die du uns hier bisher vorgestellt hast, finde ich es aber immer noch am einfachsten, die Änderungen direkt im Quellcode vorzunehmen - so wie es bereits getan wird.
[...]
Ich finde es gut so und sähe nur zwei Gründe, warum man es anders machen sollte: 1. Falls es wirklich sehr viele sehr große Änderungen an der SCHICK.DAT gibt, die sehr viele unübersichtliche zusätzliche Codezeilen benötigen.

ok, das ist eine klare Aussage, vielen Dank! Daran werde ich mich erstmal halten und schauen, wie weit ich komme.

2. Man will generell nicht nur Bugs fixen, sondern komplexere Mod-artige Änderungen vornehmen (sowas schwebte mir ursprünglich mal vor, als ich das schick-data-gui Tool begonnen habe, bin davon aber wieder abgekommen).

Nein, darum geht es mir nicht. Ich will lediglich "digitale Denkmalpflege" betreiben, um die sehr treffenden Worte von Henne (oder von dir?) zu benutzen.

Für vernünftiges Modding hielte ich es für zielführender, wenn man das Spiel neu und v.a. sauber programmiert und sich dabei die Logik aus BrightEyes abschaut. Vorher muss man sich sehr gründlich überlegen, wie man die Schnitstelle zu den Daten-Beschreibungsdateien möglichst flexibel gestalten will. Dieses Gefühl hatte ich von Anfang an und seitdem ich durch BrightEyes etwas in die Untiefen des Quellcodes geblickt habe, hat sich das nur deutlich verhärtet.

Am Rande bemerkt verstehe ich nicht, warum Henne an den von dir verlinkten Stellen so umständliche Char-Arrays anstatt String-Literale benutzt [...]

Das hatte ich mich auch gefragt. Hat es vielleicht was mit BCC-Kompatibilität zu tun?