1.20.1 Use pose system for calculating the height of crouching instead of hardcoded values

[Happyrobot33]

instead of using hardcoded crouching values, just use the built in method for geting a entitys eye height with a specific pose. Should close #4484 from personal testing

closes #4484

[ZacSharp]

Removing a public method from the API package. I'd say an @Deprecated is more appropriate.

Otherwise a simple and sane looking change.

[wagyourtail]

IPlayerContext does have access to the player entity, so you could just put the pose thing in the old function

[Happyrobot33]

IPlayerContext does have access to the player entity, so you could just put the pose thing in the old function

the problem is its static so I'm not sure how to even reference the IPlayerContext directly here since it doesn't have a instance reference. and if it was changed to non static it would still be a breaking change

[ZacSharp]

There is the possibility of BaritoneAPI.getProvider().getAllBaritones().stream().map(Baritone::getPlayerContext).filter(c -> c.player() == entity).findFirst().get().getEyeHeight(true), but that's clearly worse and (re?)introducing BaritoneProvider::getBaritoneForPlayer wouldn't help much.
Also why assume the entity is a player? I'd say either the method has to take a LocalPlayer argument or assuming the entity is a player is plain wrong. Not sure whether we should assume there is a Baritone instance for the passed player.

EDIT: I've been tricked by an interface default implementation. IBaritoneProvider::getBaritoneForPlayer does exist, but not in the file I looked at. So it would be BaritoneAPI.getProvider().getBaritoneForPlayer((LocalPlayer) entity).getPlayerContext().getEyeHeight(true), with potential for CCE and NPE for no reason.

[Happyrobot33]

There is the possibility of BaritoneAPI.getProvider().getAllBaritones().stream().map(Baritone::getPlayerContext).filter(c -> c.player() == player).findFirst().get().getEyeHeight(true), but that's clearly worse and (re?)introducing BaritoneProvider::getBaritoneForPlayer wouldn't help much. Also why assume the entity is a player? I'd say either the method has to take a LocalPlayer argument or assuming the entity is a player is plain wrong. Not sure whether we should assume there is a Baritone instance for the passed player.

yeah that long method call is just painful to read as is and feels very breakable lol. I think deprecating it is a better option here, and anyone using it should just refer to the entity itself in the same way the codebase does

[leijurv]

can this be done to the 1.19 branch?