Hello there,
I am a Forge mod developer working on porting my mod to 1.12, and while attempting to setup a server with Sponge installed, ran into a bit of a problem. My mod (internally known as “ANDAI”, loads as “andai_core”) has a coremod component, and has to transform some block classes. This apparently causes problems, since it runs before Sponge does. I’ve tried the bootstrap loader as well, with no improvements. Anything I can do, either as a server owner, or mod developer, to fix this issue?
Latest log: Crash log from attempting to load DivisionGuard with Sponge installed. · GitHub
Sponge version: spongeforge-1.12.2-2838-7.3.1-RC4079.jar
Sponge Bootstrap: SpongeBootstrap-0.7.1.jar
I can provide the mod list as well, but I know for certain that the conflict is with my own mod, which is closed source, but I can provide some insight if it helps. It transforms “BlockIce”, “BlockSnow”, “BlockSnowBlock”, “World”, and “WorldServer”.
Thanks in advance. Apologies if this is in the wrong section, I haven’t used Sponge before, or visited this forum extensively either.
It looks like there are multiple coremods loading, for the avoidance of doubt it would be helpful to just load your mod and sponge to ensure it isn’t caused by another mod.
It would be helpful to see the source of ANDAIClassTransformer and related classes so we can get a better idea what’s happening.
If you can’t provide that, there are some things I usually look for in troublesome coremods, usually it’s caused by a coremod loading a runtime class:
- Extending a runtime class, or having method signatures containing runtime classes. Sometimes I see coremods extending
DummyModContainer or similar.
- Directly accessing class names such as
WorldServer.class.getName(). This example pulls in the WorldServer class in the coremod classloader (IIRC the correct thing to do would be to load it through Launch.classLoader). It’s generally a bad idea to do this though, mixin will try to mitigate this by tainting a re-entrant coremod.
As a sanity check, I loaded up my mod in a clean server installation with no other mods. I got the same result. I looked into your suggestions - the coremod does extend DummyModContainer for showing up in the mods list, but with it removed, there were no changes. As for directly accessing class names, classes like WorldServer are referenced in the coremod, but not for actually accessing bytecode. Here’s some of the source code: Gist. I didn’t include some like ASMSnow or ASMItemStack, since they don’t seem to be executed before the error occurs, but all the changes I made to block classes generally involve replacing the updateTick method.
https://gist.github.com/Unknown025/d444d39b051a44ec524acfc3f7c4362d#file-asmworldserver-java-L71
public static void patchSnow(WorldServer instance, BlockPos pos) {
This here is loading WorldServer and BlockPos in the coremod classloader.
You should put injected code in a separate class to the injector itself. Same goes for the other injections you have there.
Perhaps as a general rule, it should be considered a “code smell” if we see both org.objectweb.asm and net.minecraft classes in the same file.
Yup, that fixed the problem. Thanks for the help, looks like I’ll take this opportunity to cleanup the coremod portion of my mod, and move all the methods to a different location.