Data Components

[Owen1212055]

This is like the item property api but split up into a lot of smaller chunks.

In this case, we replace item meta internally by a property map held on item stacks.

Opinions wanted:

• names
• serialization logic

[powercasgamer]

Suggested change

	+ // Paper
	+ // Paper start

[powercasgamer]

Suggested change

	+
	+

[powercasgamer]

Suggested change

	+ AIR(9648, 64), // Paper - air techncially stacks to 64
	+ AIR(9648, 64), // Paper - air technically stacks to 64

[Malfrador]

Not using vanilla names but "Datakey" instead is really confusing. Mojang officially (in changelogs) calls them "Item Stack Components" or "Data Components" and the Paper API should use a similar name - everything else is just confusing to users.

itemStack.getDataKeyMap().remove(DataKeys.HIDE_ADDITIONAL_TOOLTIP);
is a lot more confusing than just
itemStack.getComponents().remove(ItemComponent.HIDE_ADDITIONAL_TOOLTIP);

I don't think adventure components existing justifies deviating from vanilla naming so much. The distinction between a Text Component and a Item Component is clear enough.

Imagine someone wanting to look up a component they found in the API on the Minecraft Wiki, or the other way around. They wouldn't even know what search term they are looking for.
This is also gonna get worse if Mojang decides to adapt the same component system for other parts of the game, such as entities or block entities.

[kennytv]

General ideas

[kennytv]

Is there any use for this?

[Owen1212055]

So you can wrap around a patched map

[kennytv]

This should just accept/return PatchedDataKeyMap directly and possibly be moved to ItemStack or a separate interface

[Owen1212055]

Do we not want some kind of middle man object? So for example people could apply certain changes to multiple item stacks? (I would allow people to make their own patch sets)

[Owen1212055]

General changes:

• DataKey -> DataComponentType (legit just went with vanilla names, we can trim names if need be)
• PatchedDataComponentMap no longer has remove, but has unset, and reset. Which I think make the most sense in this case.
  • Reset will remove the patch present on the map
  • Unset will unset it (so, like !minecraft:tool)
• ItemStack now implements PatchedDataKeyMapHolder which contains methods like setData which can be accessed on ItemStack directly, rather than needing to call components() evey time

Builder Types:

• Unbreakable: Unbreakable.unbreakable().showInTooltip(false).build()
• ItemLore: ItemLore.lore().lore(List.of(Component.text("h"))).build()

It should be noted that there are builder for most components for future-proofing. Advanced objects that might hold a bit more context to them...

Additionally it helps gain a little more power in the data component API (such has being able to get the styled tooltip from the lore)

[kennytv]

No likey the "Abstract" prefix. Though in any case, I would move this to a different package

[Owen1212055]

Added new pot decoration / charged projectiles type.