Dylan T.

> If you load data in a callback and store it in memory, will the `PlayerQuitEvent` trigger to free the memory when the player leaves? Could there be a memory...

My main sticking point for this PR now boils down to the use of `PlayerCreationEvent`. Considering there's been discussions to scrap it, I'm not sure if repurposing it like this...

Ah, because PlayerLoginEvent is mutable ... yes, you are correct, I'd forgotten how easily async events can become nightmares

Yeah, the same thought crossed my mind as well. We can't guarantee that PlayerCreationEvent will be immutable in PM6 anyway, as there are several unresolved obstacles to removing custom player...

> Well, after some testing, it's more interesting to move this functionality before launching PlayerPreLogin. I was able to carry out player disconnection tests at the time of `PlayerCreation`, `PlayerPreLogin`...

I'm undecided, but I don't think prelogin is the right call.

I'm leaning towards doing it directly after PlayerCreationEvent, to permit the player to be properly constructed with the appropriate data. It would be nice if Player::__construct() could receive all of...

I'm thinking of stuff like the `?CompoundTag` containing the player's data. But yes, you're probably right, since custom data would be used to configure plugin sessions, rather than the player...

I haven't actually thought about the password protecting stuff. I think encrypting stuff in that manner is probably better left to plugins.

#5917