Apply resolvable default item components to every Item#6375
Open
eclipseisoffline wants to merge 7 commits into
Open
Apply resolvable default item components to every Item#6375eclipseisoffline wants to merge 7 commits into
eclipseisoffline wants to merge 7 commits into
Conversation
eclipseisoffline
changed the title
onebeastchris
requested changes
May 12, 2026
Member
onebeastchris
left a comment
onebeastchris
left a comment
There was a problem hiding this comment.
I miss the times when item code was session agnostic :p
onebeastchris
added
PR: Under Review
eclipseisoffline
force-pushed
the
resolvable-default-item-components
branch
from
356eab8 to
340633a
Compare
onebeastchris
approved these changes
May 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR refactors Geyser's
ComponentCache/ResolvableComponentsystem to be applied to everyIteminstance, and not justNonVanillaIteminstances. Since the only reason theNonVanillaItemclass existed was to support the resolvable component system, this class has been removed.Resolvable data components, or resolvable components for short, are data components that have to be resolved once a session has successfully configured. Usually, this is because the values of these components contain data-driven registries, and we (or rather, MCPL) stores the values as integer, network IDs. These network IDs can change for every session as the registry is data-driven/dynamic.
Geyser loads every item's default/standard data components at start-up, from a mappings file generated by the mappings generator. It does this by using MCPL's data component readers. The mappings file is generated using a vanilla datapack, and thus, the IDs MCPL is reading for resolvable components are only necessarily true for servers using that vanilla datapack. As such, these values can very quickly be wrong for servers having datapacks or modifying data-driven registries in other ways.
This was not a problem in Minecraft 1.21.11 and below, as Minecraft serialised these data-driven default item components using their identifier, and not their network ID (see: 1.21.11's
EitherHolder).The solution to this is simple: we already have a
ResolvableComponentsystem in place for non-vanilla items, so this PR expands this system to apply to every item. Now, at startup, Geyser also reads a "resolvable components" mappings file, which contains identifiers of resolvable components, instead of network IDs. Then, whenever a session finishes the configuration stage, the resolvable components' respective MCPL values are read into the session'sComponentCache.The mappings file is generated by a new generator in mappings-generator#94, the generated file is in mappings#116. This PR depends on both of those PRs.
The loading of the new mappings file has been tested, simple gameplay testing is still a TODO.