Some information

Operating system:
Java version: Runtime 21.0.1
Minecraft version: 1.21.3
Baritone version: 1.11.1 (latest)
Other mods (if used): Plenty honestly. It's a lot of fps improvement mods and other client side mods. I don't think this issue is relating to any mod interference but I'll write them here if you need me to.

Exception, error or logs

How to reproduce

For some reason Britone is unable to mine flowers next to the world boarder. It paths to the flower just fine, but it doesn't break it when it arrives. I have to break it manually.

The flower must be next to the world boarder, not in it or past it. However if the flower is only 1 block away or more. It can mine it just fine.

Modified settings

It's also alot. I'll add them if I need to.

Final checklist

• I know how to properly use check boxes
• I have included the version of Minecraft I'm running, baritone's version and forge mods (if used).
• I have included logs, exceptions and / or steps to reproduce the issue.
• I have not used any OwO's or UwU's in this issue.

If I'm correct about the reason for this, this should happen with anything Baritone can walk through. Other blocks will be ignored when next to or outside the world border.

Firstly, for canWalkThrough blocks just walking into them won't do the trick. Path execution will walk into them and that's it (honestly I was surprised mining them works anyway). However, there's a second mechanism by which MineProcess can break blocks:
If a target block is in the same xz column as the player and at or above foot height and breaking it won't trigger falling blocks or risk unblocking liquids, then MineProcess will break it.

The check for falling blocks/liquids happens in MovementHelper.avoidBreaking, which also returns true right next to the world border. Normally that's not a problem since MovementHelper.getMiningDurationTicks reports any such block as being unbreakable and MineProcess will completely ignore inbreakable blocks.
However, if a block is canWalkThrough there is no reason for movements to break it, so getMiningDurationTicks shortcuts and returns 0, making MineProcess include it in the pathfinder goal even though it won't be able to break the block.

(I'll hopefully have a fix tomorrow; should be as simple as explicitly checking avoidBreaking)

Huh. Well Baritone seems to know where the bottom of the full sugar cane crop is. I don't know how baritone works but maybe adding an exception to crops like sugar cane where baritone has to mine them at a distance.

But then again, having baritone be able to mine blocks from a distance by default would fix many problems.

I personally can't thing of a reason for baritone not mine blocks from a distance, it would fix Baritone's pathing issues for blocks it mines at eye level, it would probably fix the flower thing at workd boarder. Itight even fix breaking sugar cane. But what do I know lol

If I'm correct about the reason for this, this should happen with anything Baritone can walk through. Other blocks will be ignored when next to or outside the world border.

Firstly, for canWalkThrough blocks just walking into them won't do the trick. Path execution will walk into them and that's it (honestly I was surprised mining them works anyway). However, there's a second mechanism by which MineProcess can break blocks: If a target block is in the same xz column as the player and at or above foot height and breaking it won't trigger falling blocks or risk unblocking liquids, then MineProcess will break it.

The check for falling blocks/liquids happens in MovementHelper.avoidBreaking, which also returns true right next to the world border. Normally that's not a problem since MovementHelper.getMiningDurationTicks reports any such block as being unbreakable and MineProcess will completely ignore inbreakable blocks. However, if a block is canWalkThrough there is no reason for movements to break it, so getMiningDurationTicks shortcuts and returns 0, making MineProcess include it in the pathfinder goal even though it won't be able to break the block.

(I'll hopefully have a fix tomorrow; should be as simple as explicitly checking avoidBreaking)

Ohh I see that makes so much sense. There's actually another bug that might be related to this, when when I instruct baritone to break sugar cane. Ot walka into the cane, and looks at the bottom block without breaking it. Probably because theres other sugar cane in the way.

Sounds very plausible. Also the avoidBreaking check doesn't check straight upwards (for a reason, but unexpected in this case) so MineProcess is completely fine mining an ore below an anvil while standing below it.

Just wanted to fix the behavior you described by mining from head position outwards and noticed that doesn't solve the problem. Just try the same thing with an interaction blocking canWalkThrough non-target above a canWalkThrough target (is this possible in vanilla?).

It doesn't know at all what sugarcane even is. It just tries to break all target blocks in in the x,z column of the player from foot level upwards. I can fix the sugarcane case by making it mine from eye level outwards, but that won't fix cases where the occluding block is not a target block.

While movement execution is a mess and horrible to reason about, it is also the most tested part of Baritone and pretty reliable at doing its thing, including dozens of weird edge cases (which are exactly the reason it's a mess). This makes mining blocks by walking into them a very simple and robust strategy. Breaking blocks from a distance means implementing all the logic in MineProcess itself, having to take care of all the edge cases.
Only mining in the same x,y column as the player was probably intended to be a foolproof and simple extension, and here is where we are

• No timeout so if it gets stuck it is stuck indefinitely
• Can drop anvils on its head, even though that was supposed to be explicitly checked for
• Gets stuck if a block is occluded
• Gets stuck if a block turns out to not be breakable

And for mining you need to walk to the block anyway in order to collect the drop.

Mining from a distance makes bookkeeping more complicated and also massively complicates determining where to walk (you can't just do thousands of raycasts per tick, so the obvious strategy is ruled out and you get into caching with all its problems). There are some cases where it would help, but I do not think it is worth the effort.

If you want to see a dozen things that can go wrong with breaking from a distance, just look at the builder.

Ah I see. When ot comes to walking into blocks in order to pick up the items they drop, I thought the mineScanDroppedItems would help. But yeah you're probably right. It's a shame

I'll leave this open until the pr is in.

I'll leave this open until the pr is in.

Oh.. Awesome!!!