mirror of
https://github.com/MCCTeam/Minecraft-Console-Client
synced 2026-08-15 13:04:36 +00:00
8ec1ccd45d
Two complementary fixes for live-server "stuck on a step then replan"
on the 252.5,138,220.5 -> 244.5,122,188.5 route.
Search layer (ParkourFeasibility.HasRunUp): a long flat sprint parkour
(5 c2c, horiz~5) cannot launch from a cold start. Vanilla physics show
that gap=4 dy=0 reaches 5.1075m only with 12 momentum ticks of straight
sprint windup; a 0t standing jump tops out at gap=3 (=4 c2c). When the
previous move type is not Parkour/Descend (i.e. no carried airborne
momentum) we now require two aligned back-runway blocks instead of one
so the executor actually has room to spin sprint up.
Execution layer (GroundedSegmentController.ShouldComplete): the
LandingRecovery early-out used to live below the MinExitSpeed gate. A
Descend that landed inside the destination block but naturally settled
to zero speed (e.g. when the next segment is a fresh Traverse rather
than a chained Parkour) would fail the 0.03 MinExitSpeed check and idle
inside the target block until the per-segment timeout fired, triggering
an unnecessary replan. Move the LandingRecovery footprint check above
the speed gate so a fully-decelerated handoff is accepted.
Verified live on 1.21.11-Vanilla:
- 252.5,138,220.5 -> 244.5,122,188.5: 24 segments, 0 replans (was: 1)
- 244.5,122,188.5 -> 252.5,138,220.5: 48 segments, 0 replans
- 251.5,141,210.5 -> 252.5,138,220.5: 34 segments, 0 replans
- 252.5,138,220.5 -> 251.5,141,210.5: 24 segments, 0 replans
Test suite: 297 passed / 22 known pre-existing failures, no new
regressions vs
|
||
|---|---|---|
| .. | ||
| Impl | ||
| IMove.cs | ||
| IMoveExpander.cs | ||
| JumpDescriptor.cs | ||
| JumpExpander.cs | ||
| JumpFeasibility.cs | ||
| MoveHelper.cs | ||
| ParkourFeasibility.cs | ||