Closed yuuka-miya closed 9 years ago
That should fix it, let me know if it doesn't.
It doesn't. Here's a build of FE including mixins and this bug: http://1drv.ms/1EHWnl6
EDIT: Seems as though FML still thinks it's looked through the file: http://puu.sh/g9eC8/074a31570b.png
It seems as though I may be forced to write my own tweaker which implements both Mixin's and my own coremod, which then injects my forge mod with voodoo magic (since coremods are treated as tweakers).
Another EDIT: On further investigation, it seems that the Mixin tweaker is removing the class from the list of loaded coremods BEFORE FML even adds it. This is either inconsistencies in FML behaviour that needs to be changed (is it even possible), or the need for Mixin to be able to initialize via host coremod/tweaker instead of specifying its own which then loads the host coremod/tweaker (once again, if possible).
What I don't quite understand is how this is working for @Zidane (who is also using it in 1.7.10) and not for you. The logic for the tweaker goes like this:
ITweaker
and is a handle to the coremod instanceForceLoadAsMod
key in the manifest, the tweaker attempts to remove its container from the loaded list in order to give FML a shot at loading the coremod normally on a second pass.However, all of this is based on 1.8 behaviour because Mixins is a 1.8 project and that's all I care about, 1.7.10 compatibility is added as a courtesy but I cannot really devote the time to troubleshooting 1.7.10 issues.
Things I know:
This means you should:
This is the limit of support I'm prepared to provide for 1.7.10 though, developing for outdated versions of minecraft is something we should all collectively discourage because all it does is pour more fuel on the fire of modders not bothering to update their stuff because "everyone's still on x version". The absolute limit of previous versions I'm prepared to entertain support for is the very latest release on 1.7.10, but no other previous versions under any circumstances.
Alright, thanks for the help anyway.
EDIT: Is it possible for me to use my own tweaker to do mixin initialization?
@luacs1998
https://github.com/AlmuraDev/AlmuraSDK
Take a look at how I use Mixins here. I can absolutely confirm that this does work for 1.7.10.
Alright, thanks for the help anyway.
Don't get me wrong, if you come back and say to me "I've figured out you need to make x, y, z change and then this'll work in 1.7.10" then I'll add that no problem, but the focus of development has to be 1.8 and I can't really devote the time for troubleshooting on an outdated platform.
EDIT: Is it possible for me to use my own tweaker to do mixin initialization?
Yes absolutely, the tweaker in the package is provided for convenience but ultimately it doesn't matter which tweaker actually gets the ball rolling.
Hmm, I'm doing the exact same things as Zidane (from what I see), but why is mixin complaining that it isn't in the right classloader when I try to getEnvironment() in my coremod? Must I reflectively call MixinBootstrap.init()?
Just thinking out loud here.
Because you can't initialise the mixin environment from a coremod in production, as I said, the mixin environment must be initialised from a tweaker in a production environment. In dev, it's safe to dispense with the tweaker and use the coremod, that's why both bits of code exist: one handles dev, the other handles production.
Once it's successfully initalised in the right classloader, it's safe to call getEnvironment
from elsewhere, but the MixinBootstrap.init()
must be called in the system classloader. The bootstrap handles excluding the mixin package from the LaunchClassLoader in order that this state of affairs obtains.
MixinTweaker only supports the post-MC 1.8 FML CoreModManager (net.minecraftforge.fml namespace), whereas other parts of the mixin codebase support the cpw.mods.fml namespace used by FML before MC 1.8.
This "bug" has prevented me from being able to test FE, which employs mixins in a 1.7.10 environment, within a production workspace.
Will this be fixed?