AbstractMethodError on world load with OpenComputers
SanAndreaP opened this issue ยท 4 comments
RFTools: 7.14
McJtyLib 2.5.0
OpenComputers: 1.7.0.124
Minecraft: 1.10.2
Minecraft Forge: 12.18.3.2511
After updating RFTools from 7.13 to 7.14, I crashed with the following stacktrace on world load:
java.lang.AbstractMethodError: mcjty.rftools.blocks.screens.ScreenControllerTileEntity.getComponentName()Ljava/lang/String;
at li.cil.oc.common.asm.template.StaticSimpleEnvironment.node(StaticSimpleEnvironment.java:33)
at li.cil.oc.common.asm.template.StaticSimpleEnvironment.writeToNBT(StaticSimpleEnvironment.java:83)
at mcjty.rftools.blocks.screens.ScreenControllerTileEntity.func_189515_b(ScreenControllerTileEntity.java:57)
at mcjty.lib.entity.GenericTileEntity.writeClientDataToNBT(GenericTileEntity.java:162)
at mcjty.lib.entity.GenericTileEntity.func_189517_E_(GenericTileEntity.java:151)
at net.minecraft.network.play.server.SPacketChunkData.<init>(SourceFile:52)
at net.minecraft.server.management.PlayerChunkMapEntry.func_187272_b(PlayerChunkMapEntry.java:156)
at net.minecraft.server.management.PlayerChunkMap.func_187302_c(SourceFile:202)
at net.minecraft.server.management.PlayerChunkMap.func_72683_a(SourceFile:227)
at net.minecraft.server.management.PlayerList.func_72375_a(PlayerList.java:299)
at net.minecraft.server.management.PlayerList.func_72377_c(PlayerList.java:369)
at net.minecraft.server.management.PlayerList.initializeConnectionToPlayer(PlayerList.java:163)
at net.minecraftforge.fml.common.network.handshake.NetworkDispatcher.completeServerSideConnection(NetworkDispatcher.java:260)
at net.minecraftforge.fml.common.network.handshake.NetworkDispatcher.access$100(NetworkDispatcher.java:73)
at net.minecraftforge.fml.common.network.handshake.NetworkDispatcher$1.func_73660_a(NetworkDispatcher.java:209)
at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:287)
at net.minecraft.network.NetworkSystem.func_151269_c(NetworkSystem.java:180)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:732)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:613)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:149)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471)
at java.lang.Thread.run(Thread.java:745)
I suspect it has something to do with the reimplemented computer screen module.
Downgrading RFTools back to 7.13 fixes this issue (but only after restoring from backup, as the crash somehow corrupted Chisels and Bits data)
Here's the full log: https://gist.github.com/SanAndreasP/1901e0b528eed8541f04d218670639b4
I tried to reproduce this issue with CompatLayer 0.2.9 and all of the other relevant mods that you listed, and it works fine for me. Can you try removing all mods except for RFTools, OpenComputers, and their dependencies, and seeing if it will load for you?
Also, is it only your existing world that does that, or can you not start new worlds either?
Never mind, I played with it some more and did get it to crash in a minimal environment. The trigger to making it crash is putting an OpenComputers adapter next to an RFTools screen controller.
Okay, here's what's going on:
- We make the screen controller work with OpenComputers by having it implement the SimpleComponent interface, and creating the relevant methods, including getComponentName().
- We mark that interface and those methods with Forge's @optional annotations so that they get stripped if OpenComputers isn't there. If we didn't do this, RFTools would depend on OpenComputers (or at least its API).
- OpenComputers' mod ID is "OpenComputers" in 1.10.x, and "opencomputers" in 1.11.x.
- When we use the @optional annotation, we give the mod ID "opencomputers". This means that in 1.10.x, Forge thinks that the mod isn't there and strips the interface and methods.
- Normally, this would be the end of it: the screen controller wouldn't work with OpenComputers since the interface is missing, but there'd be no crash either.
- However, OpenComputers uses a coremod that complicates this: they register an ASM transformer that looks for any classes that implement SimpleComponent, adds some methods to them, then makes them implement another interface too: SimpleComponentImpl. This new interface doesn't get annotated with @optional.
- The coremod runs before Forge strips anything. This means that after Forge does its stripping, the screen controller doesn't implement SimpleComponent or contain its methods, but it does still implement SimpleComponentImpl and contain its injected methods.
- These injected methods try to call the methods that we wrote and were stripped, leading to the crash since they're no longer there.
Note that none of this is specific to screen controllers or the computer screen module; it affects any OpenComputers integration that we'd try to do. I don't see any way to make OpenComputers integration work on 1.10 and 1.11 with the same codebase other than getting a change into Forge, coremodding ourself, or getting OC to tweak their coremod.
Update: Having thought about it, I believe the cleanest way to fix this is in OC. I opened MightyPirates/OpenComputers#2649 about it.
This has been fixed on OpenComputers' side. Their next release will contain the fix, but if you don't want to wait, you can use this experimental build. Version 1.7.1.150 contains the fix, so update if this affects you.