Note: this bug also affects any custom mobs that use behavior.move_to_water
Steps to reproduce
Load
. It contains a long canal along which are test areas for this bug (grassy end) and MCPE-165109 (muddy end). The lever on the command block at the middle of the canal toggles the canal between 1 block deep and 2 blocks deep. The row of command blocks at each test area will spawn a dolphin, an axolotl, a baby turtle, and a pregnant frog. (Note: the frog spawns with the components for pregnant behavior, but not the is_pregnant bit, so it will not create frogspawn.)
Set the canal to 1 block deep.
Press the button on the command blocks at the grassy end of the canal.
After a minute or so, toggle the canal to 2 blocks deep.
Press the button on the command blocks at the grassy end of the canal, again.
Expected result
After both steps (3) and (5) the mobs all start moving toward the canal within a few seconds.
Observed result
After step (3) the turtle freezes and the other mobs move randomly. After step (5) the axolotl, baby turtle, and pregnant frog move toward the water. The dolphin has an overriding issue reported at MCPE-181125 and can be ignored until that is fixed.
Related issues
is duplicated by
testing discovered
Attachments
Comments
migrated
GoldenHelmet
behavior.move_to_water looks for a path to any water block that has a water source block underneath it. This is similar to how land pathfinding looks for blocks without collision above blocks that "can provide support." I suspect that what happens in this bug is that after behavior.move_to_water finds a water block, it passes to the navigation function both the location of that water block, and also "water" as the condition for "providing support". The fix would be to make the "support" condition be something that always returns true--maybe something like "not air" or just "1".