Crystals-DSA-Foren

(05.07.2010, 16:39)HenneNWH schrieb: [ -> ]Das freut mich. Hast du es nicht unter Linux probiert oder funktioniert es da nicht?

Einfach nicht probiert, saß gerade am Windows-Rechner und es lief ja wunderbar .

(05.07.2010, 16:39)HenneNWH schrieb: [ -> ]Bei DSA2 gibt es die Datei ITEMS.DAT. Auf den ersten Blick würde ich sagen, dass dort die Daten sind die Du suchst.
Jeder Gegenstand hat eine Größe von 14 Byte, was bei einer Dateigrösse von 4942 Bytes 353 Gegenstände ergibt.
In der ITEMS.LTX sind die Namen der Gegenstände und in der ITEMS.NVF sind die Bilder.
Allerdings gibt es nur 278 Bilder, weshalb ich vermute, dass einige verschiedene Gegenstände das gleiche Bild haben.

Sehr wertvolle Informationen, dankesehr! 14 Byte pro Gegenstand klingen gut, das war ja auch die Inventar-Slot-Größe bei DSA1 (obwohl ich hoffe, dass diese 14 Bytes mehr Infos enthalten). Ich gehe einfach mal davon aus, dass ich die Infos an gleicher Stelle auch in DSA3 finden kann? Die DSA1-Liste habe ich ja vor einiger Zeit schonmal in HEX-Form zusammengestellt, die sollte ich nach Bedarf weiterverwenden und abändern können.

(05.07.2010, 17:56)Borbaradwurm schrieb: [ -> ]Ganz einfach: Die Schicksalsklinge wurde von Attic anfangs noch für Maschinen mit nur 16 bzw. 64 Farben (Atari ST bzw. OCS/ECS-Amiga) entwickelt und das sieht man dem Artwork deutlich an.

Ja, es sah so aus, als seien für einige Bilder die gleichen hochauflösenden Quellen herunterkomprimiert wurden - nur eben mit verschiedenen Zielvorgaben. Ich habe beim Basteln jetzt ein Programm geschrieben, mit dem man 6 verschiedene Algorithmen auf Bilder werfen kann, damit sie in ein DSA-kompatibles Paletten-Format umgewandelt werden; auch die Farbanzahl ist wählbar.
Ich habe damit ein wenig getestet und bemerkt, dass die Bilder sprunghanft enorm an Qualität gewinnen, wenn die Farben von 32 auf 60 bis 70 erhöht werden* (aus der ab DSA2 zur Verfügung stehenden Palette). Auch sehen die Bilder ab Teil 2 ziemlich gefiltert aus, ähnliche Ergebnisse erhalte ich, wenn ich auf hochauflösende Bilder beim Konvertieren ins DSA-Format einen bilinearen Filter anwende.
Soll heißen: Alles in Ordnung mit 32x32 Pixeln bei 96 Farben, das reicht wirklich für erstaunlich gute Resultate.

Dann gehe ich mal Items suchen - und vielen Dank für die Hilfe, frisst ja alles enorm Zeit, wenn man erst viel Tüfteln muss.

PS: Ich habe nur so aus Neugier auch mal versucht, den nvf2tga-Konverter auf die HEADS.DAT aus DSA1 anzuwenden. Das hat nicht funktioniert, weil in der Datei wohl die Paletten-Information fehlt (laut FreeDSA-Wiki, evt. steckt ja noch mehr dahinter).
Und falls es irgendjemanden interessiert : Ich habe in den Quelltext geschaut und es scheint, dass die "colors"-Variable in der "static void do_mode_same" gern über die Grenzen des Arrays läuft, für das sie als Index dient. Das Ergebnis waren zufällig ausgelesene Speicherzellen (wenn ICH sowas mache, stürzt mein Programm immer ab ).
Ich weiß nicht, ob das ein Bug ist, ob ich das Programm da arg misbraucht habe oder ob das gar so gedacht ist. Aber ich wollte es mal anmerken.

*=auch eine hohe Rot-Wichtung im RGB-Abstand scheint bei den meisten Bildern von Vorteil zu sein

Die Item-Listen der drei Spiele habe ich jetzt zerlegt (pro Teil werden die Einträge 2 Byte länger...). Somit kenne ich die Item-Indizes, die zugehörigen Bilder, Preis, Gewicht und noch ein paar mehr. Einige Bytes sind nicht entschlüsselt (scheinen eine ganze Reihe von Flags dabei zu sein), aber ich glaube nicht, dass mich die interessieren.
Als nächstes müsste ich noch mehr Infos haben, was die einzelnen Items angeht: Magische Gegenstände, Waffenwerte usw. - gibt es da vielleicht auch eine Datei?

(05.07.2010, 18:37)thEClaw schrieb: [ -> ]Einfach nicht probiert, saß gerade am Windows-Rechner und es lief ja wunderbar .

Super!
Probiers aber bitte auch mal mit deinen Dateien unter Linux, damit wir den Bug fixen können falls er doch noch vorhanden ist.

(05.07.2010, 18:37)thEClaw schrieb: [ -> ]Sehr wertvolle Informationen, dankesehr! 14 Byte pro Gegenstand klingen gut, das war ja auch die Inventar-Slot-Größe bei DSA1 (obwohl ich hoffe, dass diese 14 Bytes mehr Infos enthalten). Ich gehe einfach mal davon aus, dass ich die Infos an gleicher Stelle auch in DSA3 finden kann? Die DSA1-Liste habe ich ja vor einiger Zeit schonmal in HEX-Form zusammengestellt, die sollte ich nach Bedarf weiterverwenden und abändern können.

Die 14 Bytes sind auch nur die Vorlagen.
Es gibt Flags für magisch, kaputt, abgenutzt und diverse Gifte, welche erst im Spiel gesetzt werden.
Ich hab da mal etwas an Schick geforscht indem ich die einzelnen Bits eines Gegenstandes im Spielstand geändert habe und dann in der Zustandsübersicht den Gegenstand betrachtet habe.
Allerdings trau ich der Zustandsübersicht nicht ganz.

(05.07.2010, 18:37)thEClaw schrieb: [ -> ]PS: Ich habe nur so aus Neugier auch mal versucht, den nvf2tga-Konverter auf die HEADS.DAT aus DSA1 anzuwenden. Das hat nicht funktioniert, weil in der Datei wohl die Paletten-Information fehlt (laut FreeDSA-Wiki, evt. steckt ja noch mehr dahinter).

Nagel uffn Kopp! Die Palette ist bei DSA1 in der GEN.EXE und der SCHICKM.EXE hartcodiert.
Bei den Nachfolgern wurde da nicht mehr so mit RAM geknausert.

(05.07.2010, 18:37)thEClaw schrieb: [ -> ]Und falls es irgendjemanden interessiert : Ich habe in den Quelltext geschaut und es scheint, dass die "colors"-Variable in der "static void do_mode_same" gern über die Grenzen des Arrays läuft, für das sie als Index dient. Das Ergebnis waren zufällig ausgelesene Speicherzellen (wenn ICH sowas mache, stürzt mein Programm immer ab ).
Ich weiß nicht, ob das ein Bug ist, ob ich das Programm da arg misbraucht habe oder ob das gar so gedacht ist. Aber ich wollte es mal anmerken.

Stimmt! Habs bei mir gefixt und kommt gelich ins SVN.
Das Programm ist aber wirklich nur für Teil2+3 gedacht, da dort von den Dateienungen auf den Inhalt schliessen kann.
Bei Teil 1 war das noch nicht ganz so.

(06.07.2010, 16:59)HenneNWH schrieb: [ -> ]Super!
Probiers aber bitte auch mal mit deinen Dateien unter Linux, damit wir den Bug fixen können falls er doch noch vorhanden ist.

Der beschriebene Fehler war ja unter Windows praktisch identisch - nur wurden mir die tausenden Verzeichnisnamen da beim Erstellen zwar in der Konsole ausgegeben, ich konnte sie aber nicht finden. Vermutlich hat Windows das Erstellen wegen der Sonderzeichen geblockt.
Unter Linux sah es eben identisch aus, nur waren die Verzeichnisse am Ende auch da. Falls ich Lust habe, teste ich das nochmal unter Linux - aber momentan sitze ich lieber am Windows-Rechner (Linux läuft auf meinem Laptop und der ist zum Programmieren manchmal ein wenig träge ).

(06.07.2010, 16:59)HenneNWH schrieb: [ -> ]Es gibt Flags für magisch, kaputt, abgenutzt und diverse Gifte, welche erst im Spiel gesetzt werden.
Ich hab da mal etwas an Schick geforscht indem ich die einzelnen Bits eines Gegenstandes im Spielstand geändert habe und dann in der Zustandsübersicht den Gegenstand betrachtet habe.

Am besten wäre da wohl, zu beobachten, wann das Programm auf ein Flag reagiert. Soweit ich das einschätzen kann, wurde eine gute Menge der DSA-Daten so gecodet, dass man noch locker 10 Fortsetzungen hätte unterbringen können, ohne nochmal an der Basis rütteln zu müssen. Schade, dass es nicht soweit kam .

(06.07.2010, 16:59)HenneNWH schrieb: [ -> ]Nagel uffn Kopp! Die Palette ist bei DSA1 in der GEN.EXE und der SCHICKM.EXE hartcodiert.
Bei den Nachfolgern wurde da nicht mehr so mit RAM geknausert.

Ich habe leider nicht die richtige Palette finden können - im FreeDSA-Wiki steht zwar, dass sie fehlt, aber es wäre ganz schön, wenn die Palette dort auch zu finden wäre. Die Palette aus DSA2+3 hat leider nicht gereicht. Ich wollte nämlich (überflüssigerweise) auch mal die Charakter-Portraits und Gegenstands-Bilder aus Teil 1 entpacken. Ich habe ein paar verschiedene 256-Farb-Paletten angehängt (dann läuft das Programm auch durch), aber nur schwarze oder weiße Bilder erhalten.

(06.07.2010, 16:59)HenneNWH schrieb: [ -> ]Das Programm ist aber wirklich nur für Teil2+3 gedacht, da dort von den Dateienungen auf den Inhalt schliessen kann.
Bei Teil 1 war das noch nicht ganz so.

Achso. Na um ein Haar hätte es ja geklappt mit den von mir getesteten NVFs, nur die richtige Palette wollte ich nicht finden.

Ich habe jetzt Portraits und Items sauber verarbeitet (auch eine hoffentlich fehlerfreie Vergleichsliste aller Items von Teil 1-3 ist entstanden) und bin noch auf der Suche nach den zusätzlichen Item-Informationen. Interessant ist das nur für Waffen, Rüstungen und magische Gegenstände - AT, PA, BE, eventuelle magische Modifikatoren usw. möchte ich gern im Original sehen. Lässt sich da was machen ohne Disassembler? Noch bin ich auf keine Datei gestoßen, in der diese Infos zu finden wären. Und der auf die SCHICKM.EXE angewandte Hex-Editor hat auch kein hübsches Array zu Tage gefördert .

EDIT: Ich habe gerade mal diese Palette mit der GGSTS.NVF aus DSA1 probiert, aber die Farben sind leider falsch . Immerhin kann ich aber die Bilder erkennen.

Die Palette für die Gesichter findest du in der loader.nvf.lua.
Sie heisst facesPal und geht von 0x20-0x3f.

Auf DSA1 Support in NVF2TGA habe ich allerdings keine Lust, da wie schon erwähnt, die Formate und die Dateiendungen nicht immer etwas miteinander zu tun haben.
Das ergibt sehr unschöner Code.
Außerdem ist NVF2TGA nur als Test für die Packalgorithmen und Format von Teil2+3 gedacht.

(06.07.2010, 19:26)thEClaw schrieb: [ -> ]Ich habe jetzt Portraits und Items sauber verarbeitet (auch eine hoffentlich fehlerfreie Vergleichsliste aller Items von Teil 1-3 ist entstanden) und bin noch auf der Suche nach den zusätzlichen Item-Informationen. Interessant ist das nur für Waffen, Rüstungen und magische Gegenstände - AT, PA, BE, eventuelle magische Modifikatoren usw. möchte ich gern im Original sehen. Lässt sich da was machen ohne Disassembler? Noch bin ich auf keine Datei gestoßen, in der diese Infos zu finden wären. Und der auf die SCHICKM.EXE angewandte Hex-Editor hat auch kein hübsches Array zu Tage gefördert .

Das kann ich dir heute nicht sagen, aber ich werde beim nächsten disassemblieren die Item-Funktionen genauer unter die Lupe nehmen und näheres berichten.

Wo wird es deine Liste denn zu sehen geben?

(06.07.2010, 21:06)HenneNWH schrieb: [ -> ]Die Palette für die Gesichter findest du in der loader.nvf.lua.
Sie heisst facesPal und geht von 0x20-0x3f.

Äh...das sieht irgendwie seltsam aus. Sind das drei Kanäle eines 24-Bit-Farbwertes? Ich habe gerade versucht, alle mit 4 zu multiplizieren, aber das waren dann scheinbar doch nicht die richtigen RGB-Werte. Dabei war das eine verfluchte Arbeit, alles von Hand umzuwandeln - beim nächsten Mal mache ich das anders .
Aber danke für den Link, endlich kann ich mal die Palette sehen. Ich hatte schon einen Teil davon in Verwendung, als ich mit den Portraits gespielt habe, allerdings hatte ich auch diese Palette nur abgekupfert (von Thorium, der mir freundlicherweise den Quellcode seines Portrait-Konverters hat zukommen lassen).
Falls du mir also einen Gebrauchshinweis geben kannst...das wäre ganz nützlich - ich kenne mich mit lua nicht aus und das würde eine Weile dauern .
EDIT: Ich habe noch ein paar Paletten ausprobiert und bin mittlerweile der Meinung, dass da beim Auslesen der Bilder schon etwas schief läuft. Ich habe einige gar nicht üble Resultate gehabt, allerdings waren die Farben immer falsch und keine Form der Bildbearbeitung konnte das ändern.
Wenn das stimmt, dann wird's halt nichts mit den Item-Bildern aus DSA1, probiert habe ich jetzt genug.

(06.07.2010, 21:06)HenneNWH schrieb: [ -> ]Auf DSA1 Support in NVF2TGA habe ich allerdings keine Lust, da wie schon erwähnt, die Formate und die Dateiendungen nicht immer etwas miteinander zu tun haben.

Nein, nein, ich wollte dich nicht zu irgendwelcher Arbeit nötigen. Das Programm funktioniert so wunderbar .

(06.07.2010, 21:06)HenneNWH schrieb: [ -> ]Das kann ich dir heute nicht sagen, aber ich werde beim nächsten disassemblieren die Item-Funktionen genauer unter die Lupe nehmen und näheres berichten.

Mmh, dann hoffe ich mal, dass das nicht allzu lange auf sich warten lässt .

(06.07.2010, 21:06)HenneNWH schrieb: [ -> ]Wo wird es deine Liste denn zu sehen geben?

Die Item-Tabelle war ein Abfallprodukt, die wird es nirgendwo zu sehen geben.

So, ich bin noch immer auf der Suche nach Informationen . Ich habe mir mal den Dosbox-Hack von Hendrik runtergeladen, laut Datum müsste der ja mit Dosbox 0.72 oder 0.73 laufen, richtig? Ich werde erstmal mein Glück versuchen, mich eventuell durchs Forum klicken und - falls nötig - um Hilfe bei der Benutzung bitten.

EDIT: Die Dosbox läuft schonmal - allerdings bekomme ich noch nicht die gewünschten Informationen (ich dachte mir, dass beim Anlegen eines Gegenstandes irgendwas passieren müsse, damit z.B. der Rüstungsschutz berechnet werden kann). Kann ich da irgendwas machen um an Speicheradressen o.ä. zu kommen? Oder muss ich mit 'nem richtigen Disassembler ran?

Der aktuelle Patch ist für Doxbox 0.73, 0.74 sollte sich auch sauber damit patchen lassen.
Damit es wie gedatch funktioniert, brachst du:
a) die CD-Version v3.02 von Schicksalsklinge und,
b) musst in der dosbox.conf die CPU auf "core=full" stellen.

Dann sollten dir beim starten lauter Zeilen mit "randomInterval" um die Ohren fliegen und der Patch läuft.

Was die Benutzung des Patches angeht, ist dem nichts mehr hinzuzufügen. Da der Patch aber bisher nur Zufallswürfe überwacht, gibt es beim Anlegen von Gegenständen normalerweise keine Ausgaben. Die Berechnungen dabei sind ja deterministisch. Rüstungsschutz, AT,PA hängen ja nicht vom Zufall ab. Einzig bei der Benutzung von Zaubergegenständen wie z.B. den Stirnreifen könnte ich mir vorstellen, dass eine Probe oder zumindest die Wirkungsdauer/-stärke ausgewürfelt wird.

Die Nutzung war erstaunlich einfach, schon bei meinem Edit vorhin hatte alles wunderbar geklappt, ich habe auch noch ein wenig mit den Zufallszahlen gespielt (beim Start gab es drei Zufallswürfe oder so, die ich mir nicht erklären konnte - der für das Passwort kam später), allerdings wollte ich ja eigentlich etwas mehr sehen. Dass beim Anlegen eines Gegenstandes kein Zufallsereignis ausgelöst würde, war mir klar - da muss ich also ein anderes Hilfsmittel finden. Ich wollte erstmal den in Dosbox eingebauten Debugger nutzen, allerdings befürchte ich, dass die Arbeit damit mühsam wird, da mir das Ausgabeformat ein wenig Unverständnis entlockt und ich scheinbar noch meine Assembler-Kenntnisse erweitern muss um da mitzukommen.
Falls da noch jemand Tipps hat, höre ich mir die gern an .

Darf man fragen, was du mit dem ganzen Wissen machen willst?

(09.07.2010, 17:35)Obi-Wahn schrieb: [ -> ]Darf man fragen, was du mit dem ganzen Wissen machen willst?

Was man immer mit Wissen macht: Anhäufen und nach der Weltherrschaft greifen!

EDIT: Ich habe gerade eine Stunde im Dosbox-Debugger verbracht, ist gar nicht so unkomfortabel wie ich dachte. Da ich nicht wirklich weiß, wie ich an die Funktion komme, die beim Anlegen eines Gegenstandes aufgerufen wird (da passiert definitiv was, es dauert nämlich eine ganze Weile, bis der Vorgang abgeschlossen ist), habe ich erstmal mit einem Memorydump angefangen - in der Hoffnung, dass ich ein Array darin finde, dass seltsame Werte enthält. Bei 4MB Daten ist das leider gar nicht einfach, da ich nicht mal weiß, wie die Daten angeordnet sein mögen (den Datentyp schätze ich einfach mal auf 1 Byte Länge).
Hendrik, hast du vielleicht schon Informationen über den Speicher gesammelt? Ich habe hier doch mal was von Overlay-Funktionen gelesen. Wenn ich es vernünftig hinbekomme zu loggen, was während des Anlegens eines Gegenstandes passiert, dann wäre das natürlich auch hilfreich. Aber jetzt habe ich erstmal keine Lust mehr, morgen geht's weiter .

(09.07.2010, 18:51)thEClaw schrieb: [ -> ]

(09.07.2010, 17:35)Obi-Wahn schrieb: [ -> ]Darf man fragen, was du mit dem ganzen Wissen machen willst?

Was man immer mit Wissen macht: Anhäufen und nach der Weltherrschaft greifen!

Ein nobles Unterfangen.

(09.07.2010, 18:51)thEClaw schrieb: [ -> ]EDIT: Ich habe gerade eine Stunde im Dosbox-Debugger verbracht, ist gar nicht so unkomfortabel wie ich dachte. Da ich nicht wirklich weiß, wie ich an die Funktion komme, die beim Anlegen eines Gegenstandes aufgerufen wird (da passiert definitiv was, es dauert nämlich eine ganze Weile, bis der Vorgang abgeschlossen ist), habe ich erstmal mit einem Memorydump angefangen - in der Hoffnung, dass ich ein Array darin finde, dass seltsame Werte enthält. Bei 4MB Daten ist das leider gar nicht einfach, da ich nicht mal weiß, wie die Daten angeordnet sein mögen (den Datentyp schätze ich einfach mal auf 1 Byte Länge).

Ein guter Anfang wäre zu schauen, welche Funktion die Daten aus der ITEMS.DAT benutzt.

Die Daten daraus werden ja für die von mir gesuchten Werte gar nicht gebraucht, vermutlich wird das beim Händler wichtig, da die Infos ja nebem dem Preis auch eine Sortiments-ID enthalten. Die Datei-Zugriffe werden ja (soweit ich das sehen kann) direkt im Debug-Fenster der Dosbox angezeigt.
Momentan versuche ich noch, mitzubekommen, was beim Anlegen eines Gegenstandes alles passiert. Ich weiß nur nicht so recht, wie ich das mit dem Dosbox-Debugger schaffe - beim Loggen sämtlicher Befehle kann ich der Dosbox keinen Input mehr geben und wenn ich erst NACH dem An-/Ablegen eines Gegenstandes das Programm unterbreche, habe ich das wichtige vielleicht schon verpasst. Unterbreche ich zu früh, wird das Ereignis nicht erkannt...

Ich habe die letzten warmen Tage erstmal mit dem Schmökern in einem alten Mikroprozessor-Buch verbracht, vielleicht hilft's ja ; außerdem habe ich rausgefunden, dass DSA1 auch mit 1MB RAM läuft, hätte ich gar nicht gedacht. Und JETZT mache ich mich mal auf die Suche nach der richtigen Funktion...

Ich habe gerade eine Weile damit verbracht, zu schauen, was passiert, wenn ein Charakter eine Waffe in die Hand nimmt. Ich weiß leider nichts über das Filehandling in DOS, aber es sieht so aus, als wäre die ITEMS.DAT ständig im RAM, solange man sich im Charakterbildschirm befindet (außerhalb habe ich noch nicht geschaut).
Die AT/PA-Werte habe ich leider noch nicht gefunden, aber vielleicht stehe ich kurz davor. Auf jeden Fall bin ich auf ein paar (zumindest momentan) bemerkenswerte Dinge gestoßen:
Bewegt man einen Gegenstand im Inventar, werden sämtliche Inventarslots "abgerastert" und alle Item-Werte neu eingelesen etc. Zumindest bei diesem "Rastern" wird aber nur mit der ITEMS.DAT und einer handvoll von Werten im RAM gearbeitet.
Nachdem dann alle Slots abgefahren wurden (da bin ich momentan, berichte das jetzt nur, weil ich gespannt bin, wie es weitergeht ), werden nicht etwa AT/PA-Mali aufaddiert oder so, sondern erstmal die Größe des Charakters ermittelt. Ich habe keine Ahnung, wie das mit dem Anlegen eines Items zusammenhängen könnte...

Hier noch ein RAM-Auszug, an dem ich gerade rätsele. Hängt natürlich irgendwie mit Items zusammen. Kommt das jemandem bekannt vor? Aus einer der Dateien in der SCHICK.DAT vielleicht? Besonders markant sind natürlich die "d3 53"-Folgen.
Wäre ganz nützlich zu wissen, was mit diesen Werten genau gemacht werden kann, daher die Frage .

Das sind sicher Real-Mode Zeiger die auf die einzelnen Elemente von Arrays Zeigen.
Die Ersten 4 Bytes = Array[0] = 0x53d3:0008
Die Zweiten 4 Bytes = Array[1] = 0x53d3:000e
usw.

Guck doch mal im debugger (oder im Hexdump an Offsett: 0x53d38,0x53d3e) was sich dort befindet.

Danke für den Tipp, es mangelt mir doch noch ziemlich an Erfahrung mit dem Disassemblieren, ich musste das vorher nur ein paar Mal machen. Aber nach einem langen Tag gemütlich mit dem Disassembler spielen...es gibt doch nichts besseres!
Ich schaue gleich mal nach - außerdem will ich noch immer rausfinden, wo nun die AT/PA-Werte herkommen und was die Körpergröße damit zu tun hat .

EDIT: An der Stelle sind eine ganze Reihe von Strings im Speicher (sowas wie "bewusstlos", "krank" etc."), also nicht allzu wichtig.
EDIT2: Der Hinweis mit den Adressen war wirklich Gold wert, jetzt konnte ich innerhalb kurzer Zeit einige call-Befehle verstehen, ohne mich durch den Code zu arbeiten. Die bekommen einfach ein paar solcher Pointer übergeben (bzw. die liegen im Stack) und verändern die dortigen Werte.

Die Strings "BEWUSSTLOS", "KRANK", sind aus der Datei CHARTEXT.LTX (Zustandsübersicht, Steigerung, Outro).
Versuch mal den IDA 4.9 disassembler. Im SVN sind schon von Hendrik und und mir kommentierte Disassemblierungen.
Du findest sie unter reveng/schick.ida

IDA ist doch das Programm, dass mir halbwegs guten C-Code liefert, oder? Damit habe ich schonmal gearbeitet, war allerdings ein wenig Overkill für mich (ich selbst mag den Olly-Debugger). Hätte ich eine Ahnung, wie ich einen Disassembler mit der DOSBox nutze, hätte ich das übrigens gemacht - allerdings ist der in der DOSBox integrierte nach ein wenig Eingewöhnungszeit äußerst gut, ein paar Komfort-Funktionen fehlen mir, aber es lässt sich schön arbeiten.

Weshalb ich eigentlich was schreibe: Ich habe jetzt endlich meine Fragen geklärt und herausgefunden, wo die AT/PA bzw. RS/BE-Werte stehen .
Als kleiner Nebeneffekt hat sich nochwas geklärt, aber langsam:
Die in der ITEMS.DAT zu findenden Item-HEX-Codes waren laut FreeDSA noch nicht ganz entschlüsselt (das vierte der 12/14/16 Bytes hatte auf jeden Fall ein Fragezeichen). Dieses vierte Byte wird verwendet, um den Offset zu den von mir gesuchten Werten zu berechnen. Für eine Rüstung gibt es einen Speicherblock, der sich aus 2-Byte-Folgen zusammensetzt - das macht für jede Rüstung einen RS- und einen BE-Wert - mehr ist scheinbar mit keiner Rüstung assoziiert. Denn: Das Prinzip ist zwar bei den Waffen dasselbe, allerdings gibt es dort 7-Byte-Blöcke. Die ersten beiden Zeichen der Blöcke sind einfach der AT- und der PA-Wert. Mit dem Rest konnte ich absolut nichts anfangen, auch die Trefferpunkte usw. habe ich dort nicht gesehen. Aber irgendeine Bedeutung müssen die Bytes ja haben, sonst wären es nicht sieben dergleichen.
Kleines Problem, das mir bei ein paar der Waffen auffiel, war, dass manchmal scheinbar die AT/PA-Werte der späteren DSA-Spiele in der Liste stehen. Da ich eine modifizierte Version von Kunars Tabelle besitze, konnte ich das ganz gut vergleichen und mich darüber wundern. Vielleicht steckt ja noch irgendwo ein Bug im Programm, der da Schwierigkeiten macht...
EDIT: Hierzu noch etwas: Die Abweichungen bei den Waffenwerten beziehen sich ausschließlich auf Fernkampfwaffen, eventuell wird da etwas anders gemacht bei der letztendlichen Anwendung der Modifikatoren.
Mir fiel auch noch ein, dass Rüstungsgegenstände ja AUCH AT/PA-Modifikatoren haben - die muss ich natürlich noch suchen, denn mit der Tabelle für die Waffen werden diese nicht abgedeckt. Gibt's also doch nochwas zu tun .

Ich habe mich im Laufe der Suche nur durch ein paar hundert der vieeelen Zeilen Assembler-Code gekämpft, bin aber sogar dabei auf eine ganze Reihe von Funktionen gestoßen, die ihre Daseinsberechtigung haben. Eine von ihnen ermittelt z.B. nach dem Anlegen von Gegenständen den zugehörigen Einfluss auf AT/PA-Werte (Aufruf bei 28EA:038D) .

Ich hänge in den Anhang mal die HEX-Listen der Waffen- und Rüstungswerte, so wie sie aus dem Arbeitsspeicher (CD-Version 3.02 deutsch) kommen. Gemeinsam mit der ITEMS.DAT fällt die Zuordnung nicht schwer und es fällt auf, dass nicht etwa jeder Waffe/Rüstung eigene Werte zugeordnet sind, sondern dass alle Gegenstände in Klassen eingeteilt wurden. Es passiert z.B., dass Eisen- und Goldschild dasselbe 4. Byte in der ITEMS.DAT besitzen.

Außerdem hänge ich noch eine Text-Liste an, die ein paar Erklärungen und dieselben HEX-Werte als Text enthält. Falls die Infos irgendwann mal gebraucht werden können, sind sie somit verfügbar .

Ich find's glatt ein bisschen schade, dass mein Anreiz, weiter zu disassemblieren jetzt verschwunden ist. Hat ziemlich Spaß gemacht - aber vielleicht finde ich ja noch raus, wie magische Gegenstände funktionieren .

Sehr interessant. Eigentlich sollte man das mal systematisch angehen.
Übrigens kann ich noch den HT Editor empfehlen. IDA ist sich etwas gewöhnungsbedürftig, aber dann ein sehr praktischer Disassembler. In der DOSBox funktioniert der alte Turbodebugger, aber der ist nur noch schwer aufzutreiben.