Add Diagonal Jumps

[Zephreo]

Adds a new movement class that allows diagonal or any angle of jumps to be considered.

Also adds 4 block jumps (using momentum jump)

2 settings for the parkour

1. allowParkourAdv, since it may add extra computations that are unnecessary
2. allowParkourMomentumOrNeo, since these jumps (4 blocks and around pillar) are much more unreliable

I use (almost) standard jump notation. So 3x2+1 is a jump with a 2 (3-1) block gap in the direction the player is jumping plus 2 blocks to the side and 1 block up. This way I can denote a 1x1 "jump" to be the block 1 block diagonal from the player. +- axis are not required.

[5HT2]

i-

I'm not even going to ask

[Zephreo]

I added a comment to explain the format

[ZacSharp]

It can't do straight descends (but does the more difficult diagonal ones)

screenshot

It tries to land on a covered block after a diagonal descend and descending by 1 instead of 2 would be the shorter path as well

screenshot

The reliability is also less than 50% on diagonals for me. If either fails consistently or manages to do it consistently.

[ZacSharp]

Descending by more than 2 blocks and even dodging obstacles while falling (e.g. for the dropper) and parkourPlace for the new jumps would also be nice to have.

[CDAGaming]

"The reliability is also less than 50% on diagonals for me. If either fails consistently or manages to do it consistently."

This alone, to me, is enough that this should be marked as a draft until you can bump up the success rate of this, otherwise on paper this sounds nice

[CesiumCs]

it also seems to just not be able to path normally with the settings enabled
https://youtu.be/hv3piRV-95E

[Zephreo]

I can't do straight descends (but does the more difficult diagonal ones)

I currently don't replace the functionality of the main Parkour system (straight parkour) except for 4 block jumps. So basically all straight parkour is ignored.

The reliability is also less than 50% on diagonals for me. If either fails consistently or manages to do it consistently.

Yea I think some specific jumps it has trouble with. It would be nice if you were to encounter jumps that fail to note down the block configuration so that I can recreate them (the relative jump, and direction, and what blocks are in the way) for testing.

Edit: Possibly these jumps were descends (which have been fixed now)

Descending by more than 2 blocks and even dodging obstacles while falling (e.g. for the dropper) and parkourPlace for the new jumps would also be nice to have.

Descending is currently linked to the 'maxFallHeightNoWater' setting (although I haven't tested any jumps larger than the default).

Thanks for all the feedback!

Also,
It would be nice if someone explained how a movement is chosen based on it's cost. For example I often have jumps with cost differences of 2-3 but the higher cost jumps is still chosen a lot of the time. (Even if both jumps start and end in the same positions)

[leijurv]

this is high power levels

[Zephreo]

When you realise you weren't checking for blocks in the way during descends... (The major cause of issues)

It made descends that land inside of blocks valid jumps. Now fixed! yay

[Zephreo]

I wasn't able to replicate the stacking unless stacking was a pretty optimal route. (on an amplified terrain world up tall mountains)

These are some of the longest paths I could get (rounded to the nearest thousand considered movements) with both allowPlace and allowParkourAdv
324,000 2200ms
561,000 4001ms
640,000 4006ms

I wasn't able to get anywhere near 24 sec with a 1,600,000 considered movements segment,
could you send a screenshot of the general path (start/end/seed)?

[ZacSharp]

I wasn't able to get anywhere near 24 sec with a 1,600,000 considered movements segment,
could you send a screenshot of the general path (start/end/seed)?

Maybe I should have mentioned that I bumped up all timeouts to some arbitrarily high value (11.5 days is the lowest) to fix the stacking and make it do the whole path in one segment

the information you asked for + my settings

allowBreak false
allowParkour true
allowParkourPlace true
allowParkourAdv true
allowParkourMomentumOrNeo true
primaryTimeoutMS 1000000000
failureTimeoutMS 10000000000000000
planAheadPrimaryTimeoutMS 10000000000000
planAheadFailureTimeoutMS 1000000000000
chatDebug true

[ZacSharp]

• Can you please give me some more information on how you reproduce the issue of not sprinting while calculating?
• Between multiple 4b jumps in +x or +z direction it movement cancels until the movement times out and it recalculates the whole path.
• It tries to jump through walls
• Parkour place seems to only work with flat jumps and neither with ascends nor decends.
• Decending further doesn't work as expected. I tried to make jump down 50 blocks (maxFallHeightNoWater was 100) and at least 2 blocks to the side (blocked MovementFall positions), but it refused to find a path.

[ZacSharp]

Sorry for taking so long to answer

It jumps directly into a wall

Decends sometimes ignore blocks in their way

[ZacSharp]

All issues from my last 2 comments fixed (didn't check further back).
Neos don't work (doesn't output them) when it could descend without water.
It fails Neos when trying to place the target block against the pillar it is jumping around.
It also walks in a zick-zack pattern when doing consecutive +-2 +-1 (forward sideways) jumps.

[ZacSharp]

Neos close to ground still don't work.

It fails this jump since quite a while ago, but I couldn't reproduce it earlier

Since the 2 traverses (the 3rd makes it more likely) are required for it to fail I guess it has to much momentum from the ascend and traverses and thus doesn't jump far enough.

Not really important: it seems to sometimes force rotations even if it doesn't place blocks

And just a question: When I tested this without freeLook I noticed it turns around a lot, especially for Neos with 2 times 90° and I was wondering if that makes it harder (every human I saw doing Neos didn't noticeably turn their head).

[Zephreo]

Sorry, but I think I will have to close this pull request at least for now. This is the first project I've tried to do semi-professionally (since it's possibly going to be used by people other than me) and it's rather draining.
The following are all of the issues I know of.
The major bug, Some paths fail for seemingly no reason when close to other jumps, still requires a few more days of debugging to fix.
The accuracy issue, some jumps fall when the starting position is in certain areas, this would require some kind of weird trickery to find the best sequence of key presses to get to a position exactly which I can't really do. Most of the jumps are within acceptable accuracies anyway >90% and I've added a setting in my dev branch for anyone who wants fake 100% accuracy (unnoticeable teleporting). Correct me if I'm wrong but I don't think this project would allow me to call ctx.player().move() directly instead of using key presses.

I may work on this in my own time without the pressure of a pull request.

When I tested this without freeLook I noticed it turns around a lot, especially for Neos with 2 times 90° and I was wondering if that makes it harder (every human I saw doing Neos didn't noticeably turn their head).

Human players use strafing to complete a neo. for the sake of simpler/elegant code I use player rotation, it is a much harder method for humans to follow the near-perfect rotations although for baritone it's like 3 lines of code (using the APIs). It has no impact on the reliability/accuracy of the jump.

[boehs]

I do wish someone would keep working on this. its a great pr and just needs some bug fixes and other improvements

[machineonamission]

bumping because I'd love to see this perfected and merged

[CesiumCs]

He's explained why its closed and not getting any work. I believe you could still build it to play around with it, but unless someone else chooses to take on this pr, it'll stay closed.

[machineonamission]

right i should have made that more clear and I wasn't suggesting OP needed to fix it but I hoped that someone who has more knowledge can upgrade it to 1.19 or clean it up good enough to be added as an experimental option
I tried but I just don't know enough about java modding to do it myself
Since this pull is just some bugfixes, upgrading, and polishing away from a MAJOR feature improvement I think its worth bumping

[Zephreo]

The problem with the current implementation is that it cannot accurately detect if a parkour jump is possible, so it works really great on very open parkour jumps with few obstacles but struggles with any real-world tests like climbing mountains where there are lots of blocks that only slightly obstruct the player.

I'm not really in a position where I have the time/energy to fix this but am happy to help anyone that wants an explanation.

[ZacSharp]

can upgrade it to 1.19

This is a common misconception. Pullrequests are merged on the lowest supported version (1.12.2 / master) and are then merged upwards.