Some information

Minecraft version: 1.12.2
Baritone version: c866438
Other mods (if used): None

Exception, error or logs

No exceptions, no logs, nothing.

How to reproduce

1. Set mouse sensitivity to "HYPERSPEED!!!" (200%). It increases your chances of "getting lucky".
2. Let Baritone build a lot of blocks (I was testing #sel cyl/hcyl/sph/hshph when I noticed this)
3. If you "get lucky" it will at some point stall, looking right at the edge of a block but it wants to place right past that edge.
4. If you turn your mouse sensitivity down it will probably unstuck. (Alternatives are wildly moving your mouse or pausing and moving ever so slightly)

Maybe it is possible to set up a situation where it will get stuck right away (build blocks, set up aim using low sensitivity or commands, crank up sensitivity, let it fail), but so far I had no luck doing so.

Suspected cause

I suspect when this happens the edge of the obstructing block is less than one pixel of mouse movement from the target rotations and the closest "possible" approximation to the target rotations happen to miss the target towards the obstructing block (i.e. aiming at the wrong block gets it closer to the target rotations than aiming at the correct block)

Modified settings

No Baritone settings modified.

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 typed any OwO's or UwU's in this issue.

we addressed this in a fork, cherry picked 6c8f269

How should that fix it? When this happens Baritone is looking at the wrong block so ctx.isLookingAt(pos) is already false and changing the setting doesn't do anything (besides short circuiting the check).

I also couldn't find any difference with remainWithExistingLookDirection set to false.

It doesn't need to be looking at a block at all.

And to think I was this close to adding a setting for the mouse movements 😔

So it's a problem with c8b8deb?

The solution might be something like the old endless issues with sneak placing changing the player eye Y coordinate tbh (all the "wouldSneak" options).

When calculating "If I looked at this angle, would I be able to place this block" it should take into account that it's really "if I looked at this angle using integer mouse movements". Then, standing at the exact edge of a block like that would make it realize that the potential placement is not possible so it would continue walking forward.

@ZeroMemes

Like here https://github.com/cabaletta/baritone/blob/master/src/main/java/baritone/pathing/movement/MovementHelper.java#L686 it simulates what the rotation WOULD be if the player started sneaking then tried to look at the block - I guess this now needs to take into account: what WOULD the rotation be if the player started sneaking then tried to look at the block with only integer pixel mouse movement. THAT rotation should be the one that's then subsequently raytraced on the next line

Yes, sounds like that would fix it.

(If you want it to look even worse, you can iterate over the closest 9 rotations.)

Fun fact: BuilderProcess uses RotationUtils.reachable to look at blocks it wants to break, but does it's own thing for blocks it wants to place.

Just making RotationUtils.reachable (and BuilderProcess.possibleToPlace apply the mouse discretization before raycasting causes a lot more jitter and IAimProcessor has this effect as well. Neither gets stuck though so that's an improvement.

The jitter was me being stupid. I didn't apply the rotation processing to just the raycast, I applied them to the LookBehavior target as well.
When applying the mouse simulation (or the whole IAimProcessor) to the raycast and nothing else both the jitter and the stalling are gone.