Reverse Engineering der NLT II

[Alrik Alrikson]

[...]

4. Gibt es eigentlich irgendwelche Gegner, die (ohne übers Debugging nachzuhelfen) einen Bannbaladin oder Bösen Blick zaubern?

[...]

Spontan fiele mir da Arkandor ein, was "Böser Blick" angeht.

[Crystal]

Im ersten Teil spricht kein Gegner weder Bannbaladin noch Böser Blick. Bannbaladin wird mMn sogar von gar keinem Gegner in der gesamten NLT gesprochen.
Böser Blick kann zum einen Arkandor, wie Alrik schon bemerkte, der gehörnte Minotaur sowie die Wurmkönigin. Wo ich mir nicht sicher bin, ist Pergor in Magiergestalt und das Spiegelbild des eigenen Magiers im Spiegelkampf.
Alles Gegner aus Teil 2 und 3, weil dort schon mehr Zauber umgesetzt waren, als noch in der Schicksalsklinge.

Ich denke, Mirko meint aber vorerst nur Gegner aus dem ersten Teil, richtig?

[Mirko]

Vielen Dank für die Informationen, ihr beiden. Ja, ich meinte nur Gegner aus Teil 1. Ich habe mich (was Bright Eyes angeht) bisher nur mit der Schicksalsklinge beschäftigt und kann jetzt auch gar nicht sagen, wie weit die anderen Teile schon sind. Ich finde es auf jeden Fall interessant, dass die Sprüche größtenteils implementiert sind (es sind sogar entsprechende Textausgaben drin), aber eben nicht vollständig bzw. zum Rest des Kampfsystems passend.

[Wetzer]

Na, wäre das nicht etwas für hier:

https://www.heise.de/newsticker/meldung/...23397.html

[Shihan]

Leider nein:

• Supported file formats: ELF, PE, Mach-O, COFF, AR (archive), Intel HEX, and raw machine code. Kein MZ
  
• Supported architectures (32b only): Intel x86, ARM, MIPS, PIC32, and PowerPC.
  

Aber sonst bestimmt interessant. Danke für den Hinweis!

[Rabenaas]

Naja, raw machine code sieht als Fallbacklösung doch vielversprechend aus.

[Shihan]

Oh, da betreten wir Gebiete, die mir persönlich eher unbekannt sind. Habe mich bisher immer konsequent über dieser Ebene gehalten  

Wie bekomme ich den Code denn RAW aus der EXE? Da müsste man doch erstmal den ganzen Kram drumherum wegschneiden, wie MZ-Header, Relocation Table, etc.
Und bei Riva dann noch den DOS/4GW...

Oder steh ich auf dem Schlauch?

[Obi-Wahn]

Gibt es hier eigentlich was Neues? Die letzte Download-Version ist inzwischen vom Januar 2017...

[gaor]

Gute Frage eigentlich. Mir fehlt ein bisschen die Roadmap. Welche offenen Projekte gibt es? Was sind die Ziele dieser Projekte? Was ist am realistischsten erreichbar? Woran müsste dafür gearbeitet werden? Was wären die nächsten logischen Schritte?

Nachtrag: Hier gleich mal, was ich denke: Ich dachte ursprünglich, wir kriegen mit Bright-Eyes C++-Code, den man mit einem modernen Compiler wie gcc in eine Binary verwandeln kann, die unter Verwendung einer gültigen SCHICK.DAT selbstständig lauffähig unter Linux/Windows/... ist. Bei meiner Arbeit am Code ist mir aber mehr und mehr klar geworden, dass der existierende Code ganz wesentlich auf Standardbibliotheken von Borland basiert. Insbesondere die Hardwareschnittstellen (Grafik, Sound und Benutzereingaben mit Maus und Tastatur) liegen in einer Form vor, die man nicht mal eben an moderne Standardbibliotheken anpasst. Belehrt mich gerne eines besseren!

Naja, und ich hatte mir dementsprechend eigentlich gewünscht, dass man so einen lauffähigen Code als Grundlage verwenden könnte, um die alte Schicksalskling zu erweitern. Man könnte neue Nebenquests einfügen, die Reisekarte um neue Routen und Dungeons, vielleicht sogar ganze Ortschaften, ergänzen usw. Auf der optischen Ebene könnte man die Auflösung erhöhen, neue Grafiken einfügen, neue (magisch und nichtmagisch) Gegenstände hinzufügen. Neue Nebenquests könnten Talentwerte benutzen, die bisher mehr verzierenden Charakter hatten.

Naja, aber solange alles nur in Form von C++-Code vorliegt, der im wesentlichen entweder als Plugin von DosBox oder auf der Grundlage der Borland-Bibliotheken als natives DOS-Programm vorliegt, traue ich mich ehrlich gesagt nicht daran, solche Vorhaben anzugehen. Natürlich hält mich persönlich auch neben einem akuten Zeitmangel (haha...) die Tatsache ab, dass ich mich mit C und C++ nicht besonders wohl fühle (zu wenig Erfahrung).

[Rabenaas]

Hennes Ziel ist 100% Binärkompatibilität. Das ist zwar einerseits cool, andererseits fördert es nicht gerade das Herumhacken am Code. Mir würde es schon reichen, wenn Schick nativ mit SDL liefe.

[gaor]

Also momentan sind wir doch schon so weit, dass die mit BCC kompilierte binary identisch ist mit der SCHICKM.EXE, inklusive Datensegment usw. oder nicht?

[Rabenaas]

Das letzte mal, das Henne eine Statistik gepostet hat, fehlten 5 Funktionen für Binärkompatibilität. Außerdem schließt sich die komplette Phase 2 an, bevor es an die Portierung geht. Jedenfalls ist das mein Eindruck.

[gaor]

Ach stimmt, da sind noch 5 so Funktiönchen

Aber das Datensegment ist schon lange fertig und identisch: http://www.crystals-dsa-foren.de/showthr...#pid151670

Phase 2 kannst du also quasi als beendet verbuchen.

[Rabenaas]

Krass.

Wie sieht es denn mit der EXE aus? Gibt es ein DOS-Executable?

[gaor]

Ja, also so eine BLADEM.EXE wird erstellt Lauffähig ist die aber nicht.

Mal eine andere Frage: Ich kompiliere wie gehabt mit BCC.EXE und schaue mir die disassemblierten Ergebnisse an. Dann habe ich hier gerade das Problem, dass in meinem disassemblierten Code über "call  0x0:0x0" steht, wo eigentlich "call word 0x0:0x0" stehen sollte (also laut original SCHICKM.EXE). Das ist neu, das war vor einem halben Jahr nicht so. Hab ich da in meinem Setup irgendwas zerschossen?

[Rabenaas]

Vielleicht mein IDA einen dword-Offset, wenn da nichts steht.
Wie sehen denn jeweils die Hexwerte aus?
https://c9x.me/x86/html/file_module_x86_id_26.html

Woran scheitert die EXE denn, mal ganz naiv gefragt?

[gaor]

Also erstmal zu dem problem mit "call word": Ich hatte das problem falschherum wiedergegeben und jetzt oben korrigiert. Außerdem konnte ich es inzwischen lösen: Ich disassembliere mit dem Befehl "ndisasm". Der wurde in den vergangenen 10 Monaten einige Male upgedatet. Also habe ich kurzer Hand mal die Version von 2016 (nasm-2.11.06) installiert (aktuelle Version meines Paketmanagers ist nasm-2.13.02). Und siehe da:  Das Problem taucht nur mit Versionen 2.13.x auf!

Zu der BLADEM.EXE: Wenn man die in Dosbox aufruft passiert einfach nichts. Als wäre er in einer Endlosschleife ohne Ausgabe. Vermutlich ist die aber auch nicht richtig gelinkt, wie man an den ganzen Aufrufen von "call 0x0:0x0" (also alles zeigt nach 0x0) sieht. Man müsste sich mal durch das aktuelle Setup wühlen, um zu sehen, wie die gelinkt wird.

[Hindro]

Also ich finde ja toll was ihr da macht.
Wenn es läuft kann man anfangen Voraussetzungen für die einfache Integration eigener Orte, Dungeons, Ereignisse, Gegenstände und Geschichten einzubauen.

[gaor]

"einfache Integration". Das ist ja immer eine Frage der Perspektive

Nur mal so: Eigentlich war die Idee von Bright-Eyes, dass man ein paar Gameplay-Fragen beantwortet kriegt. Also: Welche Proben werden wann gewürfelt? Wo gibt es vielleicht Dialoge, die noch keiner entdeckt hat? Wie ist die Logik hinter dem Auslösen bestimmter extrem seltener Ereignisse? Und dann gab es auch Dinge, bei denen nicht klar war, ob es sich um einen Bug oder Absicht handelt. Alle diese Fragen kann man auch mit dem aktuellen Zustand des Codes beantworten!

Aus Bright-Eyes eine Grundlage für wirklich aufwendige Mods zu nehmen, ist eigentlich gar nicht unbedingt so klug. Ich überleg die ganze Zeit, ob es nicht weniger Arbeit wäre, alles mit modernen Engines/Libraries/Programmierparadigmen (objektorientiert!) nachzuprogrammieren und dort dann eben direkt elegante Modding-Schnittstellen einzubauen.

[Rabenaas]

Sicher, jetzt wo die Logik vollständig bekannt ist. Wobei ich Objektorientierung gar nicht mal so wichtig finde wie moderne Datentypen mit Speichermanagement und Bibliotheken.