Reverse Engineering der NLT

[Rabenaas]

Meine Disassemblierungsversuche sind gerade an einem toten Punkt angekommen. Zunächst habe ich in IDA alle DOS-in21h-Routinen entsprechend ihrer Funktion benannt. Dann die aufrufenden Funktionen und immer so weiter. Inzwischen weiße ich bei einigen Teilen des Codes ziemlich genau, was sie anstellen. Im Moment knacke ich aber an der Funktion, die „P A U S E“ ausgibt.

Es wird ziemlich viel mit dem Cdrom angestellt, Dateien werden gelöscht und neu angelegt, der Ton wird neu konfiguriert(!) und der Interrupt 16h des Keyboards, den schickm für seine Zwecke umgebogen hat, wird aufgerufen.

Kann mir jemand sagen, bei welcher Gelegenheit „P A U S E“ auf dem Bildschirm ausgegeben wird?

[Crystal]

Indem man mit STRG-P in den Pausemodus schaltet.

[Hendrik]

Das hört sich ja schon sehr gut an, Rabenaas. Gerade mit den DOS-Funktionaufrufen habe ich mich ja bisher nur wenig beschäftigt. Wenn das in dem Tempo weitergeht, entreißen wir Schick bald seine letzten Geheimnisse...

Wir sollten die IDA-Dateien abgleichen, damit wir nicht alles doppelt machen müssen. Ich habe meine Dateien für Schick und Schweif mal ins SVN hochgeladen, ich hoffe mal, dass sich das irgendwie "diffen" lässt, vielleicht, wenn man die DB im entpackten Zustand speichert.

[HenneNWH]

Hallo Ihr alle!

@All: I'm back. Im Moment habe ich noch nicht wieder soviel Zeit, beschäftige mich aber mit der Intro.exe von Schick (Floppy).

@Hendrik: Du hast nicht die IDA-Dateien hochgeladen, sondern nur die symbolischen Links auf die Dateien.

Theorie: Das "Problem" mit den wechselnden Segmentadressen des near calls liegt wahrscheinlich an den Overlays.
Das Segment ändert sich weil es aus der Exe-Datei auf Anfrage in den Speicher geladen wird.
Wird der Speicher für etwas anderes benötigt, fliegt das Segment mit der Random-Funktion wieder raus.
Wir die Random-Funktion (oder eine andere aus diesem Segment) wieder benötigt, so wird sie wieder in den Speicher geladen.
Allerdings an einer anderen Stelle.
Lösung: Die Größe und die Position des Segments in der Exe-Datei ermitteln und bei jedem Read() Aufruf, bei dem Grösse und Position übereinstimmen, die Zieladresse merken.

[Rabenaas]

Hi Henne, back in black.

Ach so, deswegen klappt's nicht.
Die intro.exe von Schick greift nicht auf sound.adv zu. Das tun nur gen.exe und schickm.exe.

[HenneNWH]

Hi Rabenaas,

das stimmt. Mit den Treibern des Miles-Sound-Systems wollte ich auch _erstmal_ nichts zu tun haben.
Die Intro.exe ist allerdings mit Turbo Pascal 6.0 kompilert worden, welches ich _per Hand_ dekompilieren kann.
Das im Moment das einzige was ich tun kann.

Btw.: Der Code im Repo müsste jetzt auch wieder funzen.

[Hendrik]

Hallo Ihr alle!

@All: I'm back. Im Moment habe ich noch nicht wieder soviel Zeit, beschäftige mich aber mit der Intro.exe von Schick (Floppy).

@Hendrik: Du hast nicht die IDA-Dateien hochgeladen, sondern nur die symbolischen Links auf die Dateien.

Theorie: Das "Problem" mit den wechselnden Segmentadressen des near calls liegt wahrscheinlich an den Overlays.
Das Segment ändert sich weil es aus der Exe-Datei auf Anfrage in den Speicher geladen wird.
Wird der Speicher für etwas anderes benötigt, fliegt das Segment mit der Random-Funktion wieder raus.
Wir die Random-Funktion (oder eine andere aus diesem Segment) wieder benötigt, so wird sie wieder in den Speicher geladen.
Allerdings an einer anderen Stelle.
Lösung: Die Größe und die Position des Segments in der Exe-Datei ermitteln und bei jedem Read() Aufruf, bei dem Grösse und Position übereinstimmen, die Zieladresse merken.

Hi, HenneNWH! Schön, dass du wieder hier bist.

Die IDA-Dateien habe ich jetzt noch einmal hochgeladen . Leider ist das ungepackte Format auch kein Text-only, so dass die Versionskontrolle uns kaum unterstützen kann, wirklich schade. Ich habe die Dateien also im gepackten Format (store) hochgeladen.

Dass mein Problem mit den Overlays zu tun hat, habe ich auch schon vermutet, allerdings war mir nicht so recht klar, wie ich am einfachsten an die richtigen Adressen komme. Eine andere Erklärung ist mir auch nicht eingefallen, also gehe ich mal davon aus, dass die Theorie richtig ist.

Die read()-Aufrufe in der SCHICKM.EXE abzufangen dürfte also die Lösung sein, allerdings müsste da eigentlich reichen, für alle interessanten Overlay-Segmente die Offsets zu ermitteln. Soweit ich weiß, werden Overlay-Segmente immer im Ganzen geladen, also braucht man die Größe nicht einmal. Oder habe ich da etwas übersehen?

Da ich diese Woche einen Haufen zu tun habe und nächste Woche wohl im Urlaub sein werde, komme ich vermutlich nicht mehr dazu, das zu implementieren. Der Patch wird also noch mindestens einen halben Monat auf sich warten lassen.

[HenneNWH]

Hi Hendrik,

du hast Recht. Der Offset reicht völlig aus.
Die Größe wäre gut zur doppelten Absicherung, falls es jemand ne andere Version von Schick startet kurioses passiert.

[Rabenaas]

Was hast Du denn mit der intro.exe vor? Was spezielles, oder komplett dekompilieren, um sie dann neu zu implementieren?

[thEClaw]

Ich habe mal ein paar Fragen an die Leute, die DSA bis ins letzte Detail kennen:
Ich suche zur Zeit den Ort, wo die AT/PA- und Behinderungswerte von Waffen und Rüstungen sowie der Schaden der Waffen und der Rüstungsschutz angegeben werden. Könnt ihr mir da eine (oder mehr) Datei nennen? In der Datei für alle Items (irgendwo in der Schick.dat) stehen diese Werte nicht, dort ist laut FreeDSA-Wiki auch nur noch ein Byte o.ä. ungeklärt in Bezug auf die enthaltenen Informationen.
Zudem bin ich nicht ganz sicher, wie sich die Magieresistenz berechnet: Gibt es dafür eine explizite Formel (die auch in der NLT angewendet wird) oder sind die Werte charakterspezifisch? (ich glaube, bei DSA4.1 ist die MR kein berechneter Wert)

Außerdem wüsste ich gern, wo in den DSA1-Spielständen die Werte für Krankheiten gespeichert werden (falls das im Charakter-Abteil ist), ich habe zwar schon ein paar Infos dazu hier im Forum gefunden, aber der angegebene Offset passt irgendwie gar nicht zu meinen bisher gesammelten Daten. Und mir ist es in vielen Jahren DSA1 noch nicht vorgekommen, dass einer meiner Helden krank wurde. In DSA2 sieht das natürlich ganz anders aus...

Falls mir jemand helfen kann, bedanke ich mich schonmal im Voraus .

[Hendrik]

Zur Magieresistenz kann ich auf die Hilfsseiten verweisen. Für die Spielercharaktere gilt also die Formel (MU+KL+ST)/3 - 2*AG + Typmodifikator + evetuelle Artefakt- oder Zauberwirkungen. Da die MR aber extra gespeichert wird, ist das nicht zwingend so, da gibt es ja diverse MR-Bugs im Zusammenhang mit Amuletten, die die MR erhöhen.
Vor allem ist diese Formel für NSCs und Gegner nicht zuverlässig, da wird die MR oft einfach festgelegt oder ausgewürfelt.

Die MR in DSA4.1 ist übrigens auch aus anderen Werten berechnet und mit Modifikatoren durch Rasse, Kultur und Profession versehen, kann aber nachträglich mit AP gesteigert werden.

[thEClaw]

Ich danke dir schonmal für die Hilfe, die MR-Tabelle hatte ich noch nicht gesehen. Damit kann ich jetzt etwas anfangen - die Werte für Gegner oder NSCs brauche ich gar nicht .
Die Frage, ob die NLT-MR auch wirklich so berechnet wird (also ohne jegliche Amulette und Co.), steht noch im Raum (ich konnte jetzt nirgendwo ein klares "Ja" oder "Nein" herauslesen). Es würde mir schon reichen, wenn das für einen "frischen" Charakter gilt.

Nochwas wichtiges: Da der Aberglaube mit in die Berechnung eingeht, erhöht es denn stets die MR um 2 Punkte, wenn ich meinen AG senke? Oder geht der nur bei der ersten Berechnung ein (also bei Generierung)?

EDIT: Habe gerade mal nachgerechnet und im Generator stimmt die MR überhaupt nicht mit dieser Formel überein. Auch im Spiel kommt das irgendwie nicht hin, bei meinen Helden gibt es überall Abweichungen.

Die aktuelle Formel sieht so aus: (MU+KL+KK)/3 - 2*AG + Typmodifikator - 1
(Mut+Klugheit+Körperkraft)/3 - 2*Aberglaube +...
Das sind meine MR in Schatten über Riva. In DSA1 scheint es eher auf eine -3 oder -4 hinauszulaufen.
Kann es denn sein, dass ich die -1 irgendwo "verdient" habe? Gibt es in einem der drei Spiele eine Stelle, die die MR dauerhaft senkt? Für alle Helden? Wenn nicht, dann werde ich diese Formel so in meinem Konverter umsetzen (also mit -1). Wenn doch, habe ich ein kleines Problem...

[Kunar]

Den Zwölfen zum Gruße!

Nochwas wichtiges: Da der Aberglaube mit in die Berechnung eingeht, erhöht es denn stets die MR um 2 Punkte, wenn ich meinen AG senke? Oder geht der nur bei der ersten Berechnung ein (also bei Generierung)?

Das Senken des Aberglaubens ist immer nützlich. Ja, die Magieresistenz wird so berechnet wie angegeben. Allerdings gibt es mindestens im ersten Teil einen Fehler bei der Generierung. Wie ich schon vor Jahren schrieben: Wenn bei der Berechnung der Magieresistenz die Division glatt aufgeht, fällt die MR manchmal um einen Punkt zu niedrig aus.

[thEClaw]

Die Rechnung geht bei mir nie auf, trotzdem ist die MR nicht wie vorhergesagt.
Besonders auffällig ist, dass bei einem neu generierten Charakter teilweise Differenzen von 4 oder 5 Punkten auftreten (Generierung mit DSA3). Nach einem kleinen Test zeigte sich, dass wirklich die in der Formel angegebenen Eigenschaften beteiligt sind - aber vielleicht stimmen ja auch die Professionsmodifikatoren nicht... irgendwo muss ein Fehler liegen.
Ich hab's schon im Thread zu meinem Programmversuch geschrieben, erwähne es aber noch einmal: Ich habe zur Zeit große Probleme mit den AT/PA-Werten aller Waffenarten. (die Formel für die Basis AT/PA scheint übrigens sehr zuverlässig zu sein). Die Werte sind relativ extrem (bei DSA4 gibt es doch irgendeine Maximaldifferenz zwischen AT und PA), außerdem werden bei einigen Gegenständen AT/PA-Modifikatoren angegeben, die dann gar nicht stimmen (ein Lederzeug hat z.B. manchmal 0/-1, manchmal -1/0 - es wird aber immer 0/-1 angezeigt; dieses Problem könnte auf Dauer meine seltsamen Werte erklären - beim Anlegen -1PA, beim Ablegen +1AT o.ä.).

Gibt es hier noch einen Profi der DSA-Spielstände, der mehr weiß, als in der Wiki steht? Es gibt da noch einige Byte-Blöcke, deren Sinn ich nicht verstehe. Es gibt einige Bytes, die auf Kämpfe reagieren (ich habe 1+5 gefunden), es könnten noch irgendwo Modifikationen für AT/PA untergebracht sein und auch die Krankheiten habe ich mangels Infektion in DSA1 noch nicht aufgetrieben.

[Hendrik]

Wie kommst du ausgerechnet auf Körperkraft? Oder hast du das "ST" als "Stärke" interpretiert? Nein, das soll die STufe des Helden sein. Klar, dass du damit auf viel zu hohe Werte kommst.
Bezüglich Krankheiten kann ich dir nicht weiterhelfen, mit den Savegames habe ich mich kaum beschäftigt. Da sind die Leute vom Hex-Support sicherlich eher in der Lage, Krankheiten wegzuhexen.
Was die AT/PA-Modi angeht, bleiben ja nicht viele Dateien übrig, die in Frage kämen. Nur 3 Dateien sind im Wiki noch ohne Erklärung: SPSTAR.NVF, TOWNPAL.DAT, und BSKILLS.DAT. Die beiden ersten kommen vom Namen her nicht in Frage - .NVF ist ein Bild, und TOWNPAL.DAT hört sich nach einer Farbpalette an. Die BSKILLS.DAT passt vom Namen auch nicht so recht. Ebenso ist der Inhalt seltsam - 4-Byte-Folgen, mit gehäuftem Auftreten der Folge 0x??006300 (oder 0x006300??, das hängt davon ab, wie lang der Header ist).
Bezüglich der Größe der Daten könnte man einige Annahmen treffen: Ein halbes Byte reicht bereits aus, um z.B. alles bis RS7 abzuspeichern. Mehr hat meines Wissens kein Rüstungsteil in DSA. Je nach Anordnung kann man auch noch alle Kombinationen mit um 1 oder 2 verringertem RS abspeichern, z.B. RS0-4 und BE-Verringerung 0-2, macht 15 Kombinationen. Die AT/PA-Modifikatoren gehen eventuell auch in ein halbes Byte, und die TP lassen sich bequem in 1 Byte (je 4 Bit für Würfelanzahl und TP) unterbringen, theoretisch auch in weniger: 2 Bit für die Anzahl der W6 und 3 Bit für den fixen Grundschaden (0-7). Der KK-Zuschlag belegt auch etwa ein halbes Byte, wenn man mit Bias arbeitet (also z.B. 10 auf die Zahl draufaddiert), wäre das auch in 3 Bytes zu machen.
Andererseits würde mich solche Knauserigkeit schon verwundern, ich gehe also eher von 1 oder 2 Byte AT/PA-Modifikatoren aus, 1 Byte für den KK-Zuschlag und 1-2 Byte für die TP, 1-2 weitere Bytes für Bruchfaktor und Heldentypenmaske (wer darf was verwenden), also insgesamt 4-6 Bytes pro Waffe. Das ist nicht viel, ist irgendjemandem in einer Datei "Cruft" aufgefallen, bei dem es sich um diese Daten handeln könnte?

[thEClaw]

Vielen Dank für die Informationen...ST und KK, ja da hätte ich euch nicht unterschätzen sollen . Ich dachte gar nicht an die Stufe (kenne auch nur das DSA4/4.1-Regelwerk genauer und da ist die Stufe bisher bei keiner Berechnung wichtig gewesen). Da muss ich gleich mal die Formel anpassen...
Ich bin schon ganz wurmstichig wegen der vielen Rätselei, zumindest ist jetzt die MR vom Tisch.

Was deine weiteren Infos angeht: Sofern ich das bis jetzt beurteilen kann, waren die DSA-Programmierer wohl eher nicht knausrig mit dem Speicherplatz für Informationen (4 Byte für AP, 4 Byte für Geld, 14 respektive 27 Byte für einen Gegenstand - gerade die Bytes für die AP sind sehr übertrieben, da man ja nicht über Stufe 21 kommt), da hätte es schon viele Gelegenheiten gegeben, Daten in Halbbytes oder anderen Portionen aufzuteilen.
Die ITEMS.DAT habe ich letztens ausgelesen und auch dort waren die Informationen schön offen vorhanden (ohne die Wiki hätte es aber eine Weil gedauert, mich da reinzufuchsen ).

Wenn es wirklich nur um Waffen- und Rüstungwerte ginge, muss man auch bedenken, dass es nur 255 Gegenstände gibt, 98 davon laut Kunars Liste Waffen oder Rüstungen.
Der Bruchfaktor steckt ja schon im Item-Namen, Redundanzen würde ich eher nicht erwarten. Die 2 Byte für die Helden sind angemessen, den Rest halte ich auch für gut. Das würde nur knapp 500 Byte an Daten ausmachen - die BSKILLS.DAT hat aber zwei KB in (wie du schon sagtest) 4 Byte-Folgen. Das wäre etwas knapp für eine Waffe und sehr reichlich bemessen für unter 100 Items. Zudem besteht die Hälfte der Datei aus Nullen, was einen 4 Byte-Block schon zu 2 Byte zusammenschrumpft. Das Spektrum der Datei scheint auf den ersten Blick genau 100 Byte zu umfassen (0x00 bis 0x63), was könnte man denn in diesem Bereich verschlüsseln? 1 Byte lange Daten, die zwischen 01 und 99 liegen, wäre für Waffenwerte gar nicht mal ungeeignet.

EDIT: Noch ein paar Gedanken: Es gibt 325 4-Byte-Blöcke in der Datei, das schafft Raum für 325, 65, 25, 13 oder 5 "Objekte" (wenn ich da jetzt keine Zahl vergessen habe). Um Waffen könnte es sich bestenfalls handeln, wenn die ersten beiden Fälle eintreten, dann gäbe es also 4 oder 20 Byte pro Waffe. Um Rüstungen könnte es sich evt. handeln, wenn die Daten dazu 4 oder 42 Byte lang wären. Wirklich möglich sind also nicht viele Kombinationen, wenn es sich um Waffen und Rüstungen handeln soll. Dazu kommt, dass die 1300 Byte große Datei einen 25x4 Byte großen 0x00-Bereich am Anfang enthält und manchmal ein 4-Byte-Block nicht durch eine 0x63, sondern ein 0x0b (oder gar 0x05) beendet wird - vielleicht sind die Blocklängen also variabel mit einem Terminierungszeichen.
Das wollte ich nur noch gesagt haben vorm Schlafengehen . Vielleicht weiß ich ja morgen früh, was in der Datei ist .

[Hendrik]

Ich möchte dazu noch anmerken, dass diese Datei auch im Sternenschweif-Archiv vorkommt. Bis auf das letzte Byte, das in der Sternenschweif-Version einfach fehlt(d.h. die Datei ist nur 2999 Bytes lang), sind die beiden Dateien inhaltlich identisch.
Mir ist allerdings im Moment nicht klar, was du mit "Der Bruchfaktor steckt ja schon im Item-Namen" meinst.

[thEClaw]

Die BSKILLS.DAT bei DSA1 hat bei mir genau 1300 Byte - keine 3000.
Das mit dem Bruchfaktor war so gemeint, dass die 14-Byte-Bezeichnung (im Inventar - irgendwo muss ja eine Liste all dieser 14-Byte-Strings enthalten sein, oder?) für ein Item ja schon ein Byte für den Bruchfaktor hergibt.

DSA2-Dateien habe ich leider noch nicht entpackt, wäre mal einen Versuch wert. Wenn dort aber die gleiche Dateigröße vorliegt, dann kann es sich fast nicht mehr um die Waffen-Eigenschaften handeln, da es ja mehr Waffen gibt, die zumindest eigene Modifikatoren mitbringen müssten.

[Azraael]

Mal aus reinem Interesse: wie siehts hier so aus? Seid ihr noch fleißig dabei? Oder sollte ich die Hoffnung auf ein Open Source DSA Spiel in der Tradition und inspiriert von der NLT doch lieber aufgeben? :-)

Schönen Tag euch allen!

P.S.: Nur um sicher zu stellen, dass der Post nicht aufdringlich klingt oder so: Ich weiß, dass das tierisch kompliziert ist und seeeeehr viel Zeit in Anspruch nimmt. Ich wollt einfach nur mal nachfragen ob da noch jemand dran arbeitet und wie die Motivation bei euch so aussieht?

[Borbaradwurm]

Mal aus reinem Interesse: wie siehts hier so aus? Seid ihr noch fleißig dabei?

Ja.

Oder sollte ich die Hoffnung auf ein Open Source DSA Spiel in der Tradition und inspiriert von der NLT doch lieber aufgeben? :-)

Leider ja, und zwar aus rein rechtlichen Gründen: wenn es jemals ein neues Open-Source-Spiel-Marke-NLT geben wird dann sicher nicht als DSA. Zu DSA wird es wohl nicht über Programm das mit den entsprechenen original Spieldaten Die Schicksalsklinge/Sternschweif/Schatten über Riva den/die jeweiligen Teil(e) der NLT spielen kann, hinaus gehen.