Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order of events with PlayerQuitEvent #11294

Open
PedroMPagani opened this issue Aug 18, 2024 · 0 comments
Open

Order of events with PlayerQuitEvent #11294

PedroMPagani opened this issue Aug 18, 2024 · 0 comments
Labels
status: needs triage type: bug Something doesn't work as it was intended to.

Comments

@PedroMPagani
Copy link

Expected behavior

I think it's expected that after the PlayerQuitEvent for the player to not tick anymore, which could potentially create issues with plugins that rely on the data state of the player in the context of the player quit. Making it impossible for the player to naturally take "damage" from sources like fire tick etc.

Observed/Actual behavior

Currently, I believe this is a Spigot tick, not sure, the code runs the player quit alongside a disconnect with the reason, and ticks the player after this event. meaning if any plugin relies on .isDead(), or other sorts of data that changed exactly after the context of player quit, would be basically an outdated data.

Steps/models to reproduce

It's in the code base, call player quit, then tick the player. This causes an issue, for example if a plugin relies on .getINventory(), and on the .doTick() the player dies, takes damage, the plugin would be having outdated data, it's at least an understanding that the player quit is basically saying "nothing will further happen to this user"

The code that causes the issue:
image

I know this technically was a spigot addon, but thought I could just report and maybe paper decides, or maybe even has an explanation as to why this wouldn't change if so? :)

Plugin and Datapack List

0

Paper version

latest commit, it's just to fork and see the method.

Other

No response

@PedroMPagani PedroMPagani added status: needs triage type: bug Something doesn't work as it was intended to. labels Aug 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage type: bug Something doesn't work as it was intended to.
Projects
Status: 🕑 Needs Triage
Development

No branches or pull requests

1 participant