Reverse Engineering der NLT III (mit KI)

[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 hatte lange und immer wieder vergeblich versucht, für diese Stellen binäräquivalenten C-Code zu finden, bis er letztlich den gewünschten Maschinencode einfach in Assembler hingeschrieben hat. 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 gespart).

Außerhalb des Kernbereichs gab es noch ein paar unkritische Bytes Differenz. Groß- vs. Kleinschreibung des Dateinamens BLADEM.EXE lies sich durch 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 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 wissen, dass man ggf. vielfach an den Positionen gewisser Reise-Events (z.B. manche Dungeon-Zugänge) vorbeilaufen muss, bis endlich die entscheidende Probe auf Sinnesschärfe gelingt. Zauber mit -5 halbwegs zuverlässig zu sprechen geht so auch nicht mehr.