Minecraft-Console-Client/MinecraftClient.Tests/Pathing/Moves/MoveJumpDiagonalAscendTests.cs

110 lines
4.3 KiB
C#
Raw Normal View History

pathing: stabilize 0-replan round-trip on ledge/descend runs Fix a cluster of execution-layer issues that caused replans and void falls when traversing narrow ledges and multi-block descents between (251.5,141,210.5) and (252.5,138,220.5): - WalkTemplate / GroundedSegmentController: suppress the pre-rotation bias toward the next segment's exit heading on stable-footing Turn exits where the next segment is not a jump. The next template snaps yaw on its first tick anyway, and pre-rotating mid-stride on a 1-block walkway pushes sprint drift perpendicular to the path and walks the bot off the edge. Turn exits into a jump still get the bias so the takeoff direction stays aligned. - GroundedSegmentController.ShouldComplete: relax the headingReady gate for Turn exits with stable footing so the segment can complete once yaw is aligned with either the current or the next segment heading (within 25/15 deg). Without this the removed bias would leave the bot stuck at the end of a walkway waiting for a rotation that never happens. - DescendTemplate: restrict the airborne exit-heading bias so it only kicks in when the footprint is inside the landing block, or on single-step drops where the fall is too short for lateral drift to miss the landing column. On 2+ block drops the bot now keeps yaw pointed at the landing center for the whole fall. - DescendTemplate: add a multi-block overshoot guard on PrepareJump exits. Once airborne and past the landing end-plane on a 2+ Y drop, release forward/sprint and press back briefly so air drag pulls the bot back into the 1x1 landing column instead of sailing one block past it into the neighbouring void. Live round-trip between the two goal coordinates now completes with zero replans in three consecutive runs in each direction. Full unit test suite is unchanged from the pre-existing baseline (22 failing tests, all orthogonal to this change). Made-with: Cursor
2026-04-22 16:43:43 +00:00
using MinecraftClient.Mapping;
using MinecraftClient.Pathing.Core;
using MinecraftClient.Pathing.Moves;
using MinecraftClient.Pathing.Moves.Impl;
using MinecraftClient.Tests.Pathing.Execution;
using Xunit;
namespace MinecraftClient.Tests.Pathing.Moves;
/// <summary>
/// Regression tests for the Baritone-parity cardinal-split gate in
/// <see cref="JumpFeasibility"/>'s diagonal Ascend branch. When a cardinal
/// fallback (cardinal Walk into the dx or dz shoulder + a cardinal Ascend
/// from there) exists, the diagonal Ascend must be rejected: it has no
/// physical way to redirect the preceding segment's axis-aligned ground
/// momentum into the diagonal in 2 handoff ticks, so executing it
/// overshoots the target and loops on replan.
/// </summary>
public sealed class MoveJumpDiagonalAscendTests
{
private const int FloorY = 79;
private static CalculationContext BuildContext(World world)
=> new(world, allowParkour: true, allowParkourAscend: true);
[Fact]
public void RejectsDiagonalAscendWhenCardinalSplitIsWalkable()
{
// Flat floor at FloorY, so the cardinal shoulders at (1, FloorY, 0)
// and (0, FloorY, 1) both have solid ground. The ascend target is a
// 1-block riser on the diagonal corner at (1, FloorY+1, 1). Either
// "walk +X first, then cardinal Ascend +Z+Y" or "walk +Z first, then
// cardinal Ascend +X+Y" produces a stable 2-step plan, so the direct
// diagonal Ascend must be rejected.
var world = FlatWorldTestBuilder.CreateStoneFloor(FloorY);
FlatWorldTestBuilder.SetSolid(world, 1, FloorY + 1, 1);
var ctx = BuildContext(world);
var move = MoveJump.DiagonalAscend(1, 1);
var result = default(MoveResult);
move.Calculate(ctx, 0, FloorY + 1, 0, ref result);
Assert.True(result.IsImpossible);
}
[Fact]
public void AcceptsDiagonalAscendWhenBothCardinalShouldersLackFloor()
{
// Island configuration: the source pillar and the diagonal ascend
// riser are the only walk-on surfaces near the bot. The cardinal
// shoulders are open air, so no cardinal Walk + cardinal Ascend
// split exists and the diagonal Ascend is the genuine only option.
var world = FlatWorldTestBuilder.CreateStoneFloor(FloorY);
world.SetBlock(new Location(1, FloorY, 0), Block.Air);
world.SetBlock(new Location(0, FloorY, 1), Block.Air);
FlatWorldTestBuilder.SetSolid(world, 1, FloorY + 1, 1);
var ctx = BuildContext(world);
var move = MoveJump.DiagonalAscend(1, 1);
var result = default(MoveResult);
move.Calculate(ctx, 0, FloorY + 1, 0, ref result);
Assert.False(result.IsImpossible);
Assert.Equal(1, result.DestX);
Assert.Equal(FloorY + 2, result.DestY);
Assert.Equal(1, result.DestZ);
}
[Fact]
public void RejectsDiagonalAscendWhenOnlyOneCardinalShoulderHasFloor()
{
// Only the +X shoulder has floor support; the +Z shoulder is open
// air. Even a single viable cardinal split is enough for Baritone's
// gate to forbid the diagonal Ascend, because A* can simply take
// "walk +X then cardinal Ascend +Z+Y" instead.
var world = FlatWorldTestBuilder.CreateStoneFloor(FloorY);
world.SetBlock(new Location(0, FloorY, 1), Block.Air);
FlatWorldTestBuilder.SetSolid(world, 1, FloorY + 1, 1);
var ctx = BuildContext(world);
var move = MoveJump.DiagonalAscend(1, 1);
var result = default(MoveResult);
move.Calculate(ctx, 0, FloorY + 1, 0, ref result);
Assert.True(result.IsImpossible);
}
[Fact]
public void CardinalAscendStillAcceptedOnFlatFloor()
{
// Sanity: the gate must not touch cardinal Ascend. A plain +X Ascend
// onto a 1-block riser on flat floor should still plan as before.
var world = FlatWorldTestBuilder.CreateStoneFloor(FloorY);
FlatWorldTestBuilder.SetSolid(world, 1, FloorY + 1, 0);
var ctx = BuildContext(world);
var move = MoveJump.Ascend(1, 0);
var result = default(MoveResult);
move.Calculate(ctx, 0, FloorY + 1, 0, ref result);
Assert.False(result.IsImpossible);
Assert.Equal(1, result.DestX);
Assert.Equal(FloorY + 2, result.DestY);
}
}