08.01.2021, 02:45
(Dieser Beitrag wurde zuletzt bearbeitet: 08.01.2021, 12:40 von siebenstreich.)
(06.01.2021, 14:06)NRS schrieb: seg032-seg045.cpp, insbesondere in seg043.cpp und vor allem Prozedur seg038 in seg038.cpp. Wenn Du daraus schlau wirst, bitte sehr. Das "Einfrieren" das Kampfbildschirms geschieht in seg038.cpp, Prozedur FIG_backtrack, in der "while (done==0)"-Schleife.
Wie gesagt habe ich jetzt tatsächlich in den Code von BrightEyes geschaut. Vorwarnung: Zum ersten Mal. Ich habe keinerlei Wissen über globalere Datenstrukturen und Zusammenhänge und ich muss auch zugeben, das ganze ist wahrlich keine leichte Kost. Also, folgendes habe ich mir bisher zusammengereimt.
Die Hauptfunktion der Datei seg038.cpp heißt sinnigerweise seg038. Deren Parameter sind:
ptr_in: Zeiger auf den akuellen Charakter (Held / Gegner).
a1: Die Nummer des aktuellen Charakters in der Liste aller Kampfteilnehmer.
x_in, y_in: Die Koordinaten des Charakters auf dem Kampffeld.
a4: Der aktuelle Modus des Charakters, eine Zahl zwischen 0 und 9, deren Bedeutung habe ich nicht genauer nachvollzogen.
In der Funktion seg038 wird eine Entfernungstabelle aufgebaut. Diese wird im Bereich DTP2 im Datensegment abgelegt. In der Funktion verweist der Pointer ptr2 auf deren Anfang. Anfangs werden alle Einträge auf -1 sowie der für die Position des Charakters auf 0 gesetzt. Die Variable l_var2 steht für die Distanz zum Charakter und zählt sukzessive rauf. Damit wird die Tabelle per Breitensuche gefüllt. Blockierte Felder erhalten den Eintrag 100. Beim Aufbau werden gewisse, für die aktuelle Aktion relevante erreichbare Zielfelder markiert. Deren Koordinaten werden in arr1 und arr2 abgelegt. Der Aufbau der Entfernungstabelle wird abgebrochen wenn in im letzten Schleifendurchlauf (also zur letztkleineren Distanz) relevante Zielfelder gefunden wurden (l_var1 == 0), oder keine neuen erreichbaren Felder mehr dazugekommen sind (l_var3 != 0) oder schon die Distanz 50 untersucht wurde (l_var2 < 50). Außerdem bricht die Schleife sofort mit einem break ab, wenn 10 relevante Zielfelder gefunden wurden (l_si == 10).
Die erstellte Entfernungstabelle enthält nur die Distanzen zu den Feldern, aber nicht den genauen Weg (also die Richtungsabfolge) dorthin. Die Wegberechnung zu den relevanten Zielfeldern erfolgt in der Funktion FIG_backtrack.
ACHTUNG: Diese Funktion hat per se nichts mit Flucht zu tun! Vielmehr leitet sich der Namensbestandteil "backtrack" aus dem dort stattfindenden Backtracking über die Entfernungstabelle ab: Vom anvisierten Zielfeld aus wird rückwärts via Entfernungstabelle der kürzeste Weg zum Charakter bestimmt.
Die Parameter der Funktion FIG_backtrack sind:
in_ptr: Zeiger auf die erstellte Entfernungstabelle, müsste also wieder DTP2 im Datensegment sein.
target_x, target_y: Die Koordinaten des Ziels.
bp_needed: Der zuvor berechnete Abstand des Charakters zum Ziel.
bp_avail: Die aktuell vorhandenen Bewegungspunkte des Charakters.
arg6: der Modus (also die Zahl zwischen 0 und 9)
arg7: zweifeldriger Charakter (ja/nein?)
arg8: die Nummer des Charakters in der Liste aller Kampfteilnehmer.
Die Suche läuft einmal für jede Startrichtung i. Dabei wird immer so gesucht, dass nach Möglichkeit keine Kurve gelaufen wird (Initialisierung dir = i). Die Strategie ist natürlich, ein Nachbarfeld des Zielfelds zu finden, für das die Entfernung um 1 kleiner ist (Bedingung obj_id == bp_needed). Wenn der Kampf hier in der Endlosschleife festhängt, dann wird irgendwie kein solches Feld gefunden und er rotiert immer und immer wieder alle möglichen 4 Richtungen 'dir' durch. Warum das passieren kann, ist mir noch nicht klar. Die zweifeldrige Bewegung wird in dem Block "arg7 && ..." in den Zeilen 204-208 behandelt. Diese kryptischen Zeilen hab ich noch nicht so recht verstanden. Dort wird geprüft ob das um 1 weiter entferntere Nachbarfeld mit den Koordinaten lvar8 und lvar7 frei ist, für das Hinterteil des zweifeldrigen Gegners. Außerdem werden gewisse Einträge auf der Kampfkarte CHESSBOARD_CPY abgeprüft. Dabei geht es um Werte, die von der Nummer arg8 des Charakters abhängen (arg8 + 10 bzw. arg8 + 30). Was die bedeuten, weiß ich bisher nicht. Evtl. ist eins von den beiden das Hinterteil. Diese Zeilen haben recht identisch ausschauende Entsprechungen in der Entfernungsberechnung in seg038 (Zeilen 524-528, 570-574 und 597-601).