search

cabaletta / baritone

google maps for block game
GNU Lesser General Public License v3.0
7.15k stars 1.43k forks source link

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

Open Happyrobot33 opened 1 month ago

Happyrobot33 commented 1 month ago

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 commented 4 weeks ago

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

Otherwise a simple and sane looking change.

wagyourtail commented 3 weeks ago

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

Happyrobot33 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 1 week ago

can this be done to the 1.19 branch?