Commit graph

1 commit

Author SHA1 Message Date
Erik
96a62a191b docs(research): #265 capture bisect - S1 and S2 both cleared, real culprit is R6 grounded-animation-zero (S3, pre-Campaign-P)
Root-caused via segment mining + a real-trajectory replay harness
(previous commit). Mined two dramatic real "velocity annihilation +
permanent freeze" events from the live capture (a high-speed fall landing
on a moderate, walkable-by-threshold roof slope, then a full velocity
zero + frozen position for the rest of the capture - 12,292 ticks for the
worse of the two).

A/B verdict: S1 (db2889af, #116 shape-1's Path-6 hasSphere1 change) is
provably UNREACHED for the mined trajectory - hit1 never fires once across
the 80-tick replay, and diagnostic instrumentation shows the landing
actually goes through the still-unchanged sphere0 (foot) branch. Reverting
S1 locally produced byte-identical replay output, confirming this
mechanically rather than by inference. S2 (calc_friction's AP-7 threshold)
has zero production call sites (grep-confirmed) - it is dead code and
cannot affect any live behavior in either direction.

The real mechanism, hand-traced against both mined events exactly: the R6
"grounded movement is animation-root-motion-owned" architecture
(PlayerMovementController.cs:1868-1882, landed 2026-07-20 via f961d700,
ten days before Campaign P) unconditionally zeros horizontal Velocity
every tick once OnWalkable is true. With no held movement key at the
instant of landing, the mover never advances again - a frozen-phase design
predating Campaign P entirely, not a regression from S1/S2.

Recommended direction: do not revert S1 (a real, narrow, retail-faithful
fix unrelated to these two events); do not touch S2 until it's actually
wired into a live path; the real target is #166 (downhill sled) plus the
grounded-movement architecture, which needs a brainstorming pass before
any implementation, not a quick S1/S2 revert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-30 17:59:57 +02:00