Add ability to set molang tags for custom items

[onebeastchris]

These changes should allow for two things:

• Geyser would add a tag to all custom items, currently called "geyser_custom", that way, a molang query checking minecraft:is_geyser_custom now: geyser:is_custom would find all custom items.
• Ability to assign custom tags (thereby allowing tag group creating) via a "tags" entry. For this purpose, i added a nonnull set of strings to CustomItemData, which can be set either using an extension, or a mappings json. For the latter, the following format would specify additional tags to add:

"tags" : ["test:is_tag_one", "test:is_tag_two"]

(example query: query.equipped_item_any_tag('test:is_tag_one')) - any tag, including minecraft tags can be set. A namespace isn't necessary, but should exist for good measure.
Fixes #3988

[Camotoy]

Can we make our custom tag geysermc:is_custom?

[Kas-tle]

Imo it should use the same namespace we give to items/blocks which is geyser_custom:

[onebeastchris]

Not against changing the namespace (both for the custom tags, or the tag for all custom items), but imo it would be odd to name it geyser_custom:is_custom. Idk, not up to me

[onebeastchris]

For now, i went with Kastle's suggestion and set the namespace to "geyser_custom". Personally, i would prefer "geysermc" or maybe just "geyser"; but i see how consistency would be nice.
With the latest commit, a tag would e.g. be geyser_custom:is_tag_one (only "tag_one" would be specified in the mappings). Could also drop the "is_" (although seeing how Minecraft does it, that again would be inconsistent).

[Konicai]

lgtm after this :)

[ofunny]

I have tested the default tag is_custom and also the assignment via the mapping file, both seem to work fine using e.g.
query.equipped_item_any_tag('slot.weapon.mainhand', 'geyser_custom:is_custom')

While doing the tests I noticed that my player controller is not handling all conditions with filled maps, bows and shields correctly, this is unrelated to the tag implementation (already existed while using is_name_any), but I soon will update my controller using tags. If that works well, this should be ready for merge.

[ofunny]

Works well for me, I implemented tags now in my test pack, here is an example for all custom shields within the "pre_animation" section.

                "pre_animation": [
                    "variable.is_blocking_main_hand = query.blocking && !query.is_item_name_any('slot.weapon.offhand', 'minecraft:shield') && !query.equipped_item_any_tag('slot.weapon.offhand', 'geyser_custom:is_shield') && (query.is_item_name_any('slot.weapon.mainhand', 'minecraft:shield') || query.equipped_item_any_tag('slot.weapon.mainhand', 'geyser_custom:is_shield'));",
                    "variable.is_blocking_off_hand = query.blocking && (query.is_item_name_any('slot.weapon.offhand', 'minecraft:shield') || query.equipped_item_any_tag('slot.weapon.offhand', 'geyser_custom:is_shield'));",
                    "variable.is_using_bow = (query.is_item_name_any('slot.weapon.mainhand', 'minecraft:bow') || query.equipped_item_any_tag('slot.weapon.mainhand', 'geyser_custom:is_bow')) && (query.main_hand_item_use_duration > 0.0f);"
                ],

Had no issues so far related to this implementation.

[onebeastchris]

Updated to latest master changes:

• Deleted ToolBreakSpeedsUtils, not used anymore
• updated tags reading to how it's done with custom block tags here

Worth noting: minecraft:is_pickaxe, minecraft:is_axe, minecraft:is_shovel, and minecraft:is_hoe are no longer set; this however shouldn't be major since you can now set your own tags however needed

[Camotoy]

geyser_custom:is_custom just sounds weird... I'm fine with geyser:is_custom (or the geysermc namespace) because it's a tag we define, and not one a user creates.

[onebeastchris]

https://github.com/GeyserMC/Geyser/blob/master/core/src/main/java/org/geysermc/geyser/registry/mappings/versions/MappingsReader_v1.java#L500-L509
Considering block tags can be set now, I'd use the same namespace that's set for the tags there - although I agree that geyser_custom:is_custom just sounds weird.
Inconsistency would be worse though

[Kas-tle]

Actually blocks just let you set whatever you want so I'm fine with that. For tags the namespace isn't even required it's only convention.

[onebeastchris]

Addressed; now the namespace for tags is just "geyser" instead of "geyser_custom".

[Kas-tle]

But why are we forcing any namespace? We can just use whatever they give us like for blocks?

[onebeastchris]

Sure, that should work
Only reason I had a namespace is because the Mojang item tags that can be used for queries are similar to "minecraft:is_pickaxe", I assumed we wanted to follow that.
Would you suggest dropping the namespace fully?
Imo "geyser:is_custom" sounds better than just "is_custom"

[Kas-tle]

Oh sorry I thought you meant forcing user tags to have a namespace. Whatever you want to do for the global custom item tag is fine.

[onebeastchris]

After internal discussion + Kastle's comment; changed it so no namespace is set at all. Can be defined manually though, which together with the changes made in the recipes PR (usage of itemTags wherever feasible/useful in recipes) might come in handy to set a minecraft namespaced tag; atleast in theory.
I will then leave geyser:is_custom namespaced, since a tag added by us would then be unlikely to conflict with other custom tags set.

Addressed; please re-review :)

[Kas-tle]

Also should update the wiki^