NLT Modding: Ein anderer Ansatz

[Tandanu]

Die ganzen Reverse Engineering Projekte hier und Bright-Eyes sind wirklich beeindruckend, aber es gibt eine Kleinigkeit die mich daran etwas stört: man braucht immer eine gepatchte version von DOSBox zum Spielen. Deshalb hab ich mich über die letzten paar Wochenende ein bisschen selber damit beschäfigt und wollte euch hier einen leicht anderen Ansatz vorstellen (anders, nicht besser).
Ich hab mich bisher nur mit Schicksalsklinge beschäftigt und kann dort ganz gut den Zufallszahlengenerator auslesen und manipulieren und Helden editierbar machen.

Als erstes habe ich DOSBox gepatcht um... Moment, was? Hab ich nicht gerade gesagt genau das gefällt mir nicht?
Okay, also da kommt man natürlich nicht drum herum. Der Unterschied ist dass mein Patch allgemein gehalten ist und nicht spezifisch für ein Spiel ist, daher wurde das ganze auch recht schnell in DOSBox Staging aufgenommen, hier ist der PR.

Der Patch baut eine REST API in DOSBox ein die Speicher lesen und schreiben kann. Damit kann man dann prinzipiell alles tun.
In ein paar Wochen wird das ganze in den ganzen normalen DOSBox builds enthalten sein und einfach so mit der Standard-Config funktionieren.

Spielerein mit Speicher
Das offensichtlichste und einfachste ist ein Charaktereditor, warum mühsam Dateien editieren und neu laden wenn man auch einfach alles direkt live anpassen kann während das Spiel läuft?
Im Anhang ein Screenshot davon, alle Felder sind editierbar.

Dadurch dass alles über eine REST API läuft ist das ganze einfach eine Web App die man einfach in den (neuen) Ordner "webserver" in DOSBox wirft und dann http://localhost:8080/editor.html aufruft. Das macht es so viel einfacher UI Dinge zu bauen, insbesondere weil LLMs ziemlich gut darin sind so einfache Web Apps zu bauen.
Es sind nur die Basics implementiert, aber alles weitere ist nur Fleißarbeit. Natürlich stehe ich hier auch auf Schultern von Giganten weil der wirklich schwierige Teil ist natürlich das Reverse Engineering der ganzen Datenstrukturen, die konnte ich mir einfach abschauen...

Nur durch das Auslesen von Speicher könnte man auch noch eine Menge anderer tolle Dinge bauen, z.b. könnte man eine Karte anzeigen, oder einen Überblick über den aktuellen Kampf, oder die Eigenschaften von Gegnern im Kampf etc.


Modding: Code patchen und Funktionen einbauen

Etwas schwieriger wird es wenn man nicht nur Daten verändern will sondern den Code.
Ich hab den ganzen Spaß relativ ausführlich hier auf GitHub dokumentiert, die Kurzfassung davon ist dass ich ein Tool gebaut habe das mit einer unheiligen Mischung aus Javascript und 16 Bit x86 Assembler modernen C Code in laufende Spiele in DOSBox reinpatchen kann.

Als Demo für die NLT ist hier ein Tool das den Zufallszahlengenerator in Schicksalsklinge mitloggt und manipuliert.
Das ist zwar noch kein nützliches Tool (es sei denn man will wirklich jede Zufallszahl ohne weiteren Kontext sehen), die Manipulation kann aber ganz witzig sein.
Man kann, wieder über eine Web App, einfach den Zufall aus dem Zufallsgenerator rausnehmen.
Zum Beispiel wenn man erzwingt dass bei jedem random(100) immer exakt 1 raus kommt, dann bekommt man tagsüber in Städten bei jeder Bewegung eins der Zufallsevents :)

Das Ganze zu erweitern um die verschiedenen Funktionen für Proben etc schön mitzuloggen oder veränderbar zu machen ist wieder nur Fleißarbeit. Man könnte zum Beispiel alle Proben schwerer oder einfacher machen, oder die Gegner in Kämpfen schlechtere/bessere Würfel benutzen lassen.


Achtung: Der Code ist ziemlich zusammengefrickelt, vor allem Teile von der Typescript/Javascript-Implementierung sind echt nicht schön.
Muss ich bei Gelegenheit noch aufräumen.

[Shihan]

Herzlich Willkommen hier im Forum, Tandanu, und vor allem mit so einem Einstieg

Das ist eine sehr coole Idee und ich werde mir definitiv ansehen, was du da gebaut hst (also PR plus deine Hooks).
Muss gestehen, dass ich letztes Jahr auch daran gearbeitet habe, so eine API in die DOSBox reinzuhämmern. Also war die Idee entweder nicht wirklich schlecht oder wir sind halt zwei Leute mit verrückten Ideen. Aber den Reaktionen im PR nach scheint das nicht ganz soooo abwegig zu sein, wie man erst denkt.

Mein Fokus war aber eher ein Debugger-Frontend. Bin nur irgendwann nicht mehr so richtig vorwärts gekommen und hab die Idee dann erstmal wieder im Hinterkopf archiviert...

Witzig ist allerdings, dass du dich über die Notwendigkeit einer DOSBox aufgeregt hast, nur um dann erst so richtig auf die DOSBox zu setzen. Aber sowas passiert hin und wieder einfach in der Entwicklung...

Bin gespannt, wo die Reise damit hingehen wird!


@cmfrydos: DAS hier ist die Idee, von der ich Ende letzten Jahres sprach
Zum Beweis hänge ich noch Bilder an ;-)

[cmfrydos]

Auch von mir ein herzliches Willkommen im Forum!
Jau, das finde ich sehr stark. Wir hatten ja erst kürzlich konkret darüber diskutiert, so oder so ähnlich die globalen Variablen aus Riva im HDViewer verfügbar zu machen. Ich sehe darin auch das Potenzial, den von mir aktuell eher stiefmütterlich behandelten Riva-Probenlogger in eine schönere C#-Applikation zu überführen (bzw. in den HDViewer zu integrieren), da ich mich dort mit UI einfach besser auskenne als direkt in C++/SDL.
Ich schaue mir deine konkrete Implementierung bald in Ruhe an. Aktuell ist es etwas stressig, aber das verdient definitiv einen tieferen Blick!

[Tandanu]

die globalen Variablen aus Riva im HDViewer verfügbar zu machen.

Jepp, das sollte damit sehr einfach sein, die API um Speicher auszulesen ist einfach:

Code:

http://localhost:8080/memory/<segment>/<offset>/<länge>

Doku aller Endpoints ist einfach unter http://localhost:8080, einer der Endpoints gibt dir Pointer zu den DOS Datenstrukturen gibt, da findet man wo der aktuelle Prozess geladen ist.

Meine ganzen Hook-Scripts werden allerdings nicht funktionieren weil die nur 16 Bit können.

Witzig ist allerdings, dass du dich über die Notwendigkeit einer DOSBox aufgeregt hast

Nö, DOSBox an sich ist super, mich stört nur wenn man eine spezielle Version davon braucht.
Meine erste Idee war es auch eine Lua Runtime einzubauen, aber LuaJIT ist irgendwie nicht mehr so ganz auf dem Stand der Zeit und bei PUC Lua würde mich die ganze Zeit stören dass es langsam ist (und die C/C++ API ist grausam).

Mein Fokus war aber eher ein Debugger-Frontend.

Einen GDB Server hatte ich mir auch überlegt, aber das ganze Debugging funktioniert halt gut genug mit ein paar Hilfsvariablen und einem Breakpoint in der Hauptschleife von der emulierten CPU...