Reverse Engineering der NLT II

[siebenstreich]

Eigentlich hatte ich nur darauf gewartet, dass sich jemand eine KI schnappt und das Projekt weiterführt. Ich war kurz davor, es selber zu versuchen.

Im Prinzip war ich auch an diesem Punkt...
Es ist absolut unglaublich (und auch gruselig), was diese KI-Modelle inzwischen können. Ich bin überwältigt von den Resutaten, aber offen gestanden auch etwas erschlagen!

ich hab auch noch den Quellcode von der Schicksalsklinge in C umschreiben lassen bytegleich, zusätzlich, weil Attic damals wohl C schrieb und nicht C++.

Wir hatten darüber ja per e-mail kommuniziert. Bei aktiviertem Schalter __BORLANDC__ und deaktivierten M302de_ORIGINAL_BUGFIX und M302de_FEATURE_MOD ist der BrightEyes-Quellcode im Wesentlichen C-Code. Henne hatte die Dateien aber als .cpp benannt und den Binäräquivalenz-Test mit dem Borland C++-Compiler durchgeführt. Er hatte mir mal den Grund dafür gesagt, aber ich erinnere mich leider nur schlecht. Evtl. liegt es daran, dass Bright-Eyes ja ursprünglich eine modifizierte DosBox war. DosBox ist in C++ geschrieben, und evtl. erforderte das gewisse C++spezifische Sprachelemente.

In BrightEyes gibt es an ein paar Stellen Assembler-Code. Bei manchen hardware-nahen Dingen (CD-Laufwerk, VGA) ist davon auszugehen, dass das auch im Original so war. Aber an ca. 3 oder 4 Stellen sollte im Original C-Code gestanden haben. Henne muste hier Assembler-Code schreiben, weil es ihm auch nach langem Herumprobieren nicht gelingen wollte, binäräquivalenten C-Code zu finden. Meine Interpretation der Claude-Erkenntnisse ist: Wird der Borland C-Compiler (und eben nicht der C++-Compiler) benutzt, dann produziert der naheliegende C-Code an diesen Stellen byteidentischen Maschinencode! Eigentlich war der Code also schon komplett binäräquivalent, Henne hätte nur den C-Compiler benutzen müssen (und sich vermutlich einiges an Lebenszeit eingespart).

Außerhalb des Kernbereich gab es noch ein paar unkritische Bytes Differenz. Groß- vs. Kleinschreibung des Dateinamens BLADEM.EXE lies sich auf die Verwendung der Borland IDE auflösen. Der integrierte IDE-Linker verhält sich in dieser Sache offenbar anders als die Kommandozeilen-Version, auch das ist eine Claude-Erkenntnis von Claude.

Kleiner Aha-Moment beim ersten Test: Die Schicksalsklinge würfelt Talent- und Zauberproben nicht nach Tischregel.

Sie zählt die drei W20 zusammen und vergleicht die Summe mit der Summe der Eigenschaften.

Ja, es war bekannt, dass die Schicksalsklinge Talentproben nach der sog. Pool-Variante durchführt.
Dadurch werden die Proben viel einfacher.

Im BrightEyes-Code gibt es einen Schalter M302de_FEATURE_MOD, der ein paar Änderungen aktiviert, die über normale Bugfixes hinausgehen. Hier hatte ich mal eingebaut, dass Proben nach den originalen DSA3-Regeln gewürfelt werden. Das Spiel wird dadurch aber deutlich schwieriger, beispielsweise muss man evtl. vielfach an gewissen Stellen vorbeikommen (z.B. gewisse Dungeon-Zugänge), bis die entscheidende Probe auf Sinnesschärfe gelingt.