WIP: Player Loaded World API #1541
Draft
Conversation
This file contains 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
Timongcraft
added a commit
to Timongcraft/VeloProtocol
that referenced
this pull request
Apr 13, 2025
chore: remove unnecessary mapping entries chore: update player loaded world api -> see PaperMC/Velocity#1541
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
With this PR the in 1.21.4 introduced
player_loadedpacket can be utilised to send/display messages in-game without needing to guess when the player is actually in the world.This PR is not finished, and more to better discuss feature and implementation details. (see below)
This PR only implements the part when the player joins a server, and not the respawn mechanic,
this in my opinion makes sense as there's virtually no reason to fire stuff there on the proxy.
But with the current implementation the proxy only waits 1500ms before the event fires as timeouted,
this is notchian/paper behaviour but isn't particularly useful in my opinion as in my testing the 1500ms were frequently not enough (note that in my testing I used
ServerPostConnectEventas starting point). However, because the client doesn't actually enforce this timeout and sends the packet regardless, we could set our own timing.Also, I'm not exactly sure where we would start to count for the timeout and how to handle it.
Fixes: #1466