mirror of
https://github.com/MCCTeam/Minecraft-Console-Client
synced 2026-08-15 13:04:36 +00:00
f7d9a8048c
Two related fixes for the (255,117,220) -> (237,97,172) route reported where the bot fell out of a 22-block water descent and landed on the rim, and where /pathdiag noticeably froze and warped the bot. DescendTemplate: long-fall water-column overshoot ================================================= On segment 7 of the route, a 22-block descend Descend (254.5,113,224.5) -> (253.5,91,224.5), the bot's footprint enters the target column at the very first airborne tick (X=253.6 footprint inside [253,254], Z=224.7 footprint inside [224,225]). The previous code immediately set biasTowardExitInAir = true, rotating yaw to the next segment's exit heading (-Z) for the entire 20+ tick fall. Forward held during the fall pushed -Z momentum each tick (~0.05 m/tick equilibrium), so by landing time the bot had drifted ~1 m past the water column and landed on the dry rim (Z=223.42 vs target Z=224.5). On a real server this plunge from 22 blocks onto a non-water block would kill the bot. Two changes in DescendTemplate.cs: 1. Gate the footprint-inside-target bias for non-single-step descends behind a "near landing" check (remainingFallY <= 1.5 m, ~3 ticks of free-fall). The bias still applies on single-step descends (where the fall is too short for drift to matter) and on the final approach ticks of multi-block falls. 2. Extend the existing riskyOvershoot Back-input brake to fire on any multi-block descend whose footprint is already inside the target, not just the PrepareJump exit case. Once the bot is in the column, the segment's horizontal travel is done; releasing Forward and pressing Back kills any residual horizontal velocity so the bot falls straight into the water/landing block instead of accumulating air-control momentum from holding Forward for 20+ ticks. Verified on 1.21.11 with /pathdiag on: segment 7 now lands at (253.59,91,224.42), 0.09 m off target X and 0.08 m off target Z, well inside the target water column. PathSegmentManager: PathDiag main-thread offload ================================================= Diagnostic dumps were emitted line-by-line through _infoLog?.Invoke(), which calls Log.Info -> ConsoleIO.WriteLogLine -> file logger on the main 20 TPS tick. A slow-segment dump or failure trace produces 25-200 synchronous log calls; on the affected route a single batch took 200-500 ms on the tick thread, freezing the position-packet stream long enough for the server to lose track and then snap the bot forward when the tick resumed. Symptom on the user side: every time /pathdiag is on, the bot freezes for ~half a second, then "teleports" through the queued segments, then freezes again. Each diagnostic emission point now snapshots its lines into a List and dispatches them through DispatchDiagnosticsBatch, which appends to a single chained Task running on TaskScheduler.Default. The chain preserves emission order across batches so concurrent slow-segment and seg-> headers do not interleave. The tick path now does O(1) work per dump (build list, ContinueWith) instead of O(N) console writes. Verified by running the same /goto twice (with and without pathdiag): both runs produced identical trajectories and identical replan counts, confirming the diagnostics path no longer perturbs movement. Pathing test suite: 23 failures, identical to baseline. Live regression on prior 4 zero-replan routes ((237<->252, 237<->244)) all still complete cleanly. Made-with: Cursor |
||
|---|---|---|
| .. | ||
| AscendTemplate.cs | ||
| ClimbTemplate.cs | ||
| DescendTemplate.cs | ||
| FallTemplate.cs | ||
| GroundedSegmentController.cs | ||
| SidewallParkourController.cs | ||
| SprintJumpTemplate.cs | ||
| TemplateFootingHelper.cs | ||
| TemplateHelper.cs | ||
| WalkTemplate.cs | ||