Adding valueless tags to PersistentDataContainer
Nobody has claimed this yet.
- 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?
When using a PersistentDataContainer to hold Booleans, you can basically treat the key existing as the boolean value. So, I figured why not add a way to make a valueless tag so I can just store a NamespacedKey on a PDC and check if it exists.
Describe the solution you'd like.
A new function could be added to PersistentDataContainer
void tag(NamespacedKey key)
All it'd do is run set(key, PersistentDataType.BOOLEAN, false) or something.
Then, you can use PersistentDataContainerView#has and PersistentDataContainer#remove like you would now.
Describe alternatives you've considered.
Alternatively, multiple functions could be added so that tags don't interfere with any other data stored on the entity. Adding a list of strings to the NBT data would do this fine.
Three functions would be added to the API (I'm a little unsure of the internal PDC workings, sorry)
Inside PersistentDataContainerView:
boolean hasTag(NamespacedKey key)
Inside PersistentDataContainer:
void tag(NamespacedKey key)void untag(NamespacedKey key)
Alternatively, it could be addTag and removeTag.
These could be stored in a list attached to the NBT data, or it could assign a value of 0 internally.
Other
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the PersistentDataContainer and PersistentDataContainerView API entry points named in the issue, then compare the existing set, has, and remove behavior. Done means reaching a settled design for valueless tags, including their interaction with existing data, and documenting or implementing the proposed API consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100