EnchantmentType - prepare for MC 1.21 custom enchantments
Description
This PR aims to prepare Skript for future changes with Enchantments. Minecraft has moved enchantments to be data driven in 1.21. This also means the ability to create custom enchantments. This PR helps prepare Skript for that change by using the Bukkit registry rather than hard coding and using the specific fields.
Mojang is planning a 1.21 release for sometime this summer. I figured it would be best to prepare ourselves now.
NOTES:
- parsing will first attempt to grab from lang file
- if parsing fails from lang file, we move on to get from key from Registry (this allows for parsing custom enchantments)
- toString will first attempt to find the a name from the lang file (ex: "Curse of Vanishing 1")
- if that fails, will send the key for a vanilla enchantment (ex: "vanishing_curse") or the full namespace for custom enchants (ex: "my_thing:explosive")
- Static Enchantment related methods/fields have been moved to EnchantmentUtils
Target Minecraft Versions: 1.21+ Requirements: none Related Issues: none
I might prefer to keep support for custom names for Minecraft-provided enchantments. That is, one could write minecraft:vanishing_curse or curse of vanishing. This would keep the process automated but allow us to provide support for the typical representation of an enchantment's name. I'm not a super big fan of just vanishing_curse or vanishing curse (i think requiring the namespace is better when not using a Skript-provided name alias)
I might prefer to keep support for custom names for Minecraft-provided enchantments. That is, one could write
minecraft:vanishing_curseorcurse of vanishing. This would keep the process automated but allow us to provide support for the typical representation of an enchantment's name. I'm not a super big fan of justvanishing_curseorvanishing curse(i think requiring the namespace is better when not using a Skript-provided name alias)
thats probably a good idea, for a little backwards compatibility too
Seconding pickle Always have the key-based names, but also allow custom names via .lang
Converted back to draft. Once my registry PR is merged, I'll rework this a bit to work with that also.
Ok, back to being ready!