Baritone gets stuck for a little, jumping into the area the previously goal/target was.

[pennilessSplatter]

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 os relating to any mod interference but I'm write them here if you need me to.

Exception, error or logs

How to reproduce

This is a complicated issue, but I'll describe it the best way I can.

When baritone recalculates a path to another ore/target block to mine (footnote #1) (footnote #2) but the previous path involved mining the previous block is at eye level. Baritone simultaneously recalculates the path and jumps onto the block (footnote #2). Baritone is now 1 block higher in the y axis and a 1 block displaced in the x or z axis. That block that baritone landed on however is not the origin where Bartone recalculated the new path to the new target block. It's the old location of the previous target block.

Why is this a problem? It's a problem because Baritone doesn't move unless I mine a block under it manually (without pausing) and , apparently match the x axis it thought it was on OR I wait a few seconds for Baritone to recalculate a new path. For normal mining this isn't a problem because most caves have wither the ore at eye level with no room to jump, or the ores are at foot level, so when baritone mines it, it does need to jump in order to finish the path. For something like Bamboo however, baritone seems to struggle a lot because of this bug I've described.

Apparently, when using the #mine command, the baritone ai tries to stand in the same area as the block it needs to mine (if there is air above it to allow the player to stand) in order to fully complete the #mine path to that ore or whatever you told it to mine. It also cannot remember to finish the path first before recalculating. Either that or it finishes the path too early by calculating it's trajectory after making a jump or something. And because it's calculations say [Jumping in this direction = Landing on this goal = Goal finished] it finished the goal before it actually stands where the goal is, and instantly recalculates the next block to path to.

Either these or I have no clue what the hell I'm talking about and I know nothing about how ai path finding works, and maybe I should just shut up and have the experts do the thinking lol.

All I can say for certain is every time this pause happens, It's almost always at a block at Baritone's eye level, and baritone either jumps or is still in the process of jumping after the next block's path from it's current position (while it's jumping and therefor on the previous block) has been recalculated.

I hope you can understand what I'm trying to say. It should be easy to replicate this bug. Just go to a bamboo jungle. Give baritone an instamining axe (to replicate my situation) and watch as baritone gets stuck rather often

Is there a fix to this or a command I can use to stop/decrease this from happening? Even if there is no direct fix currently available. I think a command that allows me to move my player while baritone is path finding would be a good enough fix for me. Because I can move baritone onto the block it needs to start the the new path without having to wait or pause, movez then resume again. Thanks so much!

Footnote #1: ( I am talking about #mine. Any block that's run to be broken by #mine)

Footnote #2: ( After it's finished mining a previous target block)

Footnote #3: ( Because the previous target block was at eye level, implying it's on another solid block, and, there was room for baritone to jump onto the area the previous block it mined was at. A good example is Bamboo in a bamboo jungle biome. Have baritone mine bamboo in a jungle baboo biome for a bit, and you'll see what I'm talking about. )

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.

[ZacSharp]

Here's a much simpler way to observe this behavior. I'm using FollowProcess rather than MineProcess, though the problem should ultimately be the same.

0001-0675.mp4

If you step through the video frame by frame you'll notice that there is no frame with the item picked up but no new path. What I suspect happens here is

1. The player jumps from what I'll call the source position
2. While the player is still in the source position the item "disappears"
3. Accordingly the goal changes to just the position of the second item. (Note that the still current path is not finished)
4. PathingBehavior recalculates and finds a path starting at the source position and since MovementAscends without placing blocks are considered safe to cancel it will also immediately switch to that new path
5. Due to still having velocity the player leaves the source position and lands in the original goal, despite having flicked 90° and walking forwards.
6. The initial movement of the new path (a MovementTraverse) finds the player in an invalid position
7. Timeout and replan

TLDR: Baritone switches path right before the player leaves the intended starting position, making velocity carry the player out of that position before the new movement has a chance to adjust momentum.

Here's a short clip of the same situation with chatDebug enabled and about twice the frame rate

0295-0354.mp4

If I'm correct about this being the cause then this issue is not specific to MineProcess or any other process but rather a problem with the way PathingBehavior and related classes handle goal/path changes.

Concerning your guesswork on what happens: darn close. Mining does indeed work by setting the goal such that reaching it necessarily involves breaking a target block and as soon as a block is gone the corresponding position is removed from the goal, regardless of whether it was reached or not.
Picking the block to break next happens implicitly though. MineProcess simply generates a goal which requires standing in any of the known target blocks and the pathfinder returns the shortest path reaching such a position, thereby "choosing" the target block which takes the least time to reach and break. There is no point at which any part of MineProcess actually knows which block that is.

Is there a fix to this or a command I can use to stop/decrease this from happening?

I mean, technically this should be "fixable" by enabling slowPath and turning down slowPathTimeDelayMS...
That would make finding the new path take long enough to not hit this timing edge case, but any path which isn't super short would take considerably more time to find (I'd guess that doubling path length leads to 4x to 8x increased search time)

[pennilessSplatter]

Yes yes. FollowProcesses should work the same. Ultimately Baritone is recalculating the new path too early, which leads to it getting stuck like you mentioned. The video you have matches the bug perfectly. I don't know how to use slowpath, nor do I know what it does unfortunately. It seems like it might help the situation.

Maybe this bug is part of a feature. If Baritone has to predict before it recaulculates, if it's predictions are incorrect, it could lead to very long recalculating times. So maybe Baritone doesn't involve predictons when it comes to landing on the goal. But Baritone does do some level of predicting when it comes to pathing. For example when the path takes longer than it should, Baritone will recalculate.

There is another bug where in the nether, when mining blackstone without a pickaxe, in a specific area. Baritone mines the block and right before it finishes, it stops mining, recalculates, and the recalculated route just so happens to be the same route. Sk baritone mines the blackstone, and right before it finishes it recalculates. This happens forever in a loop. It involves mining blacstone without a pickaxe or any potion effects. And there is no other faster paths it can find. This is a buy for another issue tho.

But yeah I hope this bug gets fixed soon.

[pennilessSplatter]

I've just come accross something. #mineDropLoiterDurationMSthanksLouca might help. The recalculation is delayed. But it seems to only address the issue when it comes to mining and not picking up loot like you mentioned.

By setting #mineDropLoiterDurationMSthanksLouca to a high enough value like 1000ms (1 second) or over, Baritone is forced to wait that time before continuing. The problem is this happens every time Baritone finishes mining an ore/ore vien and not when it comes to mining ores or picking up items that require stepping up onto a black.