Two values were producing weird live-test behavior:
- PlayerMovementController.StepUpHeight default = 5.0f (5 meters) and
GameWindow's fallback = 2.0f. With these, walking horizontally into
a steep slope let the step-up scan find walkable polygons up to 5m
away, which often included a small building's flat top. The player
visually "teleported" up onto the roof and then could walk on
surfaces they should have just slid off.
- stepDownHeight was hardcoded 0.04f (4 cm) in two ResolveWithTransition
call sites. A typical stair step is 15–25 cm tall, so when the player
walked off the top of a stair onto level ground, the step-down probe
didn't reach the next surface. For one frame the contact plane was
invalid → ValidateTransition cleared OnWalkable → animation flickered
to falling → next frame gravity dropped + terrain found. Visible 1-frame
flicker reported as "small falling animation when reaching stair top."
Retail's Setup.step_up_height and Setup.step_down_height for human
characters are both ~0.4 m. Sourcing them from the player's Setup
(already cached in PhysicsDataCache) with a 0.4 m fallback when
the field is missing.
Files:
- PlayerMovementController.cs:104 — StepUpHeight default 5.0 → 0.4
- PlayerMovementController.cs (new) — StepDownHeight property, default 0.4
- PlayerMovementController.cs:414 — pass StepDownHeight from controller
- GameWindow.cs:7019-7036 — read Setup.StepDownHeight + reduce fallbacks
- GameWindow.cs:5759 — remote dead-reckoning: 2.0/0.04 → 0.4/0.4
No test changes; existing 12 BSPStepUp tests still cover the value flow.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
b2aaac4e52