Baritone AI pathfinder

Baritone AI pathfinder

Mods
72.7k Downloads

Baritone paths to position that does not quite meet isInGoal

Working-Joe opened this issue ยท 1 comments

commented

Problem description

I'm trying to get the BuilderProcess to incorporate support for (some) directional blocks. So far, the results have actually been promising, and behaviour is exactly as expected. The idea is to make Baritone path to the correct quadrant to place a directional block if it otherwise finds no pathing options.

Amongst other things, I added a new type of goal to move the player next to directional blocks. (code of interest is added below for reference.)

However, while Baritone does route to the proper blocks, from time to time it is unable to place the stairs from this position because the player model overlaps with the position where the block is to be placed. (See image below, ~0.002 overlap)

image

Upon further testing it seems that this is also the case with normal non-directional blocks. But Baritone would give up in these situations.

The problem seems to have something to do with the way Baritone determines what block it is in. Is there some way to solve this problem, perhaps a variable to increase to overestimate the player size?

Thanks in advance for any input.

    public static class GoalDirectional extends GoalGetToBlock {

        private boolean allowSameLevel;
        private EnumFacing facing;

        public GoalDirectional(BlockPos pos, boolean allowSameLevel, EnumFacing facing) {
            super(pos);
            this.allowSameLevel = allowSameLevel;
            this.facing = facing.getOpposite(); // We must stand on opposite direction to place
        }

        public boolean isInGoal(int x, int y, int z) {
            Vec3i dir = this.facing.getDirectionVec();
            int xDiff = x-this.x;
            int zDiff = z-this.z;
            int proj = xDiff*dir.getX() + zDiff*dir.getZ(); // length of projection onto facing vector
            int perp = zDiff*dir.getX() + xDiff*dir.getZ(); // rejection vector length

            if(Math.abs(perp)>=proj){
                return false;
            }
            if (x == this.x && y == this.y && z == this.z) {
                return false;
            }
            if (!allowSameLevel && y == this.y - 1) {
                return false;
            }
            if (y < this.y - 1) {
                return false;
            }
            // alternative goal to allow larger range (To prevent problems if there is a block in the way)
            int yDiff = y - this.y;
            int dist = Math.abs(xDiff) + Math.abs(yDiff < 0 ? yDiff + 1 : yDiff) + Math.abs(zDiff);
            return  dist <= 3;
            // return  dist > 1 && dist < 3; //  (temporary workaround)
        }

        public double heuristic(int x, int y, int z) {
            // prioritize lower y coordinates
            return this.y * 100 + super.heuristic(x, y, z);
        }
    }
commented

Some further (possibly key) information after testing:

  • The problem mainly/only occurs if the path towards the block goes through the block to be placed
  • turning to look at the blocks to place usually makes Baritone continue normally, which I consider interesting as this does not change the position. In case of the provided example bariton backs up from the stair and places the block.