Parkour on traverse

[Murat65536]

Allow for parkour on open terrains, which should be slightly faster.

• There should be a way to do headhitters by removing the check for a block on top and just setting the max jump to 1
• If the bot is able to do a 3 block jump but is able to reach the dest block with a 1 block jump, it'll just go for the 3 block jump. This is bad but I also don't want to change it back since I want the bot to prioritize larger jumps, just not when it can get to the goal in a smaller jump. The fix for this is not easy. I need to somehow see the destination in cost calculation. Edit: ok, the fix for this may or may not require a complete redesign of how Baritone's moves work and might also make pathing slower since now it has more movements to consider but it's worth it. Speed gain from following the path is big enough that it doesn't matter.

[Murat65536]

@leijurv
So I was looking at how all these movements are structured that I wondered why we even have Moves decide only a single movement option and then pass it on to the respective thing that extends Movement.
This causes a bunch of issues like needing that hack for parkour and fall to work (dynamicXZ and dynamicY) and me not being able to add parkour on traverse since if I change the code to look from the farthest jump to the closest, it'll just skip over the goal.
To fix this, I revamped how everything in Movement and Moves even work. Now instead of Moves returning a single option, it returns a list of offsets and costs. This gives us the ability to perform angled movement shenanigans and do parkour on traverse.
I started messing around with the angled movement stuff and added it to MovementParkour. I guess there is a slight disadvantage with this though. Instead of 4 movement options total in MovementParkour, there are... a little less than 80. I know it sounds pretty bad, but you're also getting a lot of good things:

• Ability to parkour traverse (you literally cannot do it without this) which increases speed on flat terrains by ~40%
• Ability for more angles which also increases speed (and also helps maintain momentum)
• Ability to do headhitters when I stop being lazy and finish this PR
• Ability to add clutching off walls

From how I see it, the time it takes to actually reach the goal is reduced enough that the increased calculation time is worth it. If you still don't think so, I could also take out diagonal parkour and keep everything else. This would bring down the movement options to only 16.

The code that I have right now is full of commented out stuff that I will implement again eventually. I just want to see if this idea will even be considered for merging before I devote even more time to it. The only two Movements that are implemented in this so far are MovementTraverse and MovementParkour.

[Murat65536]

@leijurv Any comment on this?

[flowerey]

Hey I am not a dev or anything but can you provide a video of this? I would really like that

[Murat65536]

@flowerey Sure, but if this is because you want to use these changes, you'll be pretty disappointed. Right now I'm just in a limbo waiting for @leijurv to confirm that this idea is worth implementing. I developed a base for the whole restructure, but this involves removing a bunch of functionality to later re-implement it. Functionality that includes every movement that isn't parkour or traverse. Additionally this probably breaks a lot of things, an example being parkour. Since my main focus right now has been the A* side of things, I haven't devoted the most time to making sure the path is followed correctly after calculation. I'll get to it if the PR idea is approved by leijurv but I remember hearing something about leijurv not being open to changing pathfinding? Maybe that was a conversation about A* to D* lite or something idrk. I just thought it would be best to check. If you want a tldr of the changes here, it's basically a switch from a static set of individual goals each defined in an enum to each movement returning a list to goals. In theory this should be a LOT better since we were using...some unconventional ways to get around this restriction beforehand (dynamicXZ and dynamicY), but it's also a huge change with a performance determent. I'm just hoping the increased execution time makes up for it. Anyway, here's a video:

2025-09-30.21-49-08.mp4

[flowerey]

oh i see, thanks :)