Paper
Paper copied to clipboard
PaperMC
Add PlayerDataEvents
This appears to have some support in the Discord community as developers from time to time express the desire to take control over loading/saving playerdata.
This is the first "take" on the PR. The goal here is to provide events that can optionally provide/overwrite the data that is saved/loaded for players. This does not presently include Statistics.
This PR as a whole introduces a problem in that CompoundTag is NMS and is not normally accessible by API meaning there is some whacky casting/instanceof checking which isn't very nice. As such this is meant to open the discussion on how best to implement this PR
I do not really think there is great room in the api for this. This is something I would say would be better to use mixins for, by using a third party launcher such as ignite.
Exposing internal api in an Object is not really great, and I feel like if something were to be added like this, this would be better to be covered by using the Property api. (Properties will cover wrapping around nbt objects essentially)
And not to mention, what are the use cases for this? I would guess it's just due to the poor api of OfflinePlayer, but, would love some more context here.
I do not really think there is great room in the api for this. This is something I would say would be better to use mixins for, by using a third party launcher such as ignite.
Exposing internal api in an Object is not really great, and I feel like if something were to be added like this, this would be better to be covered by using the Property api. (Properties will cover wrapping around nbt objects essentially)
And not to mention, what are the use cases for this? I would guess it's just due to the poor api of OfflinePlayer, but, would love some more context here.
I brought this fork over from Loka's fork of Paper because we use this to completely store playerdata on our mongodb server. Loka is a multi-server survival setup where we need to save playerdata in db, move player to a server, then load it on the destination server, etc.
There are plenty of servers out there that also do this (each probably with their own bespoke management). So, mayhaps there isn't enough demand for this PR to be worth yet, it but it comes up from time to time in #paper-dev.
I could also see people using this simply as a means of storing more data in player nbt, though without said Property API that is an unholy experience not for the faint of heart.
I recently added something similar in my fork to allow players to have different "Profiles", each having its own inventory etc. Of course this could also have been achieved by just setting the inventory and all properties later, but just replacing the player data seemed cleaner to me.
This could also be useful if you want to synchronise player data between different servers or otherwise store it externally, as well as for inventory backup plugins.
I would really like to see this in Paper somehow, but the NMS data structure is a bit of a problem for sure.
Actually exposing data in the events will get really messy to support across versions - having some sort of DAO passed in each event would just be impossible to maintain.
However, I feel that this approach where the plugin can dig into the internals upon the event being called is better than nothing.
PS your diff bad and these events should probably be in the papermc.io package?
Yea we'd 100% would need experimental annotations for this. Honestly I agree with owen here, preferably this lands after we get initial properties support that can wrap plain CompoundTag instances for mutation.
That way we can represent the data as a property getter/setter type instead of a plain CompoundTag or Object.
I think that in general it may be worth closing this until more proper api can be used to represent serialized entity data. Afterwards, I certainly see there being benefit with some sort of generic serialize entity event and what not.