Closed embeddedt closed 2 years ago
Thanks for the PR, you've inspired me to come up with something of my own. We'll compare and see which is more suitable.
After some consideration, is there an advantage of MixinBooter providing anything for implementing vanilla/forge mixins? After all, calling MixinBootstrap.init()
Mixins.addConfiguration
... is all you do. And Forge cannot really enforce dependencies, soft or hard, when loading coremods, for some reason @IFMLLoadingPlugin.DependsOn
is just unimplemented and useless.
After all, calling MixinBootstrap.init() Mixins.addConfiguration... is all you do.
The idea is to avoid shading Mixin into each mod. To do that there needs to be a mod providing Mixin. There then comes the issue of checking whether that mod is actually installed and available. Technically using Class.forName
and then checking for a ClassNotFoundException
works, but it's not the most ideal.
@embeddedt take a look at the support-early-mixins
branch: https://github.com/LoliKingdom/MixinBooter/tree/support-early-mixins
It works well with one minor change (added to this PR). This is even cleaner than how I did it; good idea!
Thanks! That rounds it up, I'll get it ready for next release.
This is related to our discussion in #12. Not sure if it's a 100% perfect solution, or if it works properly with mods in dev environments, but it seems to work in production just fine.
With this approach, implementing vanilla mixins is now very clean: one method in the
IFMLLoadingPlugin
here, and a standard setup hook here. This also allows the mod to load normally when MixinBooter isn't installed.What do you think?