When a mod contains forge mod, coremod and mixin, the forge mod won't be loaded when used as dependency in dev environment

[Barteks2x]

MalisisCore is an issue again.

I probably just didn't notice it before when testing. The coremod and mixins load jut find, but the forge mod isn't loaded at all.

Log: https://pastebin.com/raw/NxuJqDqf

[Mumfrey]

But from the log it looks like it's specified on the command line, so are you sure you're running with --noCoreSearch? Basically mixin isn't managing the injection of the coremod if it's specified on the command line, which is an intentional situation generated as a solution to the previous issue.

[Barteks2x]

I tried with --noCoreSearch before, and thought maybe that was the issue so I removed that argument. I will post a log with --noCoreSearch in a few minutes.

[Barteks2x]

The log (cut after starting loading world because there was my own debug spam at starting from there):
log_mixin_malisiscore.txt

[Mumfrey]

All indications are that things are working as normal, can you verify that the malisis jar definitely contains an FMLCorePluginContainsFMLMod entry?

[Barteks2x]

This is the whole MANIFEST.MF copied as is

Manifest-Version: 1.0
Implementation-Title: jar
Implementation-Version: 1.12-6.0.5-SNAPSHOT
Built-By: Ordinastie
FMLAT: malisiscore_at.cfg
TweakClass: org.spongepowered.asm.launch.MixinTweaker
Implementation-Vendor: http://github.com/Ordinastie/MalisisCore
TweakOrder: 0
MixinConfigs: mixins.malisiscore.core.json
FMLCorePluginContainsFMLMod: true
ForceLoadAsMod: true
Created-By: 25.131-b11 (Oracle Corporation)
FMLCorePlugin: net.malisis.core.asm.MalisisCorePlugin

[Mumfrey]

Sorry I've been over the log with a fine-tooth comb and I seriously can't see anything wrong, everything looks like it should, I'm completely baffled as to why it wouldn't work unless there's some underlying issue in FML that we're inadvertently tripping over.

Literally as far as I can tell, the mixin fml agent is doing exactly what it's supposed to at exactly the right times. I have no idea how to proceed to be honest, we might need to get someone from forge to take a look at it.

[Barteks2x]

Oh well, right now I can get things to more-or-less "work" without the mod being loaded (all GUI textures are missing), even if forge complains about impossible errors. So I ca wait for it to be fixed.

Note that I will be away for the next 2 weeks, maybe with internet access on my phone. So if I don't reply, that's why.

[ghost]

I am having the same issue. My forge mod isn't being loaded at all when trying to use mixins with it in a development environment.

[Mumfrey]

I am having the same issue. My forge mod isn't being loaded at all when trying to use mixins with it in a development environment.

@V0idSt4r Open an issue, provide logs, you cannot just piggy-back on someone else's issue. This specific issue pertains to a very specific situation with using deobfCompile dependencies containing mixins and also a regular @Mod-annotated classes, it is not a general-purpose bandwagon thread, this is not a forum. Saying "me too" with no corollary evidence or even a basic description of your current setup and previously-taken troubleshooting steps just serves to pollute a perfectly sensible issue with unhelpful line noise.

Either make a new issue describing your problem, or provide logs to support and enhance this issue, but do not post further banal nonsense because I'll just delete it as off-topic next time.

[ghost]

This very specific situation happens to be the exact same situation I'm in. My mod has a coremod and a normal mod but is not being loaded, mixins is working fine. I don't see why it's necessary to open a new issue you'll just be copy pasting the same messages to both issues to get it solved.

[Mumfrey]

But you keep saying "your mod", when this issue is not about a mod, but is specifically about a mod being used as a dependency in development. You also still haven't provided any logs so I don't know what you're adding to this issue by simply saying "me too"?

Are you talking about your mod not being loaded from a jar container in production? Are you talking about it not loading as a deobfCompile dependency in development in someone else's workspace? You haven't provided any useful primary or corollary information about your issue, so your comments on this issue are of zero practical use to me in trying to rectify any underlying issue.

Provide some actual information, or open a new issue if your problem does not fit the criteria outlined above.

[ghost]

Yes, as a dependency in development. I'll provide logs when I get home today but I didn't see anything suspicious.

[Barteks2x]

Any progress on this? The issue makes it near impossible to work work on some parts of my code. I really don't know what other information I could provide to help find the issue.

[Mumfrey]

I've not investigated any further because as far as I can tell this is not a fault with Mixin. @V0idSt4r said he was going to provide logs since he's having the same issue but didn't actually do so. There's no indication from FML as to why it's skipping the malisis core container, by all accounts the normal discovery process does two things: it adds the container to the reparseable collection, and injects it into the classloader. Since the file is already in the classloader and mixin is adding the container to the reparseable collection itself (as shown in the logs) it just doesn't make sense why it wouldn't scan it, because the behaviour should basically be the same.

[Barteks2x]

I took a look at the relevant fml code, and it looks like reparseable collection is completely excluded from loading mods from classpath, and the mod obviously isn't in the mods directory. So now I'm puzzled as to how loading coremod+mod dependencies has ever worked in dev environment, as I don't see any other potential places where mods are added.

I was able to workaround it by adding this to my program arguments:
--mods=../../../../../../../.gradle/caches/minecraft/deobfedDeps/deobf/net/malisis/malisiscore/1.12-6.0.5-SNAPSHOT/malisiscore-1.12-6.0.5-SNAPSHOT.jar (with the amount of ../ adjusted to reflect directory strutcure)

[kashike]

https://gist.github.com/kashike/5032776729a99912c86baf1908cf1b58#file-gistfile1-txt-L792

[09:20:44] [main/TRACE] [FML/]: Skipping known library file /home/kashike/.gradle/caches/minecraft/deobfedDeps/deobf/net/malisis/malisiscore/1.12-6.0.5-SNAPSHOT/malisiscore-1.12-6.0.5-SNAPSHOT.jar

https://github.com/SpongePowered/Mixin/blob/master/src/launchwrapper/java/org/spongepowered/asm/launch/platform/MixinPlatformAgentFML.java#L184-L201
https://github.com/MinecraftForge/MinecraftForge/blob/1.12.x/src/main/java/net/minecraftforge/fml/common/discovery/ModDiscoverer.java#L50-L79

Adding the mod to the "reparseable coremods" list prevents it from being loaded when the mod is on the classpath.

[Mumfrey]

Hmm, okay that adds some useful info. I've been over and over the FML code and it seems like nothing changed so I was confused. So, maybe this works when the agent is managing a jar because FML somehow picks it up, but doesn't work when the thing is on the classpath already because it defeats FML's candidate scan?

So are we saying that the logic in the agent should be:

• If container is on classpath, don't add to reparseable collection
• If container is not on classpath and needs to be injected via agent, add to reparseable collection?

[kashike]

The only use of net.minecraftforge.fml.relauncher.CoreModManager#getReparseableCoremods is here, which is where the issue is. I think simply removing the addition of the container to the reparseable collection all-together should work - the mod is removed from the ignored mods list which is all that really matters to make it load.

[Mumfrey]

All of which seems sensible, but I know I added that code for a reason so I'm not ready to just blithely remove it in case it breaks whatever it was fixing in the first place. Unless something internal to FML changed since 1.8 and that code is now no longer needed of course.

[kashike]

Related:

• FMLCorePluginContainsFMLMod not supported by MixinTweaker #44
• c01d491

[kashike]

The code I linked in my comment above (usage of getReparseableCoremods) is the same as the current 1.12.x branch as it was in 1.8, it seems.

[Mumfrey]

So is it safe to assume that what I need to do is remove the action of adding the file to the reparseable collection if the file is on the boot classpath?

[kashike]

It seems that way, yes. It might be safe to remove the code that adds to the repaseable collection all-together.

[Mumfrey]

It might be safe to remove the code that adds to the repaseable collection all-together.

But it must have been there in the first place to address some issue, it wasn't just added at random. I seem to remember it being something like it adding the mods/coremods twice or something if it wasn't added. I'm not removing it to fix this issue if all it does it recreate the original issue.

[kashike]

The only thing I can find is #44.

From what I can see:
In FML, mods without the "FMLCorePluginContainsFMLMod": true manifest entry will be added to net.minecraftforge.fml.relauncher.CoreModManager#ignoredModFiles, which Mixin removes from when the manifest contains "ForceLoadAsMod": true, while mods with the "FMLCorePluginContainsFMLMod": true manifest entry will be added to net.minecraftforge.fml.relauncher.CoreModManager#candidateModFiles.
findModDirMods checks net.minecraftforge.fml.relauncher.CoreModManager#getIgnoredMods and if it contains the mod it is skipped, while net.minecraftforge.fml.common.discovery.ModDiscoverer#findClasspathMods will also ignore mods from net.minecraftforge.fml.relauncher.CoreModManager#getReparseableCoremods.

[Mumfrey]

@Barteks2x, @kashike has come up with a solution for this which I have merged, please can you let us know whether the issue is resolved with this build and re-open if necessary.

[Barteks2x]

It works.

[ghost]

Works, thanks.

[Mumfrey]

Cool, thanks for the reports. Also thanks to @kashike for having the time to look into it.