05.12.2025, 12:32
(Dieser Beitrag wurde zuletzt bearbeitet: 05.12.2025, 13:56 von siebenstreich.)
Um euch ein wenig auf dem Laufenden zu halten:
Es gibt für die Schicksalsklinge folgenden Exploit, erste mir bekannte Erwähnung von JackyD vom 14.8.2006.
Man kann manches schwierige Reiseereignis wie z.B. einen Sumpf wie folgt umgehen: Bei der Ankunft gibt es die Option, umzudrehen. Das macht man, und danach dreht man gleich nochmal um (hierzu muss man zuerst ein Lager aufzuschlagen). Das Reiseereignis tritt nicht mehr auf.
Mir ist die Ursache dieses Exploits über den Weg gelaufen und ich habe es in BrightEyes repariert (als Original-Bug 51).
Der Fix ist unauffällig, aber es hat mich doch einige Zeit gekostet. Das Hauptproblem war, die Bedeutung eines gewissen Arrays zu verstehen. Zuerst hatte ich es so halb treffend mit g_journey_tevent_accessibility benannt. Schließlich ist der Groschen gefallen und ich habe es in g_journey_tevent_relative_position umgetauft.
In diesem Array wird für jedes Reiseereignis auf der aktuellen Route die Information abgelegt, ob es sich (vom Startort aus gesehen) vor oder hinter der Gruppe befindet. Im Verlauf der Reise werden die Einträge entsprechend aktualisiert. Und beim Richtungswechsel der Gruppe wird dubioserweise der Eintrag für das zuletzt aufgetretene Reiseereignis umgedreht. Gut möglich, dass dieses Verhalten bereits das Resultat einer letztlich unvollständigen Fehlerkorrektur von Attic ist. Der berühmte dirty hack, der auch oft funktioniert, dessen Auswirkungen sich aber schwer überblicken lassen und der dann in komplizierteren Situationen gerne doch nicht das tut, was er soll.
Noch genauer:
Die Grundlogik von Überlandreisen findet in der Funktion trv_do_journey (in der Datei seg094.cpp) statt. Tritt ein Reiseereignis ein, so wird dort die zugehörige handler-Funktion aufgerufen, die das Reiseereignis gewissermaßen autark abarbeitet. Danach muss die äußere Funktion trv_do_journey den zugehörigen Eintrag in g_journey_tevent_relative_position aktualisieren. Hierzu muss sie wissen, ob die Gruppe die Position des Reiseereignisses letztlich passiert hat oder nicht. Das Grundproblem: Das ist nicht so ganz klar. Meistens trifft ersteres zu, aber es gibt Reiseereignisse, in deren Handler die Möglichkeit des Umdrehens angeboten wird, und in diesem Fall hat man das Reiseereignis eben nicht passiert.
Attic geht mit der Situation so um: Man geht standardmäßig davon aus, dass das Reiseereignis passiert wurde. Wird jedoch eine Richtungsänderung durchgeführt (die an der entsprechenden Stelle vom handler eines Reiseereignisses, aber auch von einer Umkehr nach dem Abbrechen eines Lagers herkommen kann), wird das letzte Reiseereignis dahingehend korrigiert, dass die Gruppe doch nicht daran vorbegekommen ist. Damit geht man gewissermaßen auf Nummer sicher, denn in der Situation der Reiseereignis-Umkehr tut man das richtige, und in den anderen Fällen verhindert man, dass das letzte Reiseereignis nicht ein zweites Mal hintereinander ausgeführt wird (nicht ganz logisch, aber noch irgendwie vertretbar). Ändert man jetzt aber früh genug nochmal die Richtung, so ist das letzte Reiseereignis immer noch das letzte Reiseereignis, dessen Ausführung nach der erneuten Umkehr abermals unterbunden wird. Und das ist in keinem Fall richtig...
In meinem Fix wird jetzt einfach unmittelbar nach Beenden der handler-Funktion des Reiseereignisses nachgeschaut, ob eine Änderung der Richtung stattfinden soll. Falls ja, so dürfte das in (hoffentlich) allen Fällen bedeuten, dass die Gruppe sich zum Umdrehen entschieden und folglich das Reiseereignis nicht passiert hat. Die oben angesprochene dubiose Aktualisierung habe ich deaktiviert (der bloße Richtungswechsel teleportiert mich ja nicht an einem Reiseereignis vorbei).
Es gibt für die Schicksalsklinge folgenden Exploit, erste mir bekannte Erwähnung von JackyD vom 14.8.2006.
Man kann manches schwierige Reiseereignis wie z.B. einen Sumpf wie folgt umgehen: Bei der Ankunft gibt es die Option, umzudrehen. Das macht man, und danach dreht man gleich nochmal um (hierzu muss man zuerst ein Lager aufzuschlagen). Das Reiseereignis tritt nicht mehr auf.
Mir ist die Ursache dieses Exploits über den Weg gelaufen und ich habe es in BrightEyes repariert (als Original-Bug 51).
Der Fix ist unauffällig, aber es hat mich doch einige Zeit gekostet. Das Hauptproblem war, die Bedeutung eines gewissen Arrays zu verstehen. Zuerst hatte ich es so halb treffend mit g_journey_tevent_accessibility benannt. Schließlich ist der Groschen gefallen und ich habe es in g_journey_tevent_relative_position umgetauft.
In diesem Array wird für jedes Reiseereignis auf der aktuellen Route die Information abgelegt, ob es sich (vom Startort aus gesehen) vor oder hinter der Gruppe befindet. Im Verlauf der Reise werden die Einträge entsprechend aktualisiert. Und beim Richtungswechsel der Gruppe wird dubioserweise der Eintrag für das zuletzt aufgetretene Reiseereignis umgedreht. Gut möglich, dass dieses Verhalten bereits das Resultat einer letztlich unvollständigen Fehlerkorrektur von Attic ist. Der berühmte dirty hack, der auch oft funktioniert, dessen Auswirkungen sich aber schwer überblicken lassen und der dann in komplizierteren Situationen gerne doch nicht das tut, was er soll.
Noch genauer:
Die Grundlogik von Überlandreisen findet in der Funktion trv_do_journey (in der Datei seg094.cpp) statt. Tritt ein Reiseereignis ein, so wird dort die zugehörige handler-Funktion aufgerufen, die das Reiseereignis gewissermaßen autark abarbeitet. Danach muss die äußere Funktion trv_do_journey den zugehörigen Eintrag in g_journey_tevent_relative_position aktualisieren. Hierzu muss sie wissen, ob die Gruppe die Position des Reiseereignisses letztlich passiert hat oder nicht. Das Grundproblem: Das ist nicht so ganz klar. Meistens trifft ersteres zu, aber es gibt Reiseereignisse, in deren Handler die Möglichkeit des Umdrehens angeboten wird, und in diesem Fall hat man das Reiseereignis eben nicht passiert.
Attic geht mit der Situation so um: Man geht standardmäßig davon aus, dass das Reiseereignis passiert wurde. Wird jedoch eine Richtungsänderung durchgeführt (die an der entsprechenden Stelle vom handler eines Reiseereignisses, aber auch von einer Umkehr nach dem Abbrechen eines Lagers herkommen kann), wird das letzte Reiseereignis dahingehend korrigiert, dass die Gruppe doch nicht daran vorbegekommen ist. Damit geht man gewissermaßen auf Nummer sicher, denn in der Situation der Reiseereignis-Umkehr tut man das richtige, und in den anderen Fällen verhindert man, dass das letzte Reiseereignis nicht ein zweites Mal hintereinander ausgeführt wird (nicht ganz logisch, aber noch irgendwie vertretbar). Ändert man jetzt aber früh genug nochmal die Richtung, so ist das letzte Reiseereignis immer noch das letzte Reiseereignis, dessen Ausführung nach der erneuten Umkehr abermals unterbunden wird. Und das ist in keinem Fall richtig...
In meinem Fix wird jetzt einfach unmittelbar nach Beenden der handler-Funktion des Reiseereignisses nachgeschaut, ob eine Änderung der Richtung stattfinden soll. Falls ja, so dürfte das in (hoffentlich) allen Fällen bedeuten, dass die Gruppe sich zum Umdrehen entschieden und folglich das Reiseereignis nicht passiert hat. Die oben angesprochene dubiose Aktualisierung habe ich deaktiviert (der bloße Richtungswechsel teleportiert mich ja nicht an einem Reiseereignis vorbei).