HOOK_CHAIN: Rückfall-Prüfung auf einen einzelnen Haken läuft zu spät und ist wirkungslos #6

New issue

Open

opened 2026-08-29 01:41:06 +02:00 by G1LL1 · 4 comments

G1LL1 commented

2026-08-29 01:41:06 +02:00

(Migrated from gitlab.g1ll1.com)

Komponente: CORE (buildPattern)
Betroffene Version: main @ 238ed66, index.html Zeilen 934–943

Beschreibung

Die Ketten-Hakengrube will auf genau einen Haken zurückfallen, wenn der zweite Haken nicht mehr
in die Grube passt:

// index.html:934-943
const firstFx = hookCount === 1 ? rng.range(0.45, 0.7) : 0.4;
const spacing = hookCount === 1 ? 0 : rng.range(252, 286);
for (let i = 0; i < hookCount; i++) {
  const hx = e0 + (i === 0 ? firstFx * w : firstFx * w + i * spacing);
  const hy = baseY - (hookCount === 1 ? rng.range(248, 300) : rng.range(252, 288) + i * 8);
  c.hooks.push({ id: 0, x: clamp(hx, e0 + 60, g1 - 26), y: hy, ... });   // beide Haken schon angelegt
}
if (hookCount === 2 && firstFx * w + spacing > w - 40) hookCount = 1;    // <-- zu spät, ohne Effekt

Zu diesem Zeitpunkt stehen bereits zwei Haken in c.hooks, und c.pits[0].hooks wurde
schon mit hookCount === 2 befüllt (Zeile 933). Die Zuweisung hookCount = 1 ändert an
Layout und Metadaten nichts mehr – toter Code.

Folgeverhalten

Der zweite Haken wird bei knapp bemessener Grubenbreite über clamp(..., g1 - 26) an die
rechte Grubenkante gezerrt:

w = 1.6 … 1.85 × jumpDistance; bei v = 360 (jumpDistance = 270) → w = 432 … 499.
firstFx·w + spacing = 173…200 + 252…286 = 425…486, Grenze w − 40 = 392…459 → Bedingung
greift häufig.
Ergebnis: zweiter Haken bei g1 − 26, also 26 px vor der Landekante und damit praktisch über
dem Landepunkt statt über der Grube.

Damit ist das Muster „HOOK_CHAIN“ nicht mehr deterministisch wie dokumentiert
(AGENTS.md: HOOK_CHAIN = zwei Haken in Folge), und die Hakenplatzierung weicht von der
Vorgabe „Haken sitzen … seitlich über oder kurz vor der Grube“ ab.

Nicht verletzt

Die harten Vorgaben zur Löschbarkeit bleiben erfüllt (über 150 Generierungs-Läufe gemessen):

Kein Hakenabstand > 1.3 × GRAB_RADIUS (0 Verstöße).
Keine Grube breiter als maxGapJumpable ohne Haken im Wurfraum (0 Verstöße bei
Nicht-Plattform-Gruben; Plattformgruben werden über ihre Teilintervalle bewertet).
Kein Haken exakt auf einer Grubenkante durch das clamp (in 150 Läufen 0 Treffer auf
e0+60/g1−26). — Der oben beschriebene Fall ist also selten, aber möglich.

Lösungsvorschlag

Entscheidung vor das Anlegen ziehen und die Gruben-Metadaten konsistent halten:

if (hookCount === 2 && firstFx * w + spacing > w - 40) hookCount = 1;   // vor dem loop
const pit = { x0: e0, x1: g1, hooks: hookCount };
for (let i = 0; i < hookCount; i++) { ... }
c.pits.push(pit);

Zusätzlich absichern, dass ein Haken mindestens GRAB_RADIUS·0.6 von der Landekante entfernt
bleibt, damit er nicht über dem Landepunkt hängt.

Dokumentiert in gitlab-issues/06-hook-chain-rueckfall-pruefung-wirkungslos.md (Commit 238ed66). Alle Befunde ausgeführt und gemessen; Repro-Schritte im Text.

**Komponente:** CORE (`buildPattern`) **Betroffene Version:** `main` @ `238ed66`, `index.html` Zeilen 934–943 ## Beschreibung Die Ketten-Hakengrube will auf genau einen Haken zurückfallen, wenn der zweite Haken nicht mehr in die Grube passt: ```js // index.html:934-943 const firstFx = hookCount === 1 ? rng.range(0.45, 0.7) : 0.4; const spacing = hookCount === 1 ? 0 : rng.range(252, 286); for (let i = 0; i < hookCount; i++) { const hx = e0 + (i === 0 ? firstFx * w : firstFx * w + i * spacing); const hy = baseY - (hookCount === 1 ? rng.range(248, 300) : rng.range(252, 288) + i * 8); c.hooks.push({ id: 0, x: clamp(hx, e0 + 60, g1 - 26), y: hy, ... }); // beide Haken schon angelegt } if (hookCount === 2 && firstFx * w + spacing > w - 40) hookCount = 1; // <-- zu spät, ohne Effekt ``` Zu diesem Zeitpunkt stehen bereits **zwei** Haken in `c.hooks`, und `c.pits[0].hooks` wurde schon mit `hookCount === 2` befüllt (Zeile 933). Die Zuweisung `hookCount = 1` ändert an Layout und Metadaten nichts mehr – toter Code. ## Folgeverhalten Der zweite Haken wird bei knapp bemessener Grubenbreite über `clamp(..., g1 - 26)` an die rechte Grubenkante gezerrt: * `w = 1.6 … 1.85 × jumpDistance`; bei `v = 360` (`jumpDistance = 270`) → `w = 432 … 499`. * `firstFx·w + spacing = 173…200 + 252…286 = 425…486`, Grenze `w − 40 = 392…459` → Bedingung greift häufig. * Ergebnis: zweiter Haken bei `g1 − 26`, also 26 px vor der Landekante und damit praktisch über dem Landepunkt statt über der Grube. Damit ist das Muster „HOOK_CHAIN“ nicht mehr deterministisch wie dokumentiert (`AGENTS.md`: `HOOK_CHAIN` = zwei Haken in Folge), und die Hakenplatzierung weicht von der Vorgabe „Haken sitzen … seitlich über oder kurz vor der Grube“ ab. ## Nicht verletzt Die harten Vorgaben zur Löschbarkeit bleiben erfüllt (über 150 Generierungs-Läufe gemessen): * Kein Hakenabstand > `1.3 × GRAB_RADIUS` (0 Verstöße). * Keine Grube breiter als `maxGapJumpable` ohne Haken im Wurfraum (0 Verstöße bei Nicht-Plattform-Gruben; Plattformgruben werden über ihre Teilintervalle bewertet). * Kein Haken exakt auf einer Grubenkante durch das `clamp` (in 150 Läufen 0 Treffer auf `e0+60`/`g1−26`). — Der oben beschriebene Fall ist also selten, aber möglich. ## Lösungsvorschlag Entscheidung vor das Anlegen ziehen und die Gruben-Metadaten konsistent halten: ```js if (hookCount === 2 && firstFx * w + spacing > w - 40) hookCount = 1; // vor dem loop const pit = { x0: e0, x1: g1, hooks: hookCount }; for (let i = 0; i < hookCount; i++) { ... } c.pits.push(pit); ``` Zusätzlich absichern, dass ein Haken mindestens `GRAB_RADIUS·0.6` von der Landekante entfernt bleibt, damit er nicht über dem Landepunkt hängt. --- *Dokumentiert in `gitlab-issues/06-hook-chain-rueckfall-pruefung-wirkungslos.md` (Commit `238ed66`). Alle Befunde ausgeführt und gemessen; Repro-Schritte im Text.*

G1LL1 commented

2026-08-29 01:41:09 +02:00

(Migrated from gitlab.g1ll1.com)

mentioned in issue #9

G1LL1 commented

2026-08-29 01:45:25 +02:00

(Migrated from gitlab.g1ll1.com)

changed the description

G1LL1 commented

2026-08-29 01:48:09 +02:00

(Migrated from gitlab.g1ll1.com)

changed the description

G1LL1 commented

2026-08-29 10:53:46 +02:00

(Migrated from gitlab.g1ll1.com)

Querverweis zu #1/#2 (Commit 174aeb7): Der dort behebelte Solver-Befund – der Autopilot las jede Naht zweier Bodensegmente derselben Höhe als Grubenkante – ist weg (groundEdgeAfter()). Dadurch verifiziert HOOK_CHAIN wieder (19–20/20 Seeds je Geschwindigkeit). Genau dieser Issue-Hief bleibt aber bestehen: die Rückfall-Prüfung steht weiterhin nach dem Pushen und ändert nur die lokale ZählVariable –

for (let i = 0; i < hookCount; i++) { /*…*/ c.hooks.push(…); }
if (hookCount === 2 && firstFx * w + spacing > w - 40) hookCount = 1;   // wirkt auf c.hooks nicht mehr

Der zweite Haken kann also immer noch ~26 px vor der Landekante landen. Bitte Prüfung vor die Schleife ziehen (z. B. hookCount = (firstFx * w + spacing <= w - 40) ? 2 : 1) und den Grubenbreiten-Fall mit testen.

Querverweis zu #1/#2 (Commit `174aeb7`): Der dort behebelte Solver-Befund – der Autopilot las jede Naht zweier Bodensegmente derselben Höhe als Grubenkante – ist weg (`groundEdgeAfter()`). Dadurch verifiziert `HOOK_CHAIN` wieder (19–20/20 Seeds je Geschwindigkeit). **Genau dieser Issue-Hief bleibt aber bestehen:** die Rückfall-Prüfung steht weiterhin *nach* dem Pushen und ändert nur die lokale ZählVariable – ```js for (let i = 0; i < hookCount; i++) { /*…*/ c.hooks.push(…); } if (hookCount === 2 && firstFx * w + spacing > w - 40) hookCount = 1; // wirkt auf c.hooks nicht mehr ``` Der zweite Haken kann also immer noch ~26 px vor der Landekante landen. Bitte Prüfung vor die Schleife ziehen (z. B. `hookCount = (firstFx * w + spacing <= w - 40) ? 2 : 1`) und den Grubenbreiten-Fall mit testen.