[Question] How to load extra mod with mod

Here’s what I tried:

1. Running as a language adapter. Implement ModCandidateFinder and inject the mods to FabricLoaderImpl#mods. Working in 1.16, 1.17.
   • Throw ClassNotFoundException with FabricLoader class loader. My classes not in classpath.
   • Throw SecurityException after I add my classes to classpath.
2. Set system properties for using ArgumentModCandidateFinder. But it’s called before language adapter.

[EZForever]

Author of ThatOrThis here. I’m 110% against using hacks to inject mods into the loader, but it just can’t be done the other way back when the mod is out. Now that Fabric Loader has evolved to support loading mods from additional directories, and class injection just got much harder with that package signature (just why?), I’m willing to do a rewrite. However there are other problems yet to be solved.

You’ll have to wait for us to add the appropriate APIs to have a clean solution.

I actually don’t think it’s the loader’s job to provide the APIs. Fabric Loader has one job - loading mods into Minecraft - and it’s doing it well enough. All we need is a way to tell the loader which mods to load, and we have fabric.addMods now. Though I’d admit it will be painful to write a wrapper (with Knot, the entrypoint, being an implementation detail) or even half a game launcher to utilize just that. Besides, considering that #81 is still open after 3 years, I guess there’s just more important stuffs for the loader devs to do. btw, being harsh really isn’t going to help anybody.

[warjort]

Ok, this is caused by fabric loader signing the jar https://github.com/FabricMC/fabric-loader/blob/d713b2a801ad142394ac0eb1d1eaa452fc783021/build.gradle#L278

That kind of seals the packages. You can’t add new classes into those packages in the same classloader unless you also sign your jar with the same signature. Of course you can’t do that because you don’t have access to fabric’s private key.