Schicksalsklinge: Umfassender Bugfix-Patch

[Alrik Alrikson]

Zusätzlich zu den hier genannten Problemen beseitigt die nun angehängte Beta-Version des Patches folgende Probleme:

• Programmabsturz beim gescheiterten Versuch, geschützte Truhen zu öffnen, insbesondere die Heshtot-Truhe auf dem Totenschiff sowie eine Truhe im Alten Ugdalf
  
• Programmfehler nach Gürtelanlegen-Animation während eines Kampfes. In dieser Situation wird künftig einfach keine solche Animation mehr gezeigt.
  
• Fehlende Textfenster zu verhungernden oder verdurstenden Helden
  
• Oberorken-Zwergenfeste: Türen zur Wasserfalle fallen auch nach Entschärfung der Falle immer wieder zu
  
• Räuberlager im Alten Ugdalf: Waffen können nur beim ersten Betreten des Raumes mitgenommen werden
  

Anwendung wie bei vorherigen Versionen. Ich werde diese neue Version erst nach positiver Rückmeldung freigeben, und auch erst dann den Patch zur Schiffsreisemusik anpassen.

So, habe nun alles ausprobiert, der Patch beseitigt die genannten Fehler.

Einzig auffällig war, dass ich es nicht provozieren konnte, die Helden verdursten zu lassen. Selbst ohne Getränke im Gepäck, ohne Jagd/Wasserauffüllen im Lager und einer wochenlange Reise im Gebirge ohne Fluss in der Nähe wurde der Durstbalken nach dem Nachtlager jedesmal von ca. 75 % auf ca. 25 % Durst zurückgesetzt. Verhungern klappt aber und die entsprechenden Textboxen (hungrig / verhungert) kommen.

[siebenstreich]

Ich nehme den neuen Patch mit offener Kinnlade zur Kenntnis. Damit hätte ich nicht gerechnet. Danke!!

Ich werde die folgenden Fehler korrigieren:
Bug: Anlegen des Körperkraft-Gürtels während des Kampfs per "Gegenstand wechseln" führt zu einem kaputten Programmzustand.

Gerade habe ich in der Beschreibung einer älteren Version dieses Patchs folgendes gefunden: "Hier die Liste aller Dinge, die ich bislang korrigiert habe. [...] Fehlende Animation bei Anlegen des Kraftgürtels". Evtl. war der Bug durch den Patch also erst hervorgerufen worden? (zumindest für den Körperkraft-Gürtel; den Totenkopf-Gürtel habe ich nie getestet)

[...] sehe den Aufwand in keinem Verhältnis zum Nutzen stehend (z.B. [...] Steinschleuder [...])

Das enttäuscht mich etwas. Mag sein, dass hier persönliche Sentimentalität mitschwingt: Als Kind hatte ich damals ewig und ewig nach Munition für die Schleuder gesucht und die Hoffnung nie so ganz aufgegeben. Wie oben geschrieben würde eine funktionierende Schleuder (insbesondere ohne Abhängigkeit von Munition) das Spiel aber auch objektiv gesehen bereichern.
Der dumme Speer wurde schließlich auch repariert, und ich mag wetten, dass den trotzdem niemand hernimmt (mimimi...)

Ich frage mich: Was passiert eigentlich im Programm, wenn man versucht, die Schleuder im Kampf zu benutzen? Wird hier etwas abgeprüft, bevor die Ausgabe "... HAT KEINE STEINE IN DER LINKEN HAND." erscheint? Ist der weitere erforderliche Programmcode zum Abfeuern der Schleuder vielleicht schon vorhanden, so dass nur diese Abfrage umgebogen werden müsste?

[...] sehe den Aufwand in keinem Verhältnis zum Nutzen stehend (z.B. [...] Entfernungsangaben bei Kampf gegen zweifeldrige Gegner [...])

Ich stimme völlig zu, dass es kein großes Problem wäre, wenn nur die Anzeige falsch ist. Ich habe aber zunehmend den Verdacht, dass hier ein Zusammenhang zu anderen, schwerwiegenderen Fehlerbildern besteht. Dazu schreibe ich gleich noch etwas in einem neuen Beitrag.

Ein Kampf gegen bis zu drei Oger existiert auch ohne weitere Änderung als zufälliger Wildniskampf (Nr. 244, "WILD2"). Bei Wildniskämpfen ist sowohl die Auswahl der Kampfnummer als auch die tatsächliche Anzahl der Gegner zufallsabhängig.

Wenn es so ist, dann nehme ich alles zurück.

Aber irgendwie überrascht es mich. Ich kann mich nicht daran erinnern, jemails in einem Wildniskampf 3 Ogern begegnet zu sein. Es gibt in den Dateien ja wohl auch Kämpfe, die im Spiel nie aufgerufen werden. Der Kampf WILD2 kann also wirklich mit drei Ogern stattfinden?

[siebenstreich]

Bug: Kampfbildschirm friert ein, siehe diesen Beitrag.

Der Bug ist zwar nicht immer reproduzierbar, aber mit dem dort angehängten Spielstand sollte man den Bug oft provozieren können, wenn man im Kampf so vorgeht wie beschrieben.

Ich vermute einen Zusammenhang zu zweifeldrigen Gegnern und evtl. zur weiter oben schon diskutierten falschen Abstandsberechnung. Evtl. auch zu den Bugs, die im Vorgänger des oben zitierten Beitrags aufgelistet sind:

Bug: Gegnerisches Feld kann betreten werden und
Bug: Hinterteil eines zweifeldrigen Monsters ragt über den Rand der Kampfkarte hinaus.

Von einem Einfrieren des Kampfmodus wurde auch schon an anderen Stellen im Forum berichtet. Wenn dieser Bug noch dingfest gemacht werden könnte, wäre es eine größere Geschichte!

[NRS]

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.

Als Kind hatte ich damals ewig und ewig nach Munition für die Schleuder gesucht und die Hoffnung nie so ganz aufgegeben. Wie oben geschrieben würde eine funktionierende Schleuder (insbesondere ohne Abhängigkeit von Munition) das Spiel aber auch objektiv gesehen bereichern.

Es wird, analog zu Pfeil und Bolzen bei Bogen und Armbrust, bei der Schleuder ein Gegenstand mit Nummer 999 in der linken Hand abgefragt, den es natürlich gar nicht gibt; die Nummer 999 stellt einen Platzhalter dar.

Von einem Einfrieren des Kampfmodus wurde auch schon an anderen Stellen im Forum berichtet. Wenn dieser Bug noch dingfest gemacht werden könnte, wäre es eine größere Geschichte!

Ich verstehe das Problem, aber ein Wegfinder-Algorithmus ist von Natur aus eine sehr komplizierte Angelegenheit. Und beim genannten Fehler handelt es sich dem Grunde nach um einen logischen Fehler, nicht einfach um eine vergessene oder verdrehte Abfrage wie bei den meisten anderen Fehlern. Selbst mit Hilfe von BrightEyes würde ich da wahrscheinlich drei Monate dran sitzen, falls ich überhaupt auf einen grünen Zweig käme. Wenn sich jemand anderes den entsprechenden Code in BrightEyes ansähe und dem logischen Fehler dort auf die Spur käme, so dass ich die Lösung nur noch im Objektcode implementieren müsste, könnten wir darüber reden. Aber einfach nur so wird das nichts.

Der Kampf WILD2 kann also wirklich mit drei Ogern stattfinden?

Code:

Fight 244: WILD2
- 01: OGER..
- 01: OGER..
- 01: OGER..

Code:

seg117.cpp:
void random_encounter(signed short arg)
{
(...)
                        ds_writew(MAX_ENEMIES, random_schick(3));
                        do_fight(FIGHTS_WILD2);

Ich habe aber eine andere "gute" Neuigkeit: jetzt wurde auch ich plötzlich aus der Herberge zwischen Prem und Skjal rausgeworfen, obwohl ich nie vorher drin war.

[siebenstreich]

Es wird, analog zu Pfeil und Bolzen bei Bogen und Armbrust, bei der Schleuder ein Gegenstand mit Nummer 999 in der linken Hand abgefragt, den es natürlich gar nicht gibt; die Nummer 999 stellt einen Platzhalter dar.

ok, und was passiert, wenn man die Nummer 999 auf die ID eines existierenden Gegenstands (z.B. Pfeil) umändert und dem Helden diesen Gegenstand in die linke Hand gibt? Ist das Auslösen der Schleuder dann weiter implementiert? Falls ja, könnte sie eigentlich recht einfach aktiviert werden.

Ich verstehe das Problem, aber ein Wegfinder-Algorithmus ist von Natur aus eine sehr komplizierte Angelegenheit. Und beim genannten Fehler handelt es sich dem Grunde nach um einen logischen Fehler, nicht einfach um eine vergessene oder verdrehte Abfrage wie bei den meisten anderen Fehlern. Selbst mit Hilfe von BrightEyes würde ich da wahrscheinlich drei Monate dran sitzen, falls ich überhaupt auf einen grünen Zweig käme. Wenn sich jemand anderes den entsprechenden Code in BrightEyes ansähe und dem logischen Fehler dort auf die Spur käme, so dass ich die Lösung nur noch im Objektcode implementieren müsste, könnten wir darüber reden. Aber einfach nur so wird das nichts.

Wie gesagt, ich habe größten Respekt vor dem, was du da tust, also dass du compilierten Maschinencode reparierst. Ich verstehe auch, dass man damit nicht einfach so einen von der Logik her falsch implementierten Wegfinde-Algorithmus reparieren kann.

Aber: Meinem Eindruck nach funktioniert dieser Algorithmus prinzipiell. Auch bei zweifeldrigen Monstern: Zu Beginn des Steppenhund-Kampfs erscheint mir die Bewegung der Hunde so weit ganz vernünftig (zumindest soweit man die Kampf-AI in Schicksalsklinge als vernünftig bezeichnen will...), und auch die BP-Berechnungen beim Bewegen stimmen alle. Aber nach einiger Zeit treten seltsame Symptome auf. Plötzlich sind da unsichtbare Sperren, wo zuvor noch Gegner und Helden normal drübergelaufen sind. Plötzlich kommt kein Gegner mehr näher, obwohl genug Platz da wäre. Plötzlich kann ich das Kopffeld eines Hundes betreten. Und plötzlich friert der ganze Kampf ein, das ist die ärgerlichste aller Varianten.

Das wirkt auf mich eher wie ein Bug, der qualitativ mit den Dingen vergleichbar ist, die du schon repariert hast. Vielleicht wird irgendwo in der Berechnung eine Grenze nicht eng genug gezogen, so dass im Zusammenhang mit dem Drehen von zweifeldrigen Gegnern irgendwas außerhalb des vorgesehenen Datenbereichs überschrieben wird? Irgend sowas.

Natürlich kann es immer noch höllisch schwierig sein, einen solchen Fehler zu finden.

Der Kampf WILD2 kann also wirklich mit drei Ogern stattfinden?

Code:

Fight 244: WILD2
- 01: OGER..
- 01: OGER..
- 01: OGER..

Code:

seg117.cpp:

void random_encounter(signed short arg)
{
(...)
ds_writew(MAX_ENEMIES, random_schick(3));
do_fight(FIGHTS_WILD2);

ok, danke! Wenn die unteren beiden Zeilen dann auch wirklich durchlaufen werden können, bin ich überzeugt.

[NRS]

Ich habe versucht, den Wegfinde-Algorithmus in BrightEyes zu verstehen, und bin gescheitert. Du kannst ja Henne mal fragen, ob ihm was dazu einfällt, was ich dann nur noch umsetzen muss, aber von mir wird da wohl nichts mehr kommen.

Den Patch habe ich überhaupt nur noch mal angefasst, um das vom Patch neu erzeugte Problem mit der Heshtot-Truhe auf dem Totenschiff zu korrigieren. Und da ich schon mal dabei war, habe ich noch ein paar andere Kleinigkeiten verbessert. Ich werde mich aber nicht nochmal mehrere Monate insgesamt hinsetzen und mehrere Wochen lang an einer einzigen Sache basteln, wie ich es einst beim Skelettarius-Fehler oder den diversen Fehlern bei der Behandlung mehrerer Teilgruppen gemacht habe. Diese Zeiten sind vorbei.

Das mit der Entfernung der Steinschleuder-999er-Abfrage kann ich noch versuchen und eventuell das mit der Herberge, aber für größere Dinge fehlt mir einfach die Zeit, und ehrlich gesagt auch die Lust.

[siebenstreich]

Ich habe versucht, den Wegfinde-Algorithmus in BrightEyes zu verstehen, und bin gescheitert. Du kannst ja Henne mal fragen, ob ihm was dazu einfällt, was ich dann nur noch umsetzen muss, aber von mir wird da wohl nichts mehr kommen.

Ich fürchte, Henne ist weder auf Empfang noch auf Sendung seit einiger Zeit. Kannst du mir mal verraten, wo in BrightEyes der in Frage kommende Code steht?

Das mit der Entfernung der Steinschleuder-999er-Abfrage kann ich noch versuchen

Das wäre wirklich sehr schön!

und eventuell das mit der Herberge, aber für größere Dinge fehlt mir einfach die Zeit, und ehrlich gesagt auch die Lust.

Das ist natürlich legitim und komplett nachvollziehbar. Dein Patch ist der Wahnsinn und macht aus der Schicksalsklinge ein viel besseres Spiel. Ich finde es großartig, dass du hier wieder vorbeischaust und diskutierst und deinen Patch nochmal anfasst.

(Noch eine Bitte: Der Patch zum Entfernen des AP-Abzugs müsste danach wahrscheinlich auch aktualisiert werden...)

[Thorium]

An dieser Stelle ein großes Danke für den Patch auch von mir. Macht mir viel Freude.

[NRS]

Das Problem mit der Herberge zwischen Skjal und Prem kommt davon, dass ich im Array "HERBERG_KICKED_FLAGS" die Positionen 67-72 verwende, um das teilgruppenspezifische Reiseziel abzulegen. Das Originalspiel hatte ja den Fehler, dass das Reiseziel überhaupt nicht teilgruppenspezifisch verwaltet wurde. Positionen 64-73 waren von keiner Herberge in keiner Stadt verwendet, so dass ich mich mit sechs Teilgruppen-Reisezielen dort breit gemacht hatte. Es stellt sich nun heraus, dass zumindest Positionen 65-69 für Herbergen zwischen Städten verwendet werden. So mein Mist.

Man könnte das ganze sauber lösen, indem man HERBERG_KICKED_FLAGS nicht mehr als ein Byte pro Herberge, sondern als ein Bit pro Herberge ablegt. Dadurch würde genug Platz frei. Dies hätte keinerlei Auswirkung auf neu begonnene Spiele, und keinerlei Auswirkungen auf bestehende Spielstände, bei denen man noch keinen Herbergsvater beleidigt hat. Es hätte aber die Auswirkung auf bestehende Spielstände, dass bereits beleidigte Herbergsväter bei Fortsetzung dieses Spielstandes falsch zugeordnet würden. Ich halte das aber für akzeptabel -- welcher ernsthafte Spieler verbringt seine Zeit schon damit, laufend Herbergsväter anzuschnauzen? Und wenn, dass muss man halt entweder hinnehmen oder das Array-Element im Spielstand händisch korrigieren. Was meint ihr?

Kannst du mir mal verraten, wo in BrightEyes der in Frage kommende Code steht?

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.

[Crystal]

welcher ernsthafte Spieler verbringt seine Zeit schon damit, laufend Herbergsväter anzuschnauzen?

Zu der Sorte zähle ich mich zwar nicht, weil ich mit denen generell nicht rede. Aber ich denke, dass man bei den Antwortoptionen manchmal nicht weiß, welche Auswirkungen das auf den Gegenüber hat. Meistens sollte sich das aber aus dem Wortlaut ergeben...

[Alrik Alrikson]

[...]

Man könnte das ganze sauber lösen, indem man HERBERG_KICKED_FLAGS nicht mehr als ein Byte pro Herberge, sondern als ein Bit pro Herberge ablegt. Dadurch würde genug Platz frei. Dies hätte keinerlei Auswirkung auf neu begonnene Spiele, und keinerlei Auswirkungen auf bestehende Spielstände, bei denen man noch keinen Herbergsvater beleidigt hat. Es hätte aber die Auswirkung auf bestehende Spielstände, dass bereits beleidigte Herbergsväter bei Fortsetzung dieses Spielstandes falsch zugeordnet würden. Ich halte das aber für akzeptabel -- welcher ernsthafte Spieler verbringt seine Zeit schon damit, laufend Herbergsväter anzuschnauzen? Und wenn, dass muss man halt entweder hinnehmen oder das Array-Element im Spielstand händisch korrigieren. Was meint ihr?


[...]

Ich halte das auch für akzeptabel. Zumal das Problem ja nur eventuell für begonnene Spielstände relevant und dann auch nur marginal ist, da man zur Not immer ein Lager aufschlagen kann.

[NRS]

So, ich habe jetzt zusätzlich noch die folgenden Dinge geändert:

1. Steinschleuder unbenutzbar, weil es keine Steine als Munition gibt. Lösung: Steinschleuder braucht keine Munition (auf vielfachen Wunsch eines Einzelnen)
   
2. Rausschmiss aus Herberge zwischen Prem und Skjal, obwohl nie da gewesen
   
3. Bei 110% Traglast oder mehr wurden im Statusbildschirm 3 BP statt 1 BP angezeigt
   

Ich warte jetzt noch ein bisschen, ob wegen "Kampfeinfrieren gegen zweifeldrige Gegner" ein glorreicher Lösungsvorschlag von irgendwo kommt. Ich habe allerdings keine Skrupel, den Patch auch ohne eine Korrektur hierfür freizugeben. Der Fehler tritt wohl nur in der an sich schon sehr eigenwilligen Situation eines Soloabenteuers auf, nur beim Kampf gegen die beiden zweifeldrigen Gegner Steppenhunde und Grimwölfe, auch nur dann, wenn man sich in einer bestimmten Ecke verkriecht, und selbst dann ist es mir bei meinen eigenen Spielständen nie, beim bereitgestellten HEX-Spielstand nur in einem von vier Versuchen gelungen, den Fehler auszulösen. Das liegt wohl daran, dass das "Einfrieren" wie gesagt in FIG_backtrack passiert, so dass der Fehler wohl nur dann auftritt, wenn die Charaktere nicht so stark sind, dass sie einen Steppenhund mit einem Schlag töten, sondern ihn nur so stark verletzen, dass er noch fliehen kann.

[wiese.hano]

Prima, NRS. Vielen Dank für deine Mühe. Ich denke auch, der Nachteil ist vertretbar. Und wenn man mal einen Herbergsvater beleidigt haben sollte und das Problem auftritt, kann man immer noch Hand an einen Hex-Editor legen.

Muss ich denn, um den neuen Patch anwenden zu können, den alten deinstallieren, oder kann ich den einfach "drüberbügeln"?

[NRS]

Neuen Patch auf das ungepatchte Original-Spiel anwenden, da es sich um eine binäre Differenz-Datei zum Original-Spiel handelt. Bis die neue Version des Patches freigegeben ist, solltest Du aber noch nichts installieren.

Es steht meiner Meinung nach auch zur Debatte, die Sonderbehandlung von zweifeldrigen Gegnern ganz abzuknipsen; dann tritt jedenfalls das Problem mit Einfrieren des Kampfbildschirms und sonstigen seltsamen Verhaltensweisen nicht mehr auf. Das sähe zwar bisweilen komisch aus, aber besser komisch aussehen als Einfrieren. Allerdings würden solche Kämpfe im exotischen Soloabenteuer-Fall schwieriger, da man sich nicht mehr in der Ecke "verkriechen" kann.

Probiert es aus, indem ihr in SCHICKM.EXE mit Hex-Editor nach der Bytefolge 1B 26 28 27 FF sucht und das erste 1B durch FF ersetzt, und sagt mir, was ihr davon haltet. Die Alternative wären, sämtliche Kampfprozeduren in ihrer Logik geistig zu durchdringen und fehlende oder falsche Abfragen zu zwei-feldrigen Gegnern zu ergänzen oder korrigieren (Viel Spaß!), oder es einfach ganz sein zu lassen.

[Alrik Alrikson]

[...]

Es steht meiner Meinung nach auch zur Debatte, die Sonderbehandlung von zweifeldrigen Gegnern ganz abzuknipsen; dann tritt jedenfalls das Problem mit Einfrieren des Kampfbildschirms und sonstigen seltsamen Verhaltensweisen nicht mehr auf. Das sähe zwar bisweilen komisch aus, aber besser komisch aussehen als Einfrieren. Allerdings würden solche Kämpfe im exotischen Soloabenteuer-Fall schwieriger, da man sich nicht mehr in der Ecke "verkriechen" kann.


[...]

Fände ich nicht so gut. Ich habe das Problem des Einfrierens noch nie gehabt in all den Jahren und erst durch gezieltes Ausprobieren mit einem Solo-Charakter provozieren können. Da ist mir persönlich wichtiger, dass es nicht komisch aussieht.

[Zurgrimm]

Steinschleuder unbenutzbar, weil es keine Steine als Munition gibt. Lösung: Steinschleuder braucht keine Munition (auf vielfachen Wunsch eines Einzelnen)

Ich muss zugeben, dass ich bislang noch keine Partie mit Deinem glorreichen Bugfix-Patch gespielt habe. In jedem Falle aber kann ich den Wunsch dieses Einzelnen nur nachhaltig unterstützen. Es ist eine sehr sinnvolle Ergänzung, dass die Steinschleuder benutzbar ist, da das Fehlen der Munition zweifelsfrei als (m.E. gröberer) Bug zu werten ist. Insofern hätte ich zwar - zumal in völliger Unkenntnis des dafür erforderlichen Aufwandes - eine solche Ergänzung nicht eingefordert. Aber ich begrüße es sehr, dass auch dieser Missstand mit dem Patch behoben werden konnte. Danke für Deine Arbeit, NRS. 

[siebenstreich]

So, ich habe jetzt zusätzlich noch die folgenden Dinge geändert:

1. Steinschleuder unbenutzbar, weil es keine Steine als Munition gibt. Lösung: Steinschleuder braucht keine Munition (auf vielfachen Wunsch eines Einzelnen)
   

Der Einzelne bedankt sich und verbeugt sich tief. Damit geht ein Kindheitstraum in Erfüllung!

Zur Sicherheit: Voraussetzung zum Abfeuern der Steinschleuder sollte sein, dass die linke Hand leer ist (um die imaginäre Munition zu halten bzw. um einen Stein vom Boden aufzuheben). Eine Hexe mit Schleuder in der Rechten und Goldschild in der Linken wäre dann doch zu heftig.

Ich warte jetzt noch ein bisschen, ob wegen "Kampfeinfrieren gegen zweifeldrige Gegner" ein glorreicher Lösungsvorschlag von irgendwo kommt.

Ich hab in den Code geschaut und zumindest ein paar erste Gedanken. Dazu gleich mehr.

Der Fehler tritt wohl nur in der an sich schon sehr eigenwilligen Situation eines Soloabenteuers auf,

Ich kann mir eigentlich nicht vorstellen, dass ein Soloheld strikte Voraussetzung für das Auftreten des Bugs ist. Möglicherweise begünstigt es den Bug, dadurch dass weniger Zielpunkte für die Gegner existieren, Kämpfe länger dauern, Gegner öfter die Gelegenheit bekommen zu fliehen etc.

nur beim Kampf gegen die beiden zweifeldrigen Gegner Steppenhunde und Grimwölfe,

Im Kampf gegen zwei Waldlöwen (die ja auch zweifeldrig sind) hab ich zumindest den Entfernungsmessungs-Bug schon beobachtet.

Außerdem ist mir auch mal ein Kampf gegen Piraten eingefroren, bei dem ich -- wenn ich mich richtig erinnere -- mehrere mit einem bösen Blick belegt hatte. Ich vermute hier aber noch einen zweiten Bug.

auch nur dann, wenn man sich in einer bestimmten Ecke verkriecht,

Es kann in mindestens zwei Ecken passieren, siehe die beiden Screenshots in diesem Beitrag.
Dass die Nähe zu einem (bestimmten) Rand Voraussetzung ist, ist gut denkbar (Die Problematik mit unsauber programmierten Funktionen, die über die Grenzen des Speicherbereichs hinausschießen.)

Das alleine könnte der Grund sein, warum man dem Bug mit einer normalen 6er-Gruppe nicht begegnet. Man rennt mit seiner übermächtigen Heldengruppe siegessicher auf die Gegner zu und verprügelt sie auf dem schnellsten Weg. An den Rand kommt man dabei normalerweise nicht.

Das liegt wohl daran, dass das "Einfrieren" wie gesagt in FIG_backtrack passiert, so dass der Fehler wohl nur dann auftritt, wenn die Charaktere nicht so stark sind, dass sie einen Steppenhund mit einem Schlag töten, sondern ihn nur so stark verletzen, dass er noch fliehen kann.

Dass es bei fliehenden Gegnern passiert, halte ich für sehr gut möglich, im zuletzt verlinkten Beitrag hatte ich mich auch in dieser Richtung geäußert.

[NRS]

Zur Sicherheit: Voraussetzung zum Abfeuern der Steinschleuder sollte sein, dass die linke Hand leer ist (um die imaginäre Munition zu halten bzw. um einen Stein vom Boden aufzuheben). Eine Hexe mit Schleuder in der Rechten und Goldschild in der Linken wäre dann doch zu heftig.

Mit soviel Heftigkeit musst Du leben. Die Hexe hält den Schild mit Mittel-, Ring- und kleinem Finger, und die Munition mit Daumen und Zeigefinger. Ansonsten müsste die Steinschleuder intern als Zweihänder geführt werden, und das ist dann mir zu heftig.

Ich hab in den Code geschaut und zumindest ein paar erste Gedanken. Dazu gleich mehr.

Da bin ich aber mal gespannt.

[siebenstreich]

Man könnte das ganze sauber lösen, indem man HERBERG_KICKED_FLAGS nicht mehr als ein Byte pro Herberge, sondern als ein Bit pro Herberge ablegt. Dadurch würde genug Platz frei. Dies hätte keinerlei Auswirkung auf neu begonnene Spiele, und keinerlei Auswirkungen auf bestehende Spielstände, bei denen man noch keinen Herbergsvater beleidigt hat. Es hätte aber die Auswirkung auf bestehende Spielstände, dass bereits beleidigte Herbergsväter bei Fortsetzung dieses Spielstandes falsch zugeordnet würden. Ich halte das aber für akzeptabel -- welcher ernsthafte Spieler verbringt seine Zeit schon damit, laufend Herbergsväter anzuschnauzen? Und wenn, dass muss man halt entweder hinnehmen oder das Array-Element im Spielstand händisch korrigieren. Was meint ihr?

Wenn das Umwandeln in eine bitweise Aufteilung des Speichers die einfachste Lösung darstellt, dann sollte das auch so gemacht werden. Sollte das wirklich bei jemandem zu schwerwiegenden Verwerfungen führen, dann braucht er die neue Version des Patchs ja nicht installieren.

Es steht meiner Meinung nach auch zur Debatte, die Sonderbehandlung von zweifeldrigen Gegnern ganz abzuknipsen; dann tritt jedenfalls das Problem mit Einfrieren des Kampfbildschirms und sonstigen seltsamen Verhaltensweisen nicht mehr auf. Das sähe zwar bisweilen komisch aus, aber besser komisch aussehen als Einfrieren. Allerdings würden solche Kämpfe im exotischen Soloabenteuer-Fall schwieriger, da man sich nicht mehr in der Ecke "verkriechen" kann.


Probiert es aus, indem ihr in SCHICKM.EXE mit Hex-Editor nach der Bytefolge 1B 26 28 27 FF sucht und das erste 1B durch FF ersetzt, und sagt mir, was ihr davon haltet.

Interessant, dass sich das durch die Änderung eines einzigen Bytes erreichen lässt. Ich habe es ausprobiert. Damit kann man dann auch ohne Bug in die Hinterteile der Hunde reinspazieren. Trotzdem wirkt das ganze wider Erwarten eigentlich ganz natürlich auch mich. Aber irgendwie schrecke ich davor zurück, die ganze Programmlogik der zweifeldrigen Monster komplett abzuschalten. So schlimm ist der Bug, der sich irgendwo da drin verbirgt, dann auch wieder nicht.

[siebenstreich]

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