Eine mögliche Ursache für den Bug könnte sein, dass gs_dng_handled_pos nach dem fehlgeschlagenen Betreten fälschlich auf das verschüttete Feld gesetzt bleibt, obwohl die Gruppe per gs_x_target_bak/gs_y_target_bak wieder zurückgesetzt wird.
2-Schritt-Hypothese:
1) Man läuft gegen das Geröll → Dialog erscheint → das Spiel setzt die Gruppe zurück, merkt sich aber trotzdem das Geröll-Feld als „bereits behandelt“ (gs_dng_handled_pos = pos).
2) Läuft man direkt im nächsten Tick erneut vorwärts, landet die Gruppe wieder auf demselben Feld, aber die Abfrage pos != gs_dng_handled_pos greift dann nicht mehr → der Blockier-/Rollback-Code wird übersprungen → man kommt (selten) durch.
Ich habe allerdings noch keine Zeit gefunden, das gezielt im Debugger in der Praxis zu testen.
Edit: Wenn man mehrmals vorwärts drückt und die Taste während der Zeit des „Freiräumversuchs“ gedrückt hält, kommt man bei 1000 Cycles (im Originalspiel) recht zuverlässig schon nach wenigen Versuchen durch, ohne dass besonderes Gepäck oder ein Gruppensplitting nötig wären. Daher halte ich die Hypothese für plausibel und vermute, dass es am Ende vor allem eine Timing-Frage ist, ob man durchkommt.
Das oben beschriebene Gruppensplitting kann dabei durchaus trotzdem einen Einfluss haben: Die zweite Gruppe, zusammen mit den Hunger-/Durst-Abfragen, könnte das Timing verschieben und dadurch das „Treffen“ des allerersten Ticks begünstigen. Das möchte ich nicht ausschließen.
Leider kenne ich mich mit den DOS-Eingabefunktionen nicht gut genug aus, um konkret zu erklären, was genau passieren muss, damit direkt im ersten Frame (nach dem Freilegungsversuch) bereits ein UP (↑) gelesen wird.
2-Schritt-Hypothese:
1) Man läuft gegen das Geröll → Dialog erscheint → das Spiel setzt die Gruppe zurück, merkt sich aber trotzdem das Geröll-Feld als „bereits behandelt“ (gs_dng_handled_pos = pos).
2) Läuft man direkt im nächsten Tick erneut vorwärts, landet die Gruppe wieder auf demselben Feld, aber die Abfrage pos != gs_dng_handled_pos greift dann nicht mehr → der Blockier-/Rollback-Code wird übersprungen → man kommt (selten) durch.
Ich habe allerdings noch keine Zeit gefunden, das gezielt im Debugger in der Praxis zu testen.
Edit: Wenn man mehrmals vorwärts drückt und die Taste während der Zeit des „Freiräumversuchs“ gedrückt hält, kommt man bei 1000 Cycles (im Originalspiel) recht zuverlässig schon nach wenigen Versuchen durch, ohne dass besonderes Gepäck oder ein Gruppensplitting nötig wären. Daher halte ich die Hypothese für plausibel und vermute, dass es am Ende vor allem eine Timing-Frage ist, ob man durchkommt.
Das oben beschriebene Gruppensplitting kann dabei durchaus trotzdem einen Einfluss haben: Die zweite Gruppe, zusammen mit den Hunger-/Durst-Abfragen, könnte das Timing verschieben und dadurch das „Treffen“ des allerersten Ticks begünstigen. Das möchte ich nicht ausschließen.
Leider kenne ich mich mit den DOS-Eingabefunktionen nicht gut genug aus, um konkret zu erklären, was genau passieren muss, damit direkt im ersten Frame (nach dem Freilegungsversuch) bereits ein UP (↑) gelesen wird.