b1af56eb19
Phase L.4 closes the "stuck in falling animation on a steep roof" bug
the user reported on 2026-04-30 ("I jump up, I land on it. It should not
even let me land, should just slide with a falling animation"). After
this commit the body no longer sticks to a steep roof when jumping
into it — it slides along the slope while keeping the falling animation.
Two pieces:
1. BSPQuery Path 6 steep-poly slide
When an airborne sphere hits a polygon whose world normal Z is below
FloorZ (≈ 0.6642, slope > ~49°), the previous flow was:
Path 6 SetCollide → Path 4 set_walkable → ContactPlane committed →
body "lands" on the steep poly with Contact bit + falling animation.
This left the player stuck mid-slope because OnWalkable was cleared
but Contact stayed set.
The new branch detects the steep normal in Path 6 BEFORE SetCollide
is called. Instead of entering the landing path, it removes the
into-wall component of the move (project onto the steep face), sets
CollisionNormal + SlidingNormal, and returns Slid. Same shape as
Path 5's step-up fallback and CylinderCollision. The resolver retries;
the sphere is now outside the poly; FindCollisions returns OK;
ValidateTransition commits the slid position. ContactPlane is never
set, so the body stays airborne with falling animation.
2. PlayerMovementController L.3a-bounce carve-out + Inelastic stop
Re-enables the velocity-reflection bounce when the contact normal is
upward-facing but steeper than walkable (0 < N.Z < FloorZ). The base
L.3a rule suppresses bounce on landing transitions to avoid micro-
bounce on flat terrain; that suppression also stuck the player to
too-steep roofs they shouldn't land on. This carve-out re-enables
the reflection specifically for the steep upward case.
Also lands related L.2c precipice / edge-slide work that was in flight:
- TransitionTypes EdgeSlideAfterStepDownFailed: walkable-poly-steep
cliff route + steep-ContactPlane cliff route ordering, so that
CliffSlide fires when the stored walkable polygon itself is too
steep (Path 4 had previously accepted it as a "landing" via the
permissive LandingZ threshold).
- CliffSlide reference-normal selection: prefer LastWalkable, fall back
to LastKnownContactPlane only when walkable, else use world-up. This
prevents the cross(steepN, steepN) = 0 degenerate case that left the
cliff slide as a no-op when both current and last-known were steep.
- Phase 2 / step-down branch / edge-slide branch / cliff-slide
diagnostic helpers gated on ACDREAM_DUMP_EDGE_SLIDE / ACDREAM_DUMP_STEEP_ROOF.
- Two new airborne-mover regression tests in BSPStepUpTests +
PhysicsEngineTests covering wall-slide and edge tangent motion.
DEVIATION FROM RETAIL — DOCUMENTED FOR FOLLOW-UP
The Path 6 steep slide is NOT what retail does. Retail's flow on the
same hit is:
Path 6 SetCollide (no steep check) → Path 4 find_walkable returns
nothing for steep → Phase 3 reset path: restore_check_pos +
kill_velocity → return COLLIDED → validate_transition reverts CheckPos
to CurPos and forces OK.
Net retail behavior: position reverts to pre-failed-move (typically
just below the roof in the common jump-up case), velocity zeroed,
gravity rebuilds Z next frame, body falls back down naturally with
the falling animation. The "freeze" framing I used earlier was wrong;
in the typical case retail just bounces the body off and lets gravity
take over.
Strict retail behavior would match the user's intent better in the
common case AND avoid the bounce-energy-accumulation we saw with the
slide-tangent approach (V grew to ~50 m/s in continuous-contact frames).
However, retail's behavior degenerates in the edge case of an overhead
landing onto a steep slope (body would freeze mid-air above the roof).
This commit ships the slide-tangent fix as an interim "much better"
state per user verification on 2026-04-30. Follow-up work to match
retail strictly: revert Path 6 steep-slide, audit Phase 3 reset to
ensure kill_velocity (matching OBJECTINFO::kill_velocity ->
CPhysicsObj::set_velocity({0,0,0}, 0)) actually fires, and re-test.
Refs:
- acclient_2013_pseudo_c.txt:323784-323821 (Path 6 SetCollide)
- acclient_2013_pseudo_c.txt:273191-273239 (Phase 3 reset path)
- acclient_2013_pseudo_c.txt:272563-272596 (validate_transition revert)
- acclient_2013_pseudo_c.txt:274467-274475 (kill_velocity)
- acclient_2013_pseudo_c.txt:282699-282715 (handle_all_collisions bounce)
Tests: 833/833 green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
80 lines
3.8 KiB
Markdown
80 lines
3.8 KiB
Markdown
# Movement & Collision Conformance Crib
|
|
|
|
## Phase
|
|
|
|
Active phase: **L.2 - Movement & Collision Conformance**.
|
|
|
|
Plan: `docs/plans/2026-04-29-movement-collision-conformance.md`.
|
|
|
|
Roadmap: `docs/plans/2026-04-11-roadmap.md`.
|
|
|
|
## One-Sentence Framing
|
|
|
|
B.3 shipped the MVP resolver foundation; L.2 is the holistic conformance
|
|
program for physics, collision, buildings, edge/wall sliding, cell ownership,
|
|
movement packets, and server correction.
|
|
|
|
## Active Movement Spine
|
|
|
|
```text
|
|
InputDispatcher / PlayerMovementController
|
|
-> MotionInterpreter + local body prediction
|
|
-> PhysicsEngine.ResolveWithTransition
|
|
-> TransitionTypes + BSPQuery + ShadowObjectRegistry
|
|
-> ResolveResult contact/cell state
|
|
-> MoveToState / AutonomousPosition outbound messages
|
|
-> WorldSession server echo or correction diagnostics
|
|
```
|
|
|
|
## Lane Ownership
|
|
|
|
- L.2a: truth probes, diagnostics, fixture capture.
|
|
- L.2b: movement wire/contact truth, cell id on packets, correction handling.
|
|
- L.2c: transition parity, edge-slide, cliff-slide, precipice-slide,
|
|
`NegPolyHit`.
|
|
- L.2d: `CSphere` / `CCylSphere`, live entity shapes, building object identity.
|
|
- L.2e: outdoor seams, `CELLARRAY`, `find_cell_list`, adjacent-cell checks,
|
|
`cell_bsp`, building entry/exit boundaries.
|
|
- L.2f: real-DAT fixtures and live retail-observer conformance.
|
|
|
|
## Non-Negotiables
|
|
|
|
- Grep named retail before changing AC-specific physics or movement behavior.
|
|
- Do not treat ACE accepting a position as proof of retail collision parity.
|
|
- Do not reintroduce rewrite-from-zero collision guidance. Continue the partial
|
|
retail port by L.2 lanes.
|
|
- G.3 dungeon/portal delivery waits on L.2e for trustworthy cell/building
|
|
ownership.
|
|
- L.1 animation work must coordinate with L.2 when root motion or observer
|
|
movement changes the predicted body path.
|
|
|
|
## Shipped Slices
|
|
|
|
- 2026-04-29: L.2a/L.2b first diagnostic slice. `ACDREAM_DUMP_MOVE_TRUTH=1`
|
|
logs `move-truth OUT` for outbound `MoveToState` / `AutonomousPosition` and
|
|
`move-truth ECHO` for player `UpdatePosition` echoes, including local/server
|
|
delta. `GameWindow` now passes explicit grounded/airborne contact bytes from
|
|
`MovementResult.IsOnGround` to both movement packet builders.
|
|
- 2026-04-29: L.2e first cell-ownership fix. `ResolveWithTransition` refreshes
|
|
outdoor cell ownership from world position during the sphere sweep, so 24m
|
|
outdoor seams update low cell ids and full-cell callers crossing landblock
|
|
seams get the destination landblock prefix plus the correct outdoor low cell.
|
|
- 2026-04-30: L.2c edge-slide plumbing. User live-tested wall-adjacent slide as
|
|
acceptable. Local player and remote dead-reckoning now pass retail-default
|
|
`ObjectInfoState.EdgeSlide`; `ACDREAM_DUMP_EDGE_SLIDE=1` logs failed
|
|
step-down edge cases and now reports whether walkable polygon context is
|
|
present before cliff/precipice handling.
|
|
- 2026-04-30: L.2c precipice-slide context. Named retail
|
|
`SPHEREPATH::precipice_slide` and ACE `Polygon.find_crossed_edge` are now
|
|
captured in `docs/research/2026-04-30-precipice-slide-pseudocode.md`.
|
|
Terrain supplies exact walkable triangle vertices, BSP step-down/find-walkable
|
|
stores world-space walkable vertices for static object tops, and failed
|
|
step-down edge cases run the retail back-probe before precipice slide.
|
|
`cliff_slide` has a first port, but `NegPolyHit`, `CELLARRAY`, full
|
|
`cell_bsp`, and real-DAT building portal conformance remain open L.2 work.
|
|
- 2026-04-30: Edge-slide retry-loop lesson. `SPHEREPATH::precipice_slide`
|
|
usually returns `Slid` after applying the tangent offset. That result must
|
|
be handled inside `TransitionalInsert` like wall slide (`continue` and
|
|
re-test the adjusted `CheckPos`), not returned to `ValidateTransition`; the
|
|
outer validator treats non-OK as a collision and restores `CurPos`, making
|
|
edges feel like hard stops even when the tangent was computed.
|