Schicksalsklinge: Umfassender Bugfix-Patch

[NRS]

Ja, das Entfernen der Hinterteile steht noch aus. Ich bin aber tatsächlich schon etwas schlauer.

Ist abzusehen, dass das noch Erfolg haben wird? Sonst mache ich den Patch nur mit den anderen Dingen fertig.

Ich wollte eigentlich nur schnell zum neuen Jahr die von mir behobenenen kleineren Probleme erledigen, und jetzt ist schon wieder Februar, und wir reden von tiefen Eingriffen ins Kampfsystem und bekommen mittelalterliche Darstellungen von Steinschleudern gezeigt. So war das eigentlich nicht geplant.

[siebenstreich]

Es gibt jetzt einen Bugfix, der die Hinterteile in (hoffentlich!) allen Situationen entfernt.

Was ich noch nicht habe, sind die verschwundenen Leichen, wenn ein zweifeldriges Monster drüberläuft. Ich vermute, dass es in der Funktion 'draw_fight_screen' in seg002.cpp passiert. Der Name der Funktion ist irreführend, denn dort findet sowohl Kampf-Animation als auch Kampf-Logik parallel statt, wodurch es auch etwas unangenehm zu lesen ist.

[siebenstreich]

Nachtrag: Warte damit am besten noch. Denn ich glaube, der Bugfix lässt sich noch vereinfachen. Habe jetzt aber keine Zeit das zu testen, ich mache das heute abend...

[siebenstreich]

Aus der Vereinfachung wird nichts, da war ich etwas naiv.

Aber leider funktioniert noch nicht alles, wie es soll. Bei geflohenen Gegnern wird das Hinterteil jetzt entfernt, aber nicht bei Gegnern, die sich per Attacke-Patzer selber umbringen. Warum, verstehe ich im Moment noch nicht. Der Schaden wird in FIG_damage_enemy in seg041.cpp gesetzt. Und dort wird bei <= 0 LE auch das 'dead' Status-Bit gesetzt, welches mein Bugfix eigentlich abfragt.

Abgesehen davon steht in FIGHTER_CBX und FIGHTER_CBY auch nicht das drin, was ich erwarte, nämlich die Koordinaten des Hinterteils.

[siebenstreich]

1. Entfernen der Phantom-Hinterteile:
Der drei Beiträge weiter oben beschriebene Bugfix war unvollständig, denn er lässt immer noch die Hinterteile von geflohenen Gegnern am Spielfeld.

Hoffentlich korrekter Bugfix:
Diese Änderung zum Entfernen der Hinterteile von geflohenen Gegnern und diese Änderung zum Entfernen der Hinterteile von Gegnern, die sich durch einen Attacke-Patzer selber umgebracht haben.

2. Tote Gegner sind mit Skelettarius nicht mehr anwählbar, nachdem ein zweifeldriger Gegner von hinten nach vorne drübergelaufen ist.

Hierfür habe ich gerade diesen Bugfix erstellt. Die Euphorie, den Fehler endlich gefunden zu haben, ist noch frisch!

[siebenstreich]

Da muss man ja komplett was Neues einfügen. Na, das wird ein Spaß auf Binärcode-Ebene.

Das bezog sich auf diesen Bugfix. Der sollte eigentlich überflüssig sein, wenn der zweiteilige Bugfix aus Punkt 1 im letzten Beitrag implementiert ist (wozu aber auch was neues eingefügt werden muss...). Denn die Hinterteile von toten Gegnern werden damit jetzt hoffentlich alle korrekt vom Spielfeld entfernt. so dass sie der Pfadfinde-Routine nicht mehr im Weg herumliegen.

[NRS]

Sind diese Sachen jetzt eigentlich noch in meinen Patch einzuarbeiten, oder erübrigt sich das aufgrund Deiner erfolgreichen Kompilierversuche von BrightEyes?

[siebenstreich]

Naja, das musst du doch selbst entscheiden.

Das es sehr aufwändig ist, diese Dinge im Maschinencode zu korrigieren, sollte jedem klar sein.

Diese Bugfixes würden es den Leuten z.B. ermöglichen, den AP-optimalen Gorah-Kampf bugfrei zu bestreiten. Hierzu hattest du ja schon den Skelettarius repariert, aber es ist immer noch sehr schwierig weil Leichen verschwinden können wenn sie gestapelt worden sind oder wenn ein anderer Wolf drübergelaufen ist.

[NRS]

Mir ist schon klar, wozu diese Änderungen gut sind. Mir war nur der Gedanke gekommen, dass Deine BrightEyes-Kompilierung den Patch überflüssig machen könnte. Da die meisten anderen Änderungen, die der Patch vornimmt, aber nicht in BrightEyes existieren, lautet die Antwort darauf wohl nein. Ich verstehe Deine BrightEyes-Bemühungen nun also lediglich so, dass Dein Lösungsvorschlag bereits als funktionierend getestet wurde.

Vielleicht finde ich ja über Ostern Zeit, das ganze fertig zu machen, dann kann ich den Patch endlich komplett abschließen. Dass Du Dir für den Bugfix solche Mühe gemacht hast, hat mich außerdem angespornt, die Steinschleuder-Mechanik doch gemäß Deinem Vorschlag (linke Hand muss leer sein) abzuändern.

[siebenstreich]

Mir ist schon klar, wozu diese Änderungen gut sind. Mir war nur der Gedanke gekommen, dass Deine BrightEyes-Kompilierung den Patch überflüssig machen könnte. Da die meisten anderen Änderungen, die der Patch vornimmt, aber nicht in BrightEyes existieren, lautet die Antwort darauf wohl nein.

Ach so. Aber wie sollte dein Patch dadurch überflüssig geworden sein. Schon alleine wo BrightEyes doch nach wie vor als DosBox fungiert und keine SCHICKM.EXE erzeugt.

Ich verstehe Deine BrightEyes-Bemühungen nun also lediglich so, dass Dein Lösungsvorschlag bereits als funktionierend getestet wurde.

Ja, ich habe meine Bugfixes getestet und denke, dass sie tun, was sie sollen. Ansonsten gibt es da nicht viel zu verstehen: Meinen BrightEyes-Bemühungen (wie das klingt) liegt nicht etwa ein ambitionierter Dreijahresplan oder dergleichen zugrunde. Ich würde mich eher als Triebtäter bezeichnen: Ich wollte einfach wissen, wo die diskutierten Bugs herkommen. Dabei hatte ich Blut geleckt und noch etwas weitergemacht. Aber es ist desillusionierend: Wo man auch hinschaut, der nächste Bug ist nicht weit, und beim Reparieren desselben findet man zwei neue.

Aber ja, insgesamt fände ich es schon schön, wenn die bekannten Bugs auch in BrightEyes behoben wären. Vielleicht habe ich irgendwann Lust, weiterzumachen. Bei manchen deiner Bugfixes wäre es ja durchaus interessant zu wissen, wie du das konkret repariert hast. Vgl. deine Erklärung zu der Skelettarius-Geschichte, das hätte ich so schnell nicht gefunden. Wärst du bereit, auf Nachfrage Auskunft zu geben? Ach was, ich frage einfach mal ganz unverblümt: An welcher Stelle hast du denn im Kampf die Gürtel-Anlegen-Animation abgeklemmt?

Vielleicht finde ich ja über Ostern Zeit, das ganze fertig zu machen, dann kann ich den Patch endlich komplett abschließen. Als Dank für Deine weitreichenden Bemühungen habe ich mich außerdem entschlossen, die Steinschleuder-Mechanik doch gemäß Deinen Wünschen (linke Hand muss leer sein) abzuändern.

Das ist lieb, aber eigentlich wurde ich inzwischen u.a. durch mittelalterliche Illustrationen vom Gegenteil überzeugt. D.h. wegen mir musst du den Mechanismus der Steinschleuder wirklich nicht anpassen...

[NRS]

wo BrightEyes doch nach wie vor als DosBox fungiert und keine SCHICKM.EXE erzeugt

Ich dachte, es bestünde auch die Möglichkeit, bei Verwendung des ursprünglichen Borland-C++-Compilers eine SCHICKM.EXE zu erzeugen.

interessant zu wissen, wie du das konkret repariert hast. Z.B. die Skelettarius-Geschichte, das hätte ich so schnell nicht gefunden.

Frag.

An welcher Stelle hast du denn im Kampf die Gürtel-Anlegen-Animation abgeklemmt?

seg106.cpp, zu Beginn von equip_belt_ani einfügen von "if (IN_FIGHT !=0) return;".

[Obi-Wahn]

Das Ziel von HenneNWH war es, dass eine SCHICKM.EXE aus dem Code gebaut werden konnte. Siehe die letzten paar Einträge des Changelogs hier:
https://www.crystals-dsa-foren.de/showth...p?tid=3911

[siebenstreich]

Ich dachte, es bestünde auch die Möglichkeit, bei Verwendung des ursprünglichen Borland-C++-Compilers eine SCHICKM.EXE zu erzeugen.

Dass das schon funktioniert, wäre mir neu. Geplant war es von Henne als "Phase 2, Punkt 1", und er hatte wohl auch schon daran gearbeitet, siehe diesen über 4 Jahre zurückliegenden Beitrag. Danach hat der Kapitän aber wohl leider das Schiff verlassen.

An welcher Stelle hast du denn im Kampf die Gürtel-Anlegen-Animation abgeklemmt?

seg106.cpp, zu Beginn von equip_belt_ani einfügen von "if (IN_FIGHT !=0) return;".

Danke! Ich wollte das jetzt einbauen. Beim Testen konnte ich aber dem Kampfbildschirm die Animation gar nicht entlocken, weder mit Bugfix noch ohne. Ich denke, das Abspielen wird bereits die Zeile

Code:

if (ds_readb(PP20_INDEX) == ARCHIVE_FILE_ZUSTA_UK)

in seg105.cpp verhindert. Auch wenn ich nicht genau weiß, wofür PP20_INDEX steht, so vermute ich doch, dass hier getestet wird, ob man sich im Charakter-Ausrüstungs-Bildschirm befindet.

Evtl. war der Bug durch den Patch also erst hervorgerufen worden?

Nein, die damals modifizierte Abfrage, bei welchen Gegenständen eine Animation kommt, findet woanders statt.

Wenn ich oben richtig liege, dann ist der Bug doch erst durch deinen Patch entstanden. Ich vermute, dass du unter dieser Zeile in seg105.cpp einen Aufruf von equip_belt_ani() mit eingebaut hast, jedoch ohne die vorgeschaltete PP20_INDEX-Abfrage.

[NRS]

Dann brauche ich ja nur das Sprungziel beim Kraftgürtel um fünf Bytes rückwärts korrigieren, so dass die PP20_INDEX-Abfrage mit durchgeführt wird, und kann die Änderung in seg106 wieder rausnehmen.

[NRS]

Ich sehe jetzt in seg038.cpp die vorgeschlagene Änderung in FIG_find_path_to_target_backtrack (ehemals FIG_backtrack), die Wege im 60er- statt im 20er-Abstand abzulegen, nicht eingearbeitet. Heißt das, ich sollte dies unterlassen?

[siebenstreich]

Ich sehe jetzt in seg038.cpp die vorgeschlagene Änderung in FIG_find_path_to_target_backtrack (ehemals FIG_backtrack), die Wege im 60er- statt im 20er-Abstand abzulegen, nicht eingearbeitet. Heißt das, ich sollte dies unterlassen?

Die Stelle ist suspekt und ich hatte sie mal als Fehlerquelle im Verdacht. Aber mittlerweile bin ich der Meinung, dass dort letztlich nichts anbrennt. Meine Überlegungen dazu sind in diesem Beitrag, Stichwort "mehr Glück als Verstand".
D.h. wenn ich hoffentlich nicht irre, kannst du dir diese Änderung sparen.

Übrigens hab ich noch ein paar andere Sachen repariert, das meiste sind aber Nebensächlichkeiten. Bei Interesse kannst du ja mal die Commits überfliegen. Eine Überlegung könnte es vielleicht wert sein, ob man die Talent- und Zauberfertigkeitssteigerungen so anpasst wie in den original DSA-Regeln.

[NRS]

Gut, dann nehme ich das wieder raus. Edit: Nach reiflicher Überlegung über die "mehr Glück als Verstand"-Stelle habe ich mich umentschlossen und lass es doch drin, insbesondere, weil ich es schon eingebaut hatte und die Initialisierung von found_dir im selben Änderungsschritt passiert.

Fass mal lieber Deine sonstigen entdeckten Fehler in Klartextform zusammen, statt diesem doofen Quiz-Format. Das mag zwar für die anderen Leser unterhaltsam sein, für mich ist es aber eher eine Lästigkeit. Dann kann ich entscheiden, ob ich die auch noch korrigieren kann.

Edit: Die Änderung in seg032.cpp braucht 89 bytes. Das kriege ich noch irgendwie hin. Die Änderungen in seg005.cpp sind etwas schwieriger, weil sich das Segment in Hauptprogramm befindet statt einem Overlay.
Edit 2: "Original Bug 5" in seg005.cpp ist auch einfach. "Original-Bug 4" in seg005.cpp ist dagegen extremst aufwändig auf Binärebene wegen zwei zusätzlichen Funktionsaufrufen.
Edit 3: Fertig, ich hab Dir was zum Ausprobieren geschickt.

[siebenstreich]

Der Patch schaut soweit gut aus, hab ich dir ja auch per PN geschrieben. Beeindruckend, dass du das auf Maschinencode-Ebene hinbekommen hast, es waren ja teilweise etwas komplexere Änderungen.

Von mir neu gefundene Bugs habe ich wie gewünscht hier aufgelistet (incl. Rätsel 3). Wenn du davon was reparierst, wäre es nett, wenn du es mir verrätst, so dass ich es in meinem BrightEyes-Fork parallel genauso machen kann.

Außerdem gibt es noch ein paar weitere gefixte Bugs (z.B. einiges zur Alchemie) in meinem BrightEyes-Fork. U.a. auch Rätsel 1 und 2. Wie gesagt, man kann die Commits durchschauen, ich habe hoffentlich immer "bug fix" hingeschrieben. Oder man durchsucht die cpp-Dateien nach Kommentaren "Original-Bug <nr>". Angesichts des Aufwands für Maschinencode-Änderungen vermute ich, dass du das nicht alles übernehmen willst, denn es geht teilweise um Nebensächlichkeiten und an einer Stelle habe ich einen ganzen Codeblock neu geschrieben.

Ach ja, ich habe auch noch das Präprozessor-Flag M302de_FEATURE_MOD für Änderungen eingeführt, die ich machen wollte aber kein astreiner Bugfix sind. Diese sind auch mit "Feature mod <nr>" als Kommentar im Quelltext gekennzeichnet. Teilweise sind die Sachen in deinem Patch schon drin.

Feature mod 1: avoid the a posteriori weakening of the enemies of the original game. (LE set to 5/6 of the value in the enemy descriptions)

Feature mod 2: use the exact skill/spell increase mechanism as in DSA 2/3 rules.

Feature mod 3: Make the sling usable (no ammunition needed, secondary hand may be occupied with an item (like a shield)).

Feature mod 4: In the original game, when creating a savegame while not being in a temple, the AP of all heroes is decreased by 1. This feature mod stops the AP decrease.

Feature mod 5: Disable copy protection

Feature mod 6: original skill test logic as in DSA 2/3 rules (makes the skill tests and spell casting significantly harder!)

[NRS]

Beeindruckend, dass du das auf Maschinencode-Ebene hinbekommen hast, es waren ja teilweise etwas komplexere Änderungen.

Das alte Borland C++ für DOS erzeugte stellenweise derart unoptimierten Maschinencode, dass man mitunter ganze Codeblöcke einfügen kann, ohne die Länge eines Segments und damit der Datei ändern zu müssen, einfach nur, indem man den existierten Code "kürzer fasst".

Von mir neu gefundene Bugs habe ich wie gewünscht hier aufgelistet (incl. Rätsel 3).

Hm...

NRS hat mich in seinem unverwechselbaren Charme aufgefordert

Ich hab' Dich auch lieb.

Ich werde erstmal noch die Commits durchschauen, insebesondere die 99-BP-Geschichte, bevor ich mir ganz neue Dinge ansehe. Ich werde mich aber in jedem Fall auf echte Fehler oder Auslassungen beschränken, also z.B. nicht Talent-/Zaubersteigerungen nach DSA-Regeln abändern. Ansonsten käme ich wirklich vom Hundertsten ins Tausendste; man könnte dann etwa auf die Idee kommen, die Penetrizzel-Transversalis-Kombination zu unterbinden oder solche Späße.

Feature mod 5 würde ich sicherheitshalber eher wieder rausnehmen

[Crystal]

Feature mod 5: Disable copy protection

Feature mod 5 würde ich sicherheitshalber eher wieder rausnehmen

Dem stimme ich auch zu, damit ist schon JoWood auf die Nase gefallen, wenn ihr damit die Passwortabfrage meint.
Wie HenneNWH seinerzeit herausgefunden hatte, deaktivierte die deaktivierte Passwortabfrage die Auswahl des Spielmodus (Anfänger/Fortgeschritten) gleich mit, was zur Folge hatte, dass man ausschließlich im Anfängermodus spielen musste, ohne Einfluss auf die Steigerungen zu haben.