The class should be outside the package excluded by the annotation on your loading plugin, otherwise it won't get remapped from SRG to MCP names when running in-dev with a release jar. In general nothing in a coremod or in an asm package should reference a minecraft class.

Hey sfPlayer1, Thanks for the tip, I'm not sure I understand though. When publishing, all OTG asm classes are split from the main project and published as a seperate jar via Gradle. The coremod jar is then included in the main jar and is unpacked by Forge at app start. This seems to work fine in both dev and production. Am I misunderstanding something here? Thanks!

By package I mean the Java package as used for the prefix in full class names (some.package.MyClass), not the packaging of the coremod, which doesn't affect the problem.

The class com.pg85.otg.forge.asm.OTGHooks is in the package com.pg85.otg.forge.asm, the loading plugin has @TransformerExclusions(value = { "com.pg85.otg.forge.asm" }). This means that the class OTGHooks gets excluded from being processed by transformers, including the SRG->MCP renaming transformer.

OTGHooks references MC members directly, in your production jar they carry SRG names (func_.. or field_..). It is common practice to use such a production jar in-dev, relying on FML's runtime deobfuscation transformer to translating the references back to MCP names - if the class isn't excluded. Your specific setup prevents runtime deobfuscation from working.

In your case you want to move com.pg85.otg.forge.asm.OTGHooks to com.pg85.otg.forge.OTGHooks or another package outside the excludes.

It probably shouldn't even be part of the coremod jar, having a direct MC reference in a coremod defeats the main purpose of splitting it off in the first place. I'm fairly certain Forge didn't think about this case when coming up with the coremod separation policy.

Hey @sfPlayer1, thanks for clarifying! Moving the class out of the package because of the annotation makes sense, I hadn't tried running the production jar in-dev. As for using MC references, it seems to me the only obvious way. I assume you mean referencing MC code defeats the purpose because the MC classes I'm using might be exactly what I or someone else are trying to coremod? Do you have any suggestions as to how I could fix that? I can only imagine the mess of asm code I'd have to write in order to achieve the same results, compared to just injecting a few methods :/.

• com.pg85.otg.forge.asm.OTGClassTransformer implements net.minecraft.launchwrapper.IClassTransformer btw, it also contains asm code, not entirely sure what the intention is for that?

• If OTGHooks is not excluded, then will this code still work for excluded classes?

new MethodInsnNode(INVOKESTATIC, Type.getInternalName(OTGHooks.class), "getIDForObject", injectSnapShotDescriptor, false));

Note: "getIDForObject" is in OTGHooks.

Only code directly referencing Minecraft is problematic, proper transformer code doesn't do this. It only uses the string representation. The problem is that if a class A directly references another class B, e.g. in a method's signature, loading class A subsequently loads class B as well within the same context. This context may not be appropriate because it is from the wrong class loader, too early for others to register their edits or triggers infinite load recursion.

If I say "references Minecraft", I don't mean launchwrapper, most libraries or anything in FML's relauncher package. They are fine and partially required to be used. This means that using IClassTransformer is fine/required, it is the entry point for doing bytecode edits after all. You just can't use classes like net.minecraft.world.World and the likes.

Type.getInternalName(OTGHooks.class) was never correct, it may class load OTGHooks at the wrong time. This should use the string representation "some/package/containing/OTGHooks" (=qualified name with / instead of . for package part separators and $ instead of . for nested class separators) directly, instead of going through Type.getInternalName which yields the same string.

Resulting bytecode can access whatever it wants, it is not constrained in any way, only the transforming code needs to be carefully designed (contrary to the transformed code).

The trick is to use strings to describe MC or other non-asm references when emitting/modifying bytecode and moving code accessing outside the coremod, like you mostly did with OTGHooks. You don't have to do anything substantially different, it was really just an unfortunate package choice for OTGHooks and referencing OTGHooks directly instead of with a string.

*This should explain coremod crashes with Sponge and some non-vanilla launchers.

For v8_r2: OTGHooks is no longer excluded from transformations, any references to OTGHooks from the OTG-Core classtransformer use the string representation. String references to mc classes in the classtransformer have had their obfuscated representations added, which should hopefully fix problems for Sponge.

• Edit: Using obfuscated strings to represent mc classes doesn't work as expected. I've used mcpbot to find the obfuscated class name for Biome, which should be "anf" for 1.12, but by logging the names for a 1.12.2 Forge client I can see it's actually "anh". Still not understanding something here ><.

Hey @sfPlayer1, question, could you tell me what's going on with obfuscated mc class names in class transformers?

For instance:

• The method net.minecraft.world.biome.Biome.getIdForBiome() returns a net.minecraft.world.biome.Biome.
• According to mcpbot for 1.12.2, getIdForBiome() should be "a" obfuscated, and net.minecraft.world.biome.Biome should be "anh".
• When I run a Forge 1.12.2 client and log the methods and return types for BIome, I can see that method "a" returns "anf", and there are no methods returning "anh".

You said earlier that "class names stay the same with mcp<->srg", so what obfuscation am I seeing here?

These names are in what the mcp project calls the "notch" namespace, the names Mojang's obfuscator used when publishing the jars for a specific MC version/release.

anh is the correct name for the Biome class, no idea why you are seeing something else. The only method returning anf is net.minecraft.world.NextTickListEntry.setScheduledTime. It shouldn't appear in this context, your observation is likely off.

You can change the sorting order of your transformer to be after the deobfuscation transformer (translates notch->srg, priority 1000) to only deal with mcp (in-dev) and src (runtime) names.

Thanks that's good to know, will take a look at the sorting order. You're right about anf/anh, I've double-checked with some logging and it reports anh, not sure what I was doing wrong earlier.