Add Player#unsetFixedPose - #12853
Merged
Merged
Conversation
notTamion
suggested changes
Jul 19, 2025
github-project-automation
Bot
moved this from Awaiting review
to Changes required
in Paper PR Queue
In certain situations, a plugin might have set a fixed pose and now wishes to reset the pose to a "natural" state. Sure, we could just use setPose with the current pose and fixed=false, but you'd have to wait until the next tick for the pose to update, and sometimes you need to get information from the new pose *now*. This commit adds a new method for the Player class that clears the fixed pose state and immediately determines the correct pose based on the player's current state. Relevant player data, such as eye height, is immediately updated as well.
lynxplay
previously requested changes
Aug 6, 2025
lynxplay
left a comment
lynxplay
left a comment
Contributor
There was a problem hiding this comment.
I am a bit iffy on the method name, resetting a pose seems potentially conflicting given the default pose of "standing" exists.
Maybe restoreVanillaPose() ? Something along those lines, idk maybe copilot has some ideas.
Code lgtm beyond that.
Member
|
Maybe something with recalculate/update in it, |
Warriorrrr
added
type: feature
Member
|
Changed to unsetFixedPose as a suggested name from the contrib channel on discord |
kennytv
approved these changes
Aug 2, 2026
Warriorrrr
approved these changes
Aug 2, 2026
papermc-projects
Bot
moved this from Changes required
to Full approval
in Paper PR Queue
NonSwag
approved these changes
Aug 2, 2026
Strokkur424
approved these changes
Aug 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Paper adds the capability of setting a "fixed" pose that is not updated every tick like normal. In certain situations, a plugin might have set a fixed pose and now wishes to reset the pose to a "natural" state. Sure, we could just use setPose with the current pose and fixed=false, but you'd have to wait until the next tick for the pose to update, and sometimes you need to get information from the new pose now.
This commit adds a new method for the Player class that clears the fixed pose state and immediately determines the correct pose based on the player's current state. Relevant player data, such as eye height, is immediately updated as well.
A practical example for why this is useful: In my plugin, I have a fixed swimming pose on the server-side, but obviously this doesn't carry over to the client. When the player fires a bow or launches a projectile, this would be useful to clear the fixed pose, compare the eye heights, and adjust the location of the new projectile accordingly. There's probably several other use cases for this.
Effectively zero maintenance cost, as we're just wrapping a vanilla function that's unlikely to go anywhere. There's also no unanticipated side effects to this operation, since the API can already manipulate a player's pose ad-hoc. This just manipulates it more intelligently. I know poses are an Entity thing and not exclusive to players, but the vanilla code we hook into is specifically for players, and manipulation of non-player poses aren't as common as a use case. Therefore, I didn't think a more generic solution was warranted.