Schicksalsklinge: Umfassender Bugfix-Patch

[NRS]

ok, wenn sich die Länge der SCHICK.DAT ändert, dann verstehe ich das Problem. Ich hätte vermutet, dass man sich mit Füllzeichen behelfen kann, wenn der Text kürzer wird.

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.

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

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

Bringt aber alles nix.
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".

[Zurgrimm]

Ich vermute, dass bei Attic das Wort "Schleuder" ohne genauere Vorstellung bis zum Grafiker durchgereicht worden ist, und der hat dann halt was gemalt. Interessant wäre auch zu wissen, ob die Schleuder in der Schicksalsklinge frei erfunden wurde, oder ob sie auf dem damaligen DSA-Regelwerk basiert. Im zweiteren Fall könnte man also (entsprechenden Literaturzugang vorausgesetzt) in der Quelle nachschlagen. Die DSA-Sachen waren ja immer recht schön illustriert.

Ich weise in diesem Zusammenhang darauf hin, dass man sich in "Riva" im Spinnenbau - also einer ganz besonderen Situation mit magischem Hintergrund (Schrumpfung der Helden auf Ameisengröße) - aus Y-Ästen und Spinnenseilen selbst Schleudern bauen kann. Diese dürften wohl Zwillen sein; jedenfalls fällt es mir schwer, mir das Herumschleudern zum Schwungholen mit einem Y-Ast vorzustellen. Wahrscheinlich geht das dort, weil das Spinnenseil eine gewisse Elastizität hat. Ob es in Aventurien für normalgroße Helden ein vergleichbares Material gibt, ist mir unbekannt. Aber da es ja Riesenspinnen gibt (vgl. Blutzinnen), wäre es denkbar, dass von diesen auch hinreichend dicke, elastische Fäden von Spinnenseil für Zwillen im Normalformat gewonnen werden können. Ein solcher Gegenstand wäre dann aber sicherlich eine sehr teure Spezialität und kein Artikel, den es für ein paar Silberlinge bei jedem Krämer gibt.

[aeyol]

Die früheste mir bekannte offizielle DSA Quelle dazu ist Kaiser Retos Waffenkammer von 1993, wo von dieser Schlinge ohne Y-Holz die Rede ist (auch entsprechend illustriert). In älteren Editionen des Regelwerks war die Schleuder vielleicht noch nicht aufgeführt. Zumindest in der mir vorliegenden  Kaiser Retro [sic!] Sammlung finde ich nichts dazu. Ich gehe auch davon aus, dass man es an der Stelle mit dem Realismus einfach nicht so genau genommen hat.

[siebenstreich]

Ich weise in diesem Zusammenhang darauf hin, dass man sich in "Riva" im Spinnenbau - also einer ganz besonderen Situation mit magischem Hintergrund (Schrumpfung der Helden auf Ameisengröße) - aus Y-Ästen und Spinnenseilen selbst Schleudern bauen kann. Diese dürften wohl Zwillen sein; jedenfalls fällt es mir schwer, mir das Herumschleudern zum Schwungholen mit einem Y-Ast vorzustellen. Wahrscheinlich geht das dort, weil das Spinnenseil eine gewisse Elastizität hat. Ob es in Aventurien für normalgroße Helden ein vergleichbares Material gibt, ist mir unbekannt. Aber da es ja Riesenspinnen gibt (vgl. Blutzinnen), wäre es denkbar, dass von diesen auch hinreichend dicke, elastische Fäden von Spinnenseil für Zwillen im Normalformat gewonnen werden können. Ein solcher Gegenstand wäre dann aber sicherlich eine sehr teure Spezialität und kein Artikel, den es für ein paar Silberlinge bei jedem Krämer gibt.

Interessant und ein weiterer Hinweis, dass es sich bei der Schickalsklinge-Schleuder hinsichtlich DSA-Konsistenz wohl nicht um eine Zwille handelt.

Die früheste mir bekannte offizielle DSA Quelle dazu ist Kaiser Retos Waffenkammer von 1993, wo von dieser Schlinge ohne Y-Holz die Rede ist (auch entsprechend illustriert). In älteren Editionen des Regelwerks war die Schleuder vielleicht noch nicht aufgeführt. Zumindest in der mir vorliegenden Kaiser Retro [sic!] Sammlung finde ich nichts dazu. Ich gehe auch davon aus, dass man es an der Stelle mit dem Realismus einfach nicht so genau genommen hat.

Mein jugendlicher DSA-Enthusiasmus hat ja in letzter Zeit eine kleine Renaissace erlebt, angefacht u.A. durch die viel zu späte Entdeckung dieses Forums (was hab ich nur versäumt in all den Jahren...) und durch dieses Video. Mit dem Resultat dass ich mir kürzlich bei ebay die originale DSA1 Basis-Box geholt habe. In dem Regelbuch gibt es noch keine Schleuder. Die 6 Fernwaffen sind: Dolch, Speer, Wurfbeil, Kurzbogen, Langbogen, Armbrust. Übrigens ist dort für Dolch und Wurfbeil auch ein Nachkampfeinsatz vorgesehen, aber -- und das wollen vermutlich nicht alle hier lesen -- nicht für den Speer! Er ist eine reine Fernkampfwaffe.

In Kaiser Retos Waffenkammer war es also auch die klassische Rotations-Schleuder. Allerdings ist Kaiser Retos Waffenkammer erst 1993 rausgekommen, die Schicksalsklinge schon 1992. Deswegen kann es eigentlich nicht Grundlage gewesen sein. In Frage kämen evtl. Standard-Waffenlisten von DSA2 und DSA3.

[NRS]

Wenn ihr euch nun genug über die chemische Zusammensetzung von Steinschleudergummis, ihren Darstellungen in mittelalterlichen Gemälden und die Historie des DSA-Steinschleuderregelwerks ausgetauscht habt, dürfte ich eure geschätzte Aufmerksamkeit wieder auf das Problem des einfrierenden Kampfbildschirms lenken?

[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.

[NRS]

Hierfür müsste man soweit ich sehe Zeile 204 "arg7 &&" ersetzen durch "arg7 && (bp_needed != bp_bak-1) &&"

Also so?

Code:

if ((obj_id == bp_needed)      &&
        ((!arg7 ) ||
        (arg7 && (bp_needed != bp_bak-1) &&
                ((!host_readbs(Real2Host(ds_readd(CHESSBOARD_CPY)) + (lvar8 * 25) + lvar7)) ||
                (host_readbs(Real2Host(ds_readd(CHESSBOARD_CPY)) + (lvar8 * 25) + lvar7) == (arg8 + 10)) ||
                (host_readbs(Real2Host(ds_readd(CHESSBOARD_CPY)) + (lvar8 * 25) + lvar7) == (arg8 + 30))) &&
                (lvar8 < 24) && (lvar8 >= 0) && (lvar7 < 24) && (lvar7 >= 0))))
{

Dann hängt es bei jedem einzelnen gegnerischen Zug, kann also nicht richtig sein.

Das folgende beseitigt das Einfrieren aber anscheinend erfolgreich:

Code:

if ((obj_id == bp_needed)      &&
        ((!arg7 ) ||
        ((bp_needed == bp_bak-1) ||
                ((!host_readbs(Real2Host(ds_readd(CHESSBOARD_CPY)) + (lvar8 * 25) + lvar7)) ||
                (host_readbs(Real2Host(ds_readd(CHESSBOARD_CPY)) + (lvar8 * 25) + lvar7) == (arg8 + 10)) ||
                (host_readbs(Real2Host(ds_readd(CHESSBOARD_CPY)) + (lvar8 * 25) + lvar7) == (arg8 + 30))) &&
                (lvar8 < 24) && (lvar8 >= 0) && (lvar7 < 24) && (lvar7 >= 0))))
{

(Das "arg7" kann man sich schenken, wenn vorher "!arg7" abgefragt wurde.) Ich weiß jetzt nicht, ob es das ist, was Du meintest, oder ob ich damit die Hinterteil-Abfrage letztendlich ganz abgeknipst habe. Letztendlich verhindert es aber das Einfrieren.

Sollte man diese Lösung akzeptieren, würde aber immer noch der Fehler verbleiben, dass rätselhafterweise Felder, die eigentlich frei sein sollten wegen Tod eines Gegners trotzdem als blockiert gelten.

[siebenstreich]

Ja genau, das war ein kleiner Test ob du mitdenkst ;-)

Deine zweite Variante ist die, die ich eigentlich gemeint hatte. Das zweite arg7 kann natürlich weglassen, sieht so auch aufgeräumter aus. Das sollte mMn den Einfrier-Bug beheben.

Noch ein kleines Fazit: Der Bug hatte im Kern nichts mit der Solo-Held-Situation zu tun! Es liegt vielmehr daran, dass Kämpfe am Rand der Karte ausgetragen werden. Eine volle 6er Gruppe kann den Bug eher noch besser provozieren als ein Solo-Held, indem man die Gegner an den Rand lockt und dann gezielt das zur Flucht benötigte Drehfelder blockiert.

Sollte man diese Lösung akzeptieren, würde aber immer noch der Fehler verbleiben, dass rätselhafterweise Felder, die eigentlich frei sein sollten wegen Tod eines Gegners trotzdem als blockiert gelten.

Da hast du leider Recht. Die Hoffnung, dass die ganzen in diesem Beitrag beschriebenen komischen Symptome von einem einzigen Bug herrühren, hat sich zerschlagen. Ich vermute, du meinst das, was ich als Bug in der Entfernungsmessung bezeichnet hatte.
Richtig, der Bug tritt gerne mal im Bereich des Hinterteils eines getöteten zweifeldrigen Monsters auf. Aber nicht immer, siehe diesen Beitrag, wo zuvor lediglich ein Gegner geflohen ist. Es ist auch nicht so, dass ein Feld komplett blockiert wäre, sondern es wirkt so, als ob zwischen zwei Feldern eine unsichtbare Sperre hinzugekommen ist. Letzteres überrascht mich ziemlich, denn mein Eindruck war, dass Sperren zwischen den Feldern in der Spielmechanik eigentlich gar nicht vorgesehen sind. Z.B. sind die windigen Holzzäune in den Stadt-Kämpfen (z.B. Daspota) grafisch als zwischen zwei Feldern stehend dargestellt. Tatsächlich ist aber das komplette Feld hinterhalb des Zauns blockiert.

Es gibt außerdem noch die Sache mit dem verschobenen Pixel. Dort sehe ich auch das Potential, dass dieser aus dem Grafik-Speicherbereich hinausschreibt, wenn der Gegner sich nahe des Rands bewegt und damit der Pixel außerhalb der dargestellten Fläche landet.

[NRS]

Ja genau, das war ein kleiner Test ob du mitdenkst ;-)

Ich habe geprüft, dass die Hinterteilabfrage tatsächlich nicht ganz abgeknipst wurde. Und ja, sie wird immer noch ausgeführt, nur halt nicht mehr in dem von Dir benannten Fall.

Soll ich jetzt dann den Patch mit dieser letzten Änderung fertig machen, oder willst Du Dich noch des Problems der unsichtbaren Sperren oder des verschobenen Pixels analytisch annehmen?

[siebenstreich]

Danke für Überprüfen!

Es reizt mich ja schon, den unsichtbaren Sperren noch auf den Grund zu gehen. Eigentlich muss sich das auch im Umfeld der Datei seg038.cpp abspielen. Mal schauen.

[Obi-Wahn]

Danke siebenstreich für deinen Pull request! Jetzt müssen wir nur noch Henne aus der Versenkung wieder hervorzaubern! 

[Mandur]

Die früheste mir bekannte offizielle DSA Quelle dazu ist Kaiser Retos Waffenkammer von 1993, wo von dieser Schlinge ohne Y-Holz die Rede ist (auch entsprechend illustriert). In älteren Editionen des Regelwerks war die Schleuder vielleicht noch nicht aufgeführt. Zumindest in der mir vorliegenden  Kaiser Retro [sic!] Sammlung finde ich nichts dazu. Ich gehe auch davon aus, dass man es an der Stelle mit dem Realismus einfach nicht so genau genommen hat.

Noch ein Nachtrag:

Sie wird schon im Basisregelwerk von 1988 erwähnt, jedoch als einzige der Wurf- und Schusswaffen nicht beschrieben.

[Rabenaas]

Der Künstler meinte natürlich eine Stabschlinge (fustibalus), die zufällig so aussieht wie eine gemeine Fletsche.


(Quelle: Wikipedia)

[siebenstreich]

Danke siebenstreich für deinen Pull request! Jetzt müssen wir nur noch Henne aus der Versenkung wieder hervorzaubern! 

Ah, das hat tatsächlich jemand mitbekommen! Ja, wäre schön, wenn die Arbeit nicht umsonst gewesen wäre. Inzwischen hab ich die Datei seg038.cpp im wesentlichen verstanden, bilde ich mir zumindest ein. Alle Variablen sind jetzt in etwas vernünftiges umbenannt und ich habe auch einige Kommentare geschrieben.

Die früheste mir bekannte offizielle DSA Quelle dazu ist Kaiser Retos Waffenkammer von 1993, wo von dieser Schlinge ohne Y-Holz die Rede ist (auch entsprechend illustriert). In älteren Editionen des Regelwerks war die Schleuder vielleicht noch nicht aufgeführt. Zumindest in der mir vorliegenden Kaiser Retro [sic!] Sammlung finde ich nichts dazu. Ich gehe auch davon aus, dass man es an der Stelle mit dem Realismus einfach nicht so genau genommen hat.

Noch ein Nachtrag:
Sie wird schon im Basisregelwerk von 1988 erwähnt, jedoch als einzige der Wurf- und Schusswaffen nicht beschrieben.

Interessant, vielen Dank! Also gibt es die Schleuder im Basisregelwerk von DSA2, aber nicht von DSA1.

[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;
}

[Arbosh]

Ah, das hat tatsächlich jemand mitbekommen! Ja, wäre schön, wenn die Arbeit nicht umsonst gewesen wäre. Inzwischen hab ich die Datei seg038.cpp im wesentlichen verstanden, bilde ich mir zumindest ein. Alle Variablen sind jetzt in etwas vernünftiges umbenannt und ich habe auch einige Kommentare geschrieben.

Bei der Übersetzung ist in der common.h ein kleiner Fehler unterlaufen: Bit 2 von HERO_STATUS_1 sollte von "versteinert" nicht in "stoned" übersetzt werden sondern "petrified". Ich glaub die Ausrüstungsgegenstände für "stoned" finden sich in Schick eher nicht 

[siebenstreich]

Ah, das hat tatsächlich jemand mitbekommen! Ja, wäre schön, wenn die Arbeit nicht umsonst gewesen wäre. Inzwischen hab ich die Datei seg038.cpp im wesentlichen verstanden, bilde ich mir zumindest ein. Alle Variablen sind jetzt in etwas vernünftiges umbenannt und ich habe auch einige Kommentare geschrieben.

Bei der Übersetzung ist in der common.h ein kleiner Fehler unterlaufen: Bit 2 von HERO_STATUS_1 sollte von "versteinert" nicht in "stoned" übersetzt werden sondern "petrified". Ich glaub die Ausrüstungsgegenstände für "stoned" finden sich in Schick eher nicht 

Hehe.

Das Problem ist: Der Programmcode ist vielfach denglisch. Man muss immer wieder mal wörtlich auf Deutsch übersetzen, um zu erahnen, was der Verfasser gemeint hat. Es heißt schon an einigen anderen Stellen im Quellcode 'stoned', so dass es jetzt zumindest einheitlich ist.

Anderes Beispiel: Das Wort "zweifeldrig" (im Zusammenhang mit zweifeldrigen Gegnern wie Wölfen, Hunden etc.) heißt auf englisch bestimmt nicht twofielded. Im Programmcode findet man das Wort aber oft genug. Insgesamt ist wohl ein Feld auf dem Kampfbildschirm eher mit 'square' zu übersetzen. Zumindest in seg038.cpp hab ich jetzt anstelle von two_fielded lieber 'two_squares' geschrieben, bin aber nicht 100%ig überzeugt. Zum einen mit der Wortwahl (da gibt es bestimmt besseres im englischen), und zum anderen, weil es jetzt uneinheitlich ist.

Eigentlich fände ich es ja besser, wenn so was einfach auf Deutsch gemacht werden könnte. Das Spiel ist deutsch, und die Leute die sich damit beschäftigen scheinen bisher alle deutschsprachig zu sein. Aber in Bright Eyes wurde eine andere Entscheidung getroffen.

[siebenstreich]

Zum 99 BP-Bug muss ich zurückrudern. Was ich 3 Beiträge weiter oben geschrieben habe, stimmt nicht so recht. Insbesondere wird der vorgeschlagene Bugfix nicht funktionieren, also bitte vergessen!

Die Funktion FIG_backtrack terminiert Pfade, die ihr Ziel erreichen mit einer Endmarke -1. Anders als von mir zuvor behauptet werden Pfade zu einem Ziel, das mit den vorhandenen BP nicht erreicht werden kann, mit dem Doppeleintrag [-1, -2] terminiert. Bei dem Bug wird ja fälschlicherweise "ZIEL: 99 BP" ausgegeben. Die Zahl 99 muss meiner Meinung nach aus der Funktion Funktion FIG_move_pathlen in seg034.cpp stammen, weil ich nicht sehe, wo sie sonst produziert werden könnte. In dieser Funktion wird bei der zweiten Variante der Terminierung (also [-1,-2]) 99 zurückgegeben. Zuerst dachte ich, dass evtl. Reste des vorherigen Pfads im Speicher etwas durcheinanderbringen könnten, wenn zufällig noch ein -2 an der entscheidenden Stelle hinter einer geschriebenen Endmarke -1 steht. Aber ich hatte übersehen, dass die Einträge des Pfads vor der Neuberechnung per memset auf 0 gesetzt werden.

Mir ist schleierhaft, wie es beim Aufruf von FIG_move_pathlen in seg034.cpp zur Ausführung der Zeile GUI_print_string(problem == 1 ? get_tx(13) ...) dazu kommen kann, dass die "ZIEL: BP..."-Meldung ausgegeben wird.
Denn das hängt von der Variable 'problem' ab. Die davor stehende if .. else if .. else if ... Serie zum Setzen von problem ist etwas unübersichtlich, aber ich sehe nicht, wie in den beobachteten Fällen des Bugs problem==0 überleben soll.

[siebenstreich]

So, man muss sich nur konzentrieren: Die Variable 'problem' wird nicht gesetzt, wenn auf dem Zielfeld ein totes Monster oder ein toter/bewusstloser Held ist. Ich habe das auch verifiziert: Wenn man beim Bewegen ein Feld mit einem toten Monster anwählt, das sich außerhalb der Reichweite befindet, dann steht da tatsächlich 99 BP. Der Bug, von dem ich geglaubt hatte dass er alle heiligen Zeiten mal auftritt, ist also recht leicht zu reproduzieren.

Die Frage ist halt, ob das schon die volle Erklärung sein kann. Im vorletzten Screenshot in diesem Beitrag ist das Zielfeld leer, da ist kein totes Monster. Aber vielleicht liegt da trotzdem was, nur unsichtbar.

Das würde ein wenig zu meinem aufkeimenden Verdacht passen, dass der Bug mit den unsichtbaren Sperren mit irgendwelchen Artefakten von zweifeldrigen Gegnern zusammenhängen könnte. Wer weiß, vielleicht liegt da das unsichchtbare Hinterteil eines geflohenen Steppenhunds?

[siebenstreich]

Hier der Bugfix zum 99BP-Bug in meinem Fork von BrightEyes.

Der Bug hatte also per se nichts mit zweifeldrigen Gegnern zu tun. Das passt auch zum ursprünglichen Bericht von Zurgrimm vom Heiligabend vor gerade mal 14 Jahren, der den Bug in einem Daspota-Kampf beobachtet hatte, wo es meines Wissens keine zweifeldrigen Gegner gibt.