Ahoy! Baritone can now swim and use boats

[AverWasTaken]

Ahoy! Baritone can now swim and use boats

Branch: water-improvements -> 1.21.4

---

What this PR does

Two optional ways to actually cross water instead of bobbing along the bottom of it: allowSwimming sprint swims along the waterline with the head out, and allowBoats places a boat from the inventory, rows the path, and takes the boat with it on the far side. Both off by default, both priced into the planner so it picks water routes when they're faster.

Why it should be merged

Baritone treats a lake as nine ticks a block of wading, so it walks around anything bigger than a pond. Swimming brings that to about seven and a boat to under three, and the search gets to use that. Everything is behind settings that default to off, the cost side is a min() in the calculation context, and the boat execution is a self contained state machine the executor hands the tick to, so with the settings off nothing about pathing changes and with them on it's one class to look at if something looks odd.

What changed

Swimming first. Vanilla only enters the swim state with the eye underwater and actively cancels sprint at the surface, which is exactly where the old jump bob kept us, so sprint swimming never engaged on its own. Then even once it did, cutting the jump key at a depth band launched the player out of the water and porpoised. And boats: a boat's velocity keeps nine tenths of itself every tick, so anything that steers on heading error overcorrects and hunts, which took a few evenings of rowing into banks to properly appreciate.

• allowSwimming: sprint is what keeps the swim state alive, so Movement.update() forces it while in water and a small redirect in updateSwimming latches the state without waiting for gravity. Vertical control is pitch, not jump: with jump held vanilla settles at a vertical speed set purely by look pitch, so a PD on feet height turns into a pitch and the player sits 0.15 under the surface with the head out and the body in. Simulated against the exact update equations first, no overshoot from any depth, settles within a second. Shallow water crawls along the bottom until air runs low, then stands up to breathe. Corners are cut early because water momentum coasts half a block past a bend. SWIM_ONE_BLOCK_COST = 20/2.86.
• Mining from a swim didn't work at all: the swim look mode returned SERVER for everything so the crosshair never landed on the block, and vanilla mines 5x slower off the ground and 5x again with the eye under. Block interacts get CLIENT like the normal freeLook branch, and shouldSwim() is false while PREPPING so we stand up to mine.
• allowBoats: with a BoatItem anywhere in the inventory, water nodes a boat can float on are priced at BOAT_ONE_BLOCK_COST = 20/7. "Can float" is surface water with headroom for a rider, no bubble columns in the 3x3 (a whirlpool sinks it, soul sand launches it), and every neighbour at water level open, because the hull is 1.375 wide and the item refuses to place it with a bank beside the node. That last rule also routes A* a block off the banks for free.
• The crossing itself is BoatTrip, owned by PathExecutor: place the boat out over the lane from the shore (or from the water if the path jumped in), climb in, row, and at the far side punch our own boat so the item drops where we land, wait for the feet to sink back into the water node, and hand the tick back. It keeps pathPosition moving so plan ahead still works, survives splices, and a fresh executor that finds the player already rowing just carries on. boatMinWaterLength (default 8) says how much water is worth the place and scuttle overhead, boatPickup whether to take the boat along.
• Driving is a small model predictive loop on the exact vanilla boat physics: for every tap it could do (1, 2, 4 or 12 ticks either way, or nothing, with and without forward) roll twelve ticks forward, starting with last tick's choice because the boat ticks before its passenger reads the keys, and keep the one that lands nearest the lane point ahead without leaving the lane, clipping a bank with the hull's box, pointing the wrong way, or fidgeting with the keys. The lane it tracks is the node centers pulled taut, since staircase water paths otherwise turn into a wave the boat follows faithfully. Tuned offline against the same equations: two right angles in about ninety ticks with one clean swing each, and key presses on a straight down from 35 to 5. A single tap is always a ten degree turn in vanilla, so the heading holds to about five degrees at best, honestly surprised me.
• Boat stretches render as a lane in colorBoatPath (default green), two lines either side of the line the boat actually follows. Refused runs drop back to the normal path color.
• Debug chat is nautical. "ahoy! we can sail the seven seas!", "land ho!", "we've run aground. abandon ship". You'll live.

Costs changed: water traversal is min(wading, swimming) with allowSwimming and min(that, rowing) where a boat can float with allowBoats. Nothing else in the cost model moved.

Preview

https://www.youtube.com/watch?v=0kdDPz10wvI

Testing

Existing unit tests and the full build (JDK 17) green. Swimming and boats smoke tested in a dev env over a few sessions: lake crossings, rivers with bends, shores a block above the water, falling into water from a ledge, one boat in the inventory, creative and survival pickup, and pausing mid crossing. Known limits: a one wide canal is never boatable, blockFreeLook on means placement mostly fails since the client never turns, and corners at speed still swing about a block wide inside the lane.

[ZacSharp]

This pr is a little bigger and I was testing other stuff anyway, so some play testing first this time

Did you break A*? My bet would be that boats are faster than sprinting, so the heuristic no longer underestimates.

Boat trace rendering doesn't look all that great in turns

Also not yet sure what to think about the boat code. Boats feel kinda useless, so 1k+ loc is a lot, but it does look darn cool and does speed up ocean crossings.

[AverWasTaken]

yep you called it on A*. rowing was priced at 20/7 = 2.857 a block and costHeuristic is 3.563, so the heuristic overestimated anywhere near water and the search went on a scenic tour of the lake. boat water now costs max(BOAT_ONE_BLOCK_COST, costHeuristic), so nothing in the graph is cheaper than the heuristic thinks a block is. it's still under half of swimming (6.99) so boats get picked all the same, it just can't prefer a detour over water to a straight sprint anymore, which is honestly fine.

on the trace: each segment was drawing its own pair of offset lines with its own normal, so the outside of a turn gapped and the inside folded over itself into that bow tie. each side is now one connected line off averaged normals, and edge points that land closer to the centerline than the lane is wide get dropped, so the inside of a tight turn just cuts the corner.

both in 3926456.

on the size, fair. most of it is BoatTrip, which is one self contained file hooked in at the top of PathExecutor.onTick, and it's all behind allowBoats which defaults to false. with the setting off the only thing that runs is a boolean check. if you'd rather it get split out of this PR so swimming can land on its own i can do that too.