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 :)

[Murat65536]

@leijurv stop ghosting me :(

[flowerey]

xD

[pie474]

I'd also talked to them about accomplishing something similar and may be able to help on the path-following side of things if this ends up happening (I've done a little bit of research on that already). Though I am curious if you have a plan to potentially handle non-integer jump positions, or are leaving that for later (or delegating that to the path executor)? Ground contact points when sprint jumping are usually not aligned to a block if just holding down forward.

[Murat65536]

Though I am curious if you have a plan to potentially handle non-integer jump positions

I was just going to think about that later. I kind of want to start back up on this even though leijurv doesn't seem to care. Maybe it can be calculated at runtime, maybe not. I forgot when cost calc happened since it's been a while since I've looked at this.

[Murat65536]

I've thought about it a little more and it can probably be calculated at the cost calculation stage, which is ideal. Since cost recalculation takes place as the path is running, it seems doable. I have a lot of PRs open right now though, and this one (while being the most rewarding) is definitely the hardest. It's going to be annoying to take into account delta movement, friction, and whatever else I need to look at.