generateMovementFallOrDescend then MovementFall.calculateCost checks all the blocks to fall through twice

[leijurv]

First generateMovementFallOrDescend gets them to decide how long of a MovementFall to return, then calculateCost on that MovementFall goes over them again to calculate the cost.

This sucks.

[leijurv]

Okay so this is actually a huge deal performance-wise. Just commenting out fall / descend (yet leaving downward) makes pathing almost 2x faster...

[leijurv]

[22:22:26] [pool-4-thread-2/INFO]: [CHAT] §5[§dBaritone§5]§7 Starting to search for path from BlockPos{x=1368, y=68, z=457} to GoalXZ{x=0,z=0}
[22:22:30] [pool-4-thread-2/INFO]: [STDOUT]: 6172628 movements considered
[22:22:30] [pool-4-thread-2/INFO]: [STDOUT]: Open set size: 106539
[22:22:30] [pool-4-thread-2/INFO]: [STDOUT]: PathNode map size: 547441
[22:22:30] [pool-4-thread-2/INFO]: [STDOUT]: 110225 nodes per second
[22:22:30] [pool-4-thread-2/INFO]: [CHAT] §5[§dBaritone§5]§7 Took 4000ms, A* cost coefficient 1.5, 6172628 movements considered
[22:22:30] [pool-4-thread-2/INFO]: [STDOUT]: Path goes for 347.77147669123184 blocks
[22:22:30] [pool-4-thread-2/INFO]: [CHAT] §5[§dBaritone§5]§7 Static cutoff 362 to 325
[22:22:30] [pool-4-thread-2/INFO]: [CHAT] §5[§dBaritone§5]§7 Found path segment from BlockPos{x=1368, y=68, z=457} towards GoalXZ{x=0,z=0}. 440902 nodes considered

Again, this is with fall and descend disabled, just leaving downward as the only way decrease your y. It still finds a "valid" path, but it breaks blocks on every "descend" since it can no longer do a real descend. I don't count this as a new Baritone record on my laptop obviously (that's still held by #168), since I disabled a core feature.

Even though it's also a record in its own right of just movements considered, it's not a fair average since this one didn't have to consider any falls, which take longer to compute costs for.

[leijurv]

Fixed by sanik, 0d0eefe