Move various settings from NonVanillaCustomItemData to CustomItemData and allow use in JSON mappings

[eclipseisoffline]

This PR moves various settings from the NonVanillaCustomItemData to the CustomItemData class, which is useful for datapack/server side mod developers when porting custom items to Bedrock using Geyser's mapping system.

Properties that have been moved to the super-interface:

• stackSize
• maxDamage
• attackDamage
• armorType
• protectionValue
• isHat
• isFoil
• isEdible
• canAlwaysEat

The builders for these classes have been correctly updated, alongside the implementations of these classes and their use in CustomItemRegistryPopulator.

A few notes:

• The NonVanillaCustomItemData.Builder class has been given overrides for the moved properties to allow for full backwards compatibility.
• The private isTool boolean field in the implementation of NonVanillaCustomItemData (GeyserNonVanillaCustomItemData) has been removed. It was already replaced with displayHandheld and wasn't used anywhere in the implementation anymore. It was not publicly available.
• The constructor of GeyserCustomItemData has been simplified to simply take its builder as argument.
• To not change the behaviour when the stack size is unset when extending vanilla items (in that case the Java base item's stack size is used), the stack size property has been changed slightly in implementation, which shouldn't be noticeable for API users. The Javadoc has been updated correctly:

  • Returns 0 if not set. When not set, Geyser defaults to the stack count of the Java item when based on a vanilla item, or 64 when registering a non-vanilla item.

• To not change the behaviour when the max damage is unset when extending vanilla items (in that case the Java base item's max damage is used), the max damage property has been changed slightly in implementation, which shouldn't be noticeable for API users. The Javadoc has been updated correctly:

  • Returns -1 if not set. When not set, Geyser defaults to the maximum damage of the Java item when based on a vanilla item, or uses 0 when registering a non-vanilla item.

• The stackSize and maxDamage methods now properly check that their values are compatible to each other, following the logic of Java Edition (so, when stack size is above 1, max damage has to be 0, and when max damage is above 0, stack size has to be 1). The Javadoc has been updated correctly:

  • Note that, to copy Java behaviour, setting the stack size of an item to a value above 1 will set the max damage to 0. If a max damage value above 0 was explicitly set, an exception will be thrown.

  • Note that, to copy Java behaviour, setting the max damage value of an item to a value above 0 will set the stack size to 1. If a stack size above 1 was explicitly set, an exception will be thrown.

• The createComponentNbt method for CustomItemData has been updated to continue supporting GeyserMappingItem as well.
• All properties moved are now supported in JSON item mappings as well, the MappingsReader_v1 has been updated accordingly.
• The wiki has to be updated to reflect the changes (I could make the PR).

All of the new JSON mapping properties have been tested, and backwards compatibility of using builder methods in NonVanillaCustomItemData.Builder in extensions has been tested as well, which all seem to work okay.

Feel free to suggest any changes and I'll be sure to implement them!

[Camotoy]

Code looks fine to me, but will delegate to someone else for API approval.

[onebeastchris]

Overall, looks good to me - please also target the api/2.4.1 branch, and we'll be able to include this in the upcoming 2.4.1 release. Thanks!

[onebeastchris]

Looks good to me now, thanks!
Please target the newly created api/2.4.2 branch :) Might need a rebase due to the way api/2.4.1 was merged into master though.

[Konicai]

thank you! sorry for the late review

[Camotoy]

We may want to note in the docs (maybe in the builder?) how setting these new values is client-side.

[Konicai]

do we want to force it to lowercase?