17.01.2021, 03:31
(Dieser Beitrag wurde zuletzt bearbeitet: 17.01.2021, 03:33 von siebenstreich.)
Ich habe mir jetzt einige Zeit den Schädel über die Datei seg038.cpp zerbrochen und bilde mir ein, dass ich das wesentliche dort verstanden habe. Das ist stellenweise schon eine ziemliche Flickschusterei, was die damals zusammenprogrammiert haben. Eine Variable wird doppelt angelegt und parallel geführt. Andere Variablen werden fleißig beschrieben, obwohl sie hinterher nie ausgelesen werden bzw. nur in einer Art und Weise, dass man sich die Information auch anders leicht ableiten hätte können. Jedenfalls ist das der perfekte Nährboden für die Art von Bugs, der wir hier hinterherrennen.
Die Ursache der unsichtbaren Sperren habe ich leider nicht gefunden. Man muss wohl in seg034.cpp weiterlesen, wo die Funktion seg038 (hab ich in meinem Fork jetzt in FIG_find_path_to_target umbenannt) in der Funktion FIG_move_hero für die Helden-Bewegung aufgerufen wird. Aber evtl. habe ich die Herkunft der manchmal erscheinenden 99 BP gefunden. Wenn mich nicht alles täuscht, wird in FIG_backtrack der Pfad mit -2 terminiert (und nicht mit -1), wenn die Bewegungspunkte nicht ausreichen, das Ziel zu erreichen. Anders kann kein Eintrag -2 im Pfad landen. In FIG_move_pathlen in seg034.cpp wird aber darauf getestet, ob der Pfad mit der Symbolfolge -1, -2 terminiert wird, das passt also nicht zusammen. Außerdem wird an letzterer Stelle potentiell um eins über das hintere Ende des zuvor von FIG_backtrack geschriebenen Pfads hinausgelesen, so dass es evtl. passieren kann, dass eine zufällig in einem früheren FIG_backtrack-Durchlauf an die entscheidende Stelle geschriebene -2 den Ausschlag geben kann. In dem Fall wird Pfadlänge 99 zurückgegeben.
Eigentlich muss die 99 von dort herkommen, denn ich sehe nicht, wo sie sonst entstehen soll. Aber die Logik in seg034.cpp überblicke ich noch nicht so recht. Warum gibt es hier überhaupt einen Fall, der 99 zurückgibt, wofür soll das gut sein? Man könnte einfach mal probieren, die Funktion FIG_move_pathlen wie folgt abzuändern:
signed short FIG_move_pathlen(void)
{
signed short i = 0;
while (ds_readbs(FIG_MOVE_PATHDIR + i) >= 0) {
i++;
}
return i;
}
Die Ursache der unsichtbaren Sperren habe ich leider nicht gefunden. Man muss wohl in seg034.cpp weiterlesen, wo die Funktion seg038 (hab ich in meinem Fork jetzt in FIG_find_path_to_target umbenannt) in der Funktion FIG_move_hero für die Helden-Bewegung aufgerufen wird. Aber evtl. habe ich die Herkunft der manchmal erscheinenden 99 BP gefunden. Wenn mich nicht alles täuscht, wird in FIG_backtrack der Pfad mit -2 terminiert (und nicht mit -1), wenn die Bewegungspunkte nicht ausreichen, das Ziel zu erreichen. Anders kann kein Eintrag -2 im Pfad landen. In FIG_move_pathlen in seg034.cpp wird aber darauf getestet, ob der Pfad mit der Symbolfolge -1, -2 terminiert wird, das passt also nicht zusammen. Außerdem wird an letzterer Stelle potentiell um eins über das hintere Ende des zuvor von FIG_backtrack geschriebenen Pfads hinausgelesen, so dass es evtl. passieren kann, dass eine zufällig in einem früheren FIG_backtrack-Durchlauf an die entscheidende Stelle geschriebene -2 den Ausschlag geben kann. In dem Fall wird Pfadlänge 99 zurückgegeben.
Eigentlich muss die 99 von dort herkommen, denn ich sehe nicht, wo sie sonst entstehen soll. Aber die Logik in seg034.cpp überblicke ich noch nicht so recht. Warum gibt es hier überhaupt einen Fall, der 99 zurückgibt, wofür soll das gut sein? Man könnte einfach mal probieren, die Funktion FIG_move_pathlen wie folgt abzuändern:
signed short FIG_move_pathlen(void)
{
signed short i = 0;
while (ds_readbs(FIG_MOVE_PATHDIR + i) >= 0) {
i++;
}
return i;
}