Schicksalsklinge: Umfassender Bugfix-Patch

[siebenstreich]

Man müsste Leerzeichen als Füllzeichen nehmen, die dann entsprechend hässlich aussehen. Den String früher mit $00 zu terminieren läuft nicht, da attics ".LTX"-Format bei jedem $00-Zeichen automatisch beim Parsen die Stringnummer erhöht.

Danke, damit verstehe ich den Zusatzaufwand.

Wegen Kampf habe ich jetzt folgende Änderungen durchgeführt:

    doppelte lvar_5 in lvar_4 geändert;
    in FIG_backtrack die Wege im 60er- statt im 20er-Abstand abgelegt;
    in FIG_backtrack "found_dir" mit 0 initialisiert.

Bringt aber alles nix.

Danke, dass du das ausgetestet hast. Die Änderungen sind in jedem Fall vernünftig, auch wenn es unseren Bug nicht behebt (womit ich auch nicht gerechnet hatte). Wer weiß, vielleicht ist durch das Vorinitialisieren von found_dir der Bug behoben, der bei mir mal einen Piraten-Kampf (ohne zweifeldrige Monster) zum Absturz brachte?

Ich glaube, man muss sich genau anschauen, was in "seg038" bezüglich "two_fields" gemacht wird und was das in der Konsequenz für FIG_backtrack bedeutet. "two_fields" ist ja der vorletzte Parameter von FIG_backtrack, also "arg7".

Ich habe jetzt nochmal einige Zeit in den Quellcode gestarrt und ich glaube, ich habe den Bug gefunden.

In FIG_backtrack sind ja die Zeilen 204-208 für die zusätzliche Einschränkung der zweifeldrigen Bewegung zuständig, nämlich dass das Hinterteil Platz haben muss. Für zweifeldrige Gegner wird diese Hinterteil-Bedingung ausnahmslos für jeden einzelnen Schritt der Wegberechnung abgeprüft.
Beim vorherigen Aufbau der Entfernungstabelle in der Funktion seg038 steht das Gegenstück der Hinterteil-Bedingung in den Zeilen 523-528. Beim Markieren der relevanten Zielfelder allerdings wird die Hinterteil-Bedingung nicht immer abgeprüft. Sie steht in den Zeilen 570-574 und 597-601, aber in den Zeilen 536, 547, 559, 586 und 620 fehlt sie. Für welche Situation diese einzelnen Codestellen genau stehen weiß ich nicht, dafür müsste man sich mit den ids der CHESSBOARD-Einträge und den Modus-ids (gespeichert in a4) auskennen.
Meine Vermutung ist nun, dass eines dieser relevanten Zielfelder ein Fluchtfeld im Modus Flucht ist, bei dem die Hinterteil-Bedingung *nicht* abgeprüft wird. Der Funktion FIG_backtrack gelingt es nun u.U. nicht, einen gültigen Schritt zu dem Zielfeld zu finden, weil sie ja die Hinterteil-Bedingung strikt berücksichtigt.

Das würde jedenfalls die beiden Screenshots von eingefrorenen Kämpfen in diesem Beitrag erklären. Die aktiven Gegner stehen direkt am Rand und wollen mutmaßlich fliehen. Ohne die Hinterteil-Bediungung können sie das mit einem einzigen BP. Aber mit der Hinterteil-Bedingung können sie es nicht (zumindest nicht mit 1 BP), denn in beiden Fällen verhindert der Kopf eines Artgenossen das Drehen in die Zielrichtung.

Welche Repaturmöglichkeiten gibt es?

(1)
An den oben genannten 5 Codestellen wird die Hinterteil-Bedingung mit eingefügt. Nur solange man nicht genau weiß, für welche Situationen diese Codestellen eigentlich stehen, sollte man vielleicht auch nicht daran herummodifizieren.

(2)
Die Hinterteil-Bedingung in FIG_backtrack wird deaktiviert.
Auch dann wird jeder zweifeldrige Gegner nur Felder erreichen können, die er auch mit der Hinterteil-Bedingung erreichen kann (abgesehen von der Sache mit den relevanten Zielfeldern).
Allerdings kann es passieren, dass eine nicht Hinterteil-konforme Route gewählt wird, bei der also das Hinterteil mit irgendwelchen Hindernissen kollidiert.
Diese Situationen dürften aber ziemlich selten sein.

(3)
Vermutlich besser als (2): Die Hinterteil-Bedingung in FIG_backtrack wird nur für den ersten Backtrack-Schritt deaktiviert.
Damit läuft dann der Schritt auf das Zielfeld ohne die Bedinung, der Rest aber mit.
Hierfür müsste man soweit ich sehe Zeile 204 "arg7 &&" ersetzen durch "arg7 && (bp_needed != bp_bak-1) &&"


Noch ein kleines Kuriosum, das mir beim Studium der Hinterteil-Bedinung bewusst geworden ist:
Steht ein zweifeldriger Gegner mit dem Kopf an einer durchgehenden Wand, dann kommt er von der Wand nicht mehr weg.
Gleiches gilt für den Rand der Kampfkarte.