[1.18.X/1.19.X] Upcoming Configured 2.0.0 update will break Mixins
MrCrayfish opened this issue · 11 comments
I'm currently in the works of releasing a new update to Configured. Right now I am testing the mod on major modpacks and noticed your mod was causing an issue on launch, since the 2.0.0 update changes said classes your mod is applying mixins to. Having that said, Configured 2.0.0 will have an API that allows you to make any custom configs specs or config frameworks to work with the menus. You should no longer need Mixins to fix your custom iceberg spec.
Just thought I'd point this out before people start sending reports to your mod.
If you'd like to see how the API works, you can look at the following implementations in the base mod. You'll probably just be able to extend the Forge implementation for it to work.
https://github.com/MrCrayfish/Configured/tree/1.19.X/src/main/java/com/mrcrayfish/configured/impl
Oh this is wonderful news, I will switch over to using the API as soon as possible, thank you for letting me know.
I've finished up with this, unfortunately I wasn't able to extend your built-in Forge implementation, but your API made it very simple nonetheless. I've just released the 1.19.x version and will be releasing 1.18.x shortly. I'd like to ask, do you have any plans to support map values in future versions of Configured? My configuration system allows for them and I use them in several of my mods, but I couldn't find any easy way to get them to be represented in Configured.
Glad you found it easy it implement. Is there a specific reason why you couldn't extend the Forge impl? I can make changes since I haven't released the update yet. Unfortuanely it's not possible to represent new types at the moment, however I will likely do that in a patch after 2.0.0.
Also I noticed you may have by accident released a patch for Iceberg with the changes, however Configured 2.0.0 is not released yet.
One more thing, you can actually make Configured completely optional now since your classes will only be loaded if Configured installed. The provider triggers the class loading, however that will never be called if Configured is not present.
I looked at your code and made changes that potentially blocked you from extending the Forge impl.
MrCrayfish/Configured@e51ae8a
Oh and Configured is coming to Fabric too!
Glad you found it easy it implement. Is there a specific reason why you couldn't extend the Forge impl? I can make changes since I haven't released the update yet. Unfortuanely it's not possible to represent new types at the moment, however I will likely do that in a patch after 2.0.0.
Also I noticed you may have by accident released a patch for Iceberg with the changes, however Configured 2.0.0 is not released yet.
One more thing, you can actually make Configured completely optional now since your classes will only be loaded if Configured installed. The provider triggers the class loading, however that will never be called if Configured is not present.
Thank you for making those changes, I should be able to extend your Forge implementation now. My apologies for releasing the update early, I was under the impression that the 2.0 update was frozen. Configured should already be optional for Iceberg, I don't believe any compatibility classes will be loaded if it is not present.
I will be removing the explicit 2.x dependency from Iceberg so it will no longer stop your game from loading before everyone is able to upgrade, however this will break IcebergConfig compatibility with 1.x because I can't support both versions. I'll try to get that fix out later today.
Until then, just downgrade Iceberg--this was the only change in the update.
Thanks for all the help @MrCrayfish, I will close this issue now.
Okay, Iceberg beta version 1.0.48 has removed the version requirement for Configured. It still does not support 1.x, but it will no longer prevent the game from loading when the version is below 2.0.