Die Zwingfeste in Thorwal

[cmfrydos]

Über das gs_groups_x_target hatte ich mich auch gewundert und es als potentielle zweite Schwachstelle (neben der Unsicherheit über das Inventargewicht) abgespeichert. Aber ich hatte es erstmal weggeschoben, weil es mich schmerzlich daran erinnerte, dass ich die deinen Exploit mit der framegenauen Eingabe noch nicht verstanden hatte.

Ok, ich wollte hier nochmal kurz mein Verständnis des Exploits darlegen. Vielleicht hilft das dir, siebenstreich, oder anderen, den Mechanismus besser einzuordnen bzw. die Rahmenbedingungen sauber zu bestimmen.

Ich verstehe aktuell noch nicht vollständig, warum „Vorwärts (↑) gedrückt halten“ nur manchmal zuverlässig greift (bei niedrigen Cycles oft konsistenter, bei hohen teils gar nicht). Aber der grundlegende Mechanismus im Code sieht für mich so aus:

Das Spiel läuft in einer Schleife, in der grob zwei Dinge passieren:

1) Input-Handling (Key lesen -> Action setzen -> ggf. Bewegung ausführen)

2) Dungeon/Event-Handling (pro Tick, unabhängig von Input)

Dass der Eventhandler in jedem Tick läuft, erklärt die Notwendigkeit von gs_dng_handled_pos. Damit soll verhindert werden, dass ein Event auf derselben Kachel im nächsten Tick sofort erneut feuert. Events sollen idealerweise nur beim „frischen Betreten“ einer Kachel abgearbeitet werden.

Im Folgenden habe ich den Exploit samt Codestellen tabellarisch als Gist formatiert (mein Versuch, das hier sauber als Tabelle zu formatieren, scheiterte u. a. an der maximalen Linkanzahl pro Post):
https://gist.github.com/cmsautter/a5e3c1...6d9419ae29

Runde 1 ist das erste „Betreten“ des Geröllfeldes.

Runde 2 ist dann geteilt:

a) Ohne Exploit bzw. ohne sofortige neue Vorwärts-Eingabe landet man effektiv wieder auf dem Feld vor dem Geröll.

b) Mit Exploit (↑ im richtigen Timing bzw. „Spam“) kann man auf dem Geröllfeld verbleiben bzw. darüber hinwegkommen, weil der Rollback-Block nicht mehr triggert.

Der Kern des Exploits ist (so wie ich es aktuell verstehe):

In Runde 1 läuft der Geröll-Block und setzt die Gruppe per Rollback wieder auf die vorherige Position (*_bak) zurück.

ABER: gs_dng_handled_pos wird am Ende trotzdem auf pos gesetzt, und pos ist zu diesem Zeitpunkt noch die Event-Kachel (Geröllfeld), nicht die zurückgesetzte *_bak-Position.

Damit ist handled_pos danach „Geröll“, obwohl die Gruppe effektiv wieder vor dem Geröll steht.

Wenn dann in Runde 2 sofort wieder „Vorwärts“ gelesen wird, ist pos erneut „Geröll“. Da handled_pos ebenfalls „Geröll“ ist, greift die Guard-Bedingung (pos != handled_pos) nicht mehr. Dadurch wird der Rollback-Branch übersprungen, und man bleibt auf dem Geröllfeld stehen (bzw. kann darüber hinaus).

Ich hoffe, das macht klar, warum der Bug sich schwer an einer einzelnen Codestelle ablesen lässt. Es ist keine reine „Ein-Zeile-ist-falsch“-Sache, sondern eine Art falsche Schleifeninvariante bzw. Annahme über zwei Iterationen hinweg. Rollback und handled_pos-Update sind inkonsistent, wenn im nächsten Tick sofort wieder Input verarbeitet wird.

Damit ist auch nicht ganz eindeutig, wie das Ganze am besten gefixt wird. Mein Vorschlag wäre:

gs_dng_handled_pos sollte nur dann auf pos gesetzt werden, wenn pos nach der Eventbehandlung auch wirklich der aktuellen Gruppenposition entspricht. Wenn per Rollback auf *_bak zurückgesetzt wurde, sollte handled_pos entsprechend auf die *_bak-Position (oder auf ein invalides Feld) gesetzt werden.

Damit wäre die ganze Klasse an „Rollback-Events mit handled_pos-Guard“ sauber gefixt.

Alternativ könnte man bei Events dieser Klasse den Guard pos != handled_pos entfernen, weil das Event durch den Rollback ohnehin „sich selbst“ verlässt. Das müsste man aber sorgfältig pro Event prüfen. In der Prem-Mine gibt es z. B. Stellen, die beabsichtigt dauerhaft freigelegt werden können. Dort existiert vermutlich zusätzliche Logik („ist Hindernis bereits entfernt?“).