Add data-driven shields

[StellarWind22]

Allow items to be treated as shields by simply including them in the #fabricshieldlib:shields tag. Any shields registered this way will just use default settings(cooldown);

[rikka0w0]

Is this still work in progress?

[CringeStar]

Still brainstorming it. Currently we're more focused on updating the wiki page and ironing out bugs.

[rikka0w0]

The int getCoolDownTicks(); and boolean supportsBanner(); in interface FabricShield should return the vanilla value by default, so that modders can simply implement the FabricShield interface to make their custom shield.

Speaking of the data-driven shields, my suggestion is to create a shield registry similar to how the vanilla biome registry works. The shield characteristics are described in JSON files (/data/<mod_id>/fabricshieldlib/shield/<shield_name>.json). The "shield_name" should match the item name of the shield. Each of those JSON files will be serialized into instances of a Java record (Lets call it FabricShieldProperty).

We use Mixin to add a method (public @Nullable FabricShieldProperties getShieldProperties();) to the vanilla Item class. Upon the first call, it looks up the FabricShieldProperty from the shield registry and then caches the result (can be null). In the Fabric shield lib implementation where we need to get info about the shield, we first retrieve the item, then examine the return of its getShieldProperties() method. A shield should have a non-null return value.

[rikka0w0]

Another way of doing this is to take advantage of the DataComponent system introduced in 1.21.

We will consider all items in #fabricshieldlib:shields as shields (perhaps should be the conventional shield tag?). When a player is holding these items, he can block attacks just like a vanilla shield. The cooling downtime and enchantment value are the same as the vanilla shield.

If a modded shield wants to have a different cooling downtime or enchantment value, the modder can add a newly-defined
DataComponentType called FabricShieldProperty and put specifications there. If FabricShieldProperty is not present on a modded shield's DataComponent list, vanilla values will be used.

[rikka0w0]

See my progress here: https://github.com/rikka0w0/Fabric-Shield-Lib/tree/experimental

[CringeStar]

The int getCoolDownTicks(); and boolean supportsBanner(); in interface FabricShield should return the vanilla value by default, so that modders can simply implement the FabricShield interface to make their custom shield.

Yeah, makes sense! I wonder why we ddint do that in the first place lol.

We will consider all items in #fabricshieldlib:shields as shields (perhaps should be the conventional shield tag?).

We only use the proprietary tag in versions where the c: isnt available.

When a player is holding these items, he can block attacks just like a vanilla shield. The cooling downtime and enchantment value are the same as the vanilla shield.

Yeah that's basically @StellarWind22 's initial plan with this. Would this just entail changing every check for "FabricShield" into a check for "c:shield"?

If a modded shield wants to have a different cooling downtime or enchantment value, the modder can add a newly-defined DataComponentType called FabricShieldProperty and put specifications there.

Yeah, sounds good!

newly-defined DataComponentType called FabricShieldProperty and put specifications there. If FabricShieldProperty is not present on a modded shield's DataComponent list, vanilla values will be used.

Sorry, but I am not very familiar with DataCompnents yet (school hasn't given me time to look into them), but how would this change the item initialization process? Would devs still just do new fabricshielditem or would we have to change the process up?

See my progress here: https://github.com/rikka0w0/Fabric-Shield-Lib/tree/experimental

Will check out after exams along with your PR #182!

[CringeStar]

See my progress here: https://github.com/rikka0w0/Fabric-Shield-Lib/tree/experimental

I LOVE the FabricShieldUtils.java you made! I still have to look at the rest of the repo, but I just wanted to check out the utils file after I saw it in your PR/