Minecraft Version: 1.12.2
Inventory Tweaks Version: latest

https://github.com/CoFH/Feedback/issues/971
CoFH/ThermalExpansion@96934ae

Supposedly COFH tried to add support but there was a problem on IT's end.

Yep. Tried again. Here's the crashlog.

https://github.com/CoFH/Feedback/issues/1050

Something in your ASM doesn't work with our Void Satchel.

The implicated line is here which is just a call back into ASM.

The full trace seems like ASM, for some reason, is trying to look up a class during the writing of the modified bytecode (and fails):

Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: cofh.thermalexpansion.gui.slot.SlotSatchelVoid
at org.objectweb.asm.ClassWriter.getCommonSuperClass(Unknown Source)

...Quick google search around with that brings me to this StackOverflow question which seems likely -- I have frame generation on (because java complains if it's wrong and I am adding new methods which would presumably require it), and apparently something is going on in there that causes the correct generation to require knowing a common superclass.

Given the natures of the edits being contained in new functions, I could theoretically just build manual frames in the new methods and tell ASM not to generate them -- I've just never really looked up how you're supposed to do that since it's one of those extra weird parts of bytecode.

Additional comments:

InvTweaks is probably not the only thing that'd choke on this (I'm pretty sure most coremods use COMPUTE_FRAMES, especially if they're doing more invasive things), it just happens to be the only one actually editing that class.

Looking at your stuff I'd implicate this line as it's basically the only reference to SlotSatchelVoid and roughly matches the type of pattern I'd potentially expect to need that sort of information in the stack frame info.

Yeah, I just rewrote that to be this:

So I figured it out and have a workaround, but it's still kind of confusing.

if (isVoid) {
	addSlotToContainer(new SlotSatchelVoid(containerWrapper, 0, 80, 26));
	} else {
	addSlotToContainer(new SlotSatchelCreative(this, containerWrapper, 0, 80, 26));
}

and it works fine. Which...alright, whatever. It's logically the same thing but I can see why ASM might dislike that.

Feel free to close this up. I'm gonna have a hotfix for TE soon.

I threw up a basic note issue to look into removing the need for COMPUTE_FRAMES as much as possible, sometime, but if you're going to do that there isn't much need to keep this one open.