Slice 3 v2 (point-in stickiness) closed the cell-resolver ping-pong
(data confirmed: scen4_cottage_cellar_slice3v2 capture shows 1 cell-
transit vs 20+ pre-fix). BUT user verification revealed: cellar-up
symptom transitioned from "stuck-at-top-ping-pong" (pre-slice-3) to
"never-reach-top-stuck-in-cellar" (post-slice-3). Stickiness was
holding player in cellar cell so aggressively that the legitimate
transition to the cottage main floor cell at the ramp top never
fired.
Reverting the stickiness check entirely. Trade-off:
- Inn doorway ping-pong returns (existed pre-slice-3; lesser evil)
- Player can again reach the top of the cellar ramp (per pre-slice-3
user observation)
- Issue #98 cellar-up remains open — but with sharper diagnosis: it's
not the cell resolver at all, it's deeper (BSP step-physics or
AdjustOffset slope-projection at the cottage main floor boundary,
per slice 4 polydump trace showing repeated push-back on the
46-degree ramp polygon)
The slice 3 stickiness premise was correct but the implementation
shape was wrong. A future attempt needs either:
- A "near boundary" gate (only stick when sphere is deep inside cell)
- A retail-faithful per-cell hysteresis matching CObjCell::find_cell_list
Position-variant (acclient_2013_pseudo_c.txt:308742-308783) more
exactly than point-in
- OR address the underlying BSP step-physics bug first; then ping-pong
may not even need a stickiness fix
Test suite: 1148 + 8 (baseline maintained).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
8bd311759e