PaperMC / PaperMC/Paper

Allow Editing PersistentDataContainers for OfflinePlayers

Open
#13,699 8 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status: needs triage
Dominant language
Java
Stars
12.7k
Forks
3.5k
Avg merge
3d 13h
Merged PRs (30d)
11

Description

Is your feature request related to a problem?

Currently, OfflinePlayer#getPersistentDataContainer returns a immutable PersistentDataContainerView. I was wondering what concerns there may be for just returning a PersistentDataContainer and allowing plugins to edit data for offline players.

Describe the solution you'd like.

I'd like OfflinePlayer#getPersistentDataContainer to return a mutable PersistentDataContainer.

Describe alternatives you've considered.

I read over #8177, and the main issue with the original idea seemed to be that it'd be weird to handle nbt data for a player that hasn't joined. I have 3 ideas on how to implement this. (technically 2 as I'm re-proposing one of the old solutions that didn't get commented on)

Firstly, just return null if the player hasn't joined before. Mention it in the docstring that if the player hasn't played before, then the returned value will be null. This was proposed in #8177, but was not commented on.
Secondly, add a tag like "hasPlayed" that maps to a boolean. Logic based on the existence of the data file (like OfflinePlayer#hasJoinedBefore) will just read that value.
Thirdly, If the main data file doesn't exist, save data to a .prejoin.dat file. This file would contain all the data for a player until they join, at which point the .prejoin.dat file would be merged with the main data file. After that, all future edits will just go to straight to the player's data file. This prevents any logic changes based on whether the file exists.

These solutions handle what to do if you don't want to allow editing the nbt data of players who haven't joined before, as well as what to do to prevent/address any logic errors based on the presence of the .dat file.

Other

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with OfflinePlayer#getPersistentDataContainer and review the behavior discussed in PR #8117. Resolve how mutable data should behave for players who have never joined, including persistence and merging on first join; done requires an agreed API and storage design.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.