[Note to Future Us] Innate Enchantment component findings

[fzzyhmstrs]

Recording this for when it comes time to deal with it in the porting..

While reviewing API design for Modifier Core, I came across a pretty glaring issue with the current state of Enchantments and Components.

1. Default Item components need to be fully defined at Item registration time. Not a builder, template, etc. a fully instantiated component.
2. Enchantments are dynamic, and the component requires RegistryEntry. Those aren't available at Item registration time... the dynamic registries haven't been loaded yet....
3. So how to attach enchantments to items at registration time?? (In vanilla, there is no way)

From this revelation, it seems doubly apparent that there will need to be a custom component, with mixins to the various places they were before to "cheat" the enchantment system into thinking they exist as normal.

In Modifier Core, I've solved the attachment problem (currently untested) by creating a construct I'm calling DynamicEntry, that lazily finds its RegistryEntry as needed from a stored RegistryKey, which we do have at Item registration time. You just finished making all those in the last code session.

• The reasoning behind this is that the enchantments (modifiers in my case) will never be needed before dynamic registries are loaded
• It safely fall back to null or an Optional just in case anyways
• The serialization is effectively identical, making the user-facing part in-game appear no different (both Key and Entry serialize to the identifier underneath).