Describe your suggestion

Baritone should check if boots with FrostWalker are equiped and if they are water should be treated as a block you can walk on.

Settings

A setting to turn this on or off.

Context

Right now Baritone has issues with FrostWalk. It stops constantly to recalculate the path and sometimes walks long paths on land rather than a straight path through water.

Final checklist

• I know how to properly use check boxes
• I have not used any OwO's or UwU's in this issue.

or Jesus

@unknown81311 have a look at assumeWalkOnWater

Making Baritone work with frostwalker should be possible in most cases as long as you don't want to use it together with jesus.
The problem is that A* cannot handle movements changing the world so any block placing or breaking Baritone does works based on the assumtion of never standing in an invalid location (always standing in two canWalkThrough blocks and on a canWalkOn block).

With frostwalker we can only move onto water horizontally from solid blocks and thus know that whenever we are planning to stand on water we will actually be standing on a solid block (ice). With jesus we can stand on water just like we can stand on any other block so at execution time we will actually standing on water. If you enable both however those inferences don't work anymore because we can stand on water both by moving there using frostwalker or jesus and there's no way of telling how we got to a specific position. If we stand on water with both enabled we can't tell whether we are standing on ice (normal walking, can pillar up, can parkour) or actual water (increased walking cost, no pillaring, no parkour) and thus Baritone will always have to assume the worst case scenario, preventing it from e.g. pillaring up from frozen water.
This might seem logical when explained here, but in the end it causes assumeWalkOnWater to have seemingly unrelated effects.

A second problem might be that frostwalker has a bigger impact than placing or breaking a block so the likelihood of a collision between movements increases (e.g. a MovementFall onto water you have frozen in a previous movement is a bad idea). However I don't think that's a big problem because Baritone should notice such changes in time and replan if neccessary.
Also, have you noticed how often Baritone trips itself up with a block it broke or placed? I don't think it will happen much more often with frostwalker.

Mostly working but overshoots when descending into a traverse onto water, entering the water without walking next to it. I also still need to make sure this cannot cause impossible paths when combined with assumeWalkOnWater.

This is getting much more difficult than I expected. If you just walk down an edge without sprint you already have enough momentum to only hit the edge of the next block. This means that a) frostwalker does not trigger and b) Baritone skips directly to the next movement so the actually failed traverse doesn't get a reliable chance to either fix itself or report the failure.

Until I get to have a look at preventing this, here's a version which is hopefully fully working apart from that bug (CI build is here). It would be nice if you could let me know if it worked / did not work during some extended real use, regardless of whether you actually made use of frostwalker or not, because I might very well have messed up some other movements (e.g. I completely broke bridging in ZacSharp@e75a4b9).

Overshooting (and a couple more) fixed here (CI) but there's one more problem I know of and I expect at least a dozen more to pop up while I try fixing them all.

I regret having touched movement code.