search

Draconic-Inc / BrandonsCore

Other
22 stars 26 forks source link

Fix NoSuchMethodError when using on a dedicated server #92

Closed Web-44 closed 2 years ago

Web-44 commented 2 years ago

This fixes an issue when using this core on a standalone minecraft forge server.

How to reproduce:

  1. in minecraft 1.16.5 on forge install mods: BrandonsCore, DraconicEvolution, ComputerCraft
  2. build a standard reactor
  3. use the peripheral integration from DraconicEvolution via ComputerCraft to charge the reactor

My findings: This issue seems to be caused by CodeChickenLibs PacketCustom.sendToServer() method only existing in the Client. This mods Proxy already has a method to fix this but it is not used in TileBCore and therefore throws this exception.

Exception: [19:38:23] [ComputerCraft-Coroutine-21/ERROR] [computercraft/]: Error calling call on dan200.computercraft.core.apis.PeripheralAPI@3e63c4ec java.lang.NoSuchMethodError: codechicken.lib.packet.PacketCustom.sendToServer()V at com.brandon3055.brandonscore.blocks.TileBCore.sendPacketToServer(TileBCore.java:173) ~[brandonscore:1.16.5-3.0.12.240] {re:classloading} at com.brandon3055.draconicevolution.integration.computers.PeripheralReactorComponent.chargeReactor(PeripheralReactorComponent.java:73) ~[draconicevolution:1.16.5-3.0.20.440] {re:classloading} at com.brandon3055.draconicevolution.integration.computers.PeripheralReactorComponent$cc$chargeReactor135.apply(CC generated method) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading,re:classloading,re:classloading} at dan200.computercraft.core.apis.PeripheralAPI$PeripheralWrapper.call(PeripheralAPI.java:112) ~[computercraft:1.100.2] {re:classloading} at dan200.computercraft.core.apis.PeripheralAPI.call(PeripheralAPI.java:361) ~[computercraft:1.100.2] {re:classloading} at dan200.computercraft.core.apis.PeripheralAPI$cc$call94.apply(CC generated method) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading,re:classloading,re:classloading} at dan200.computercraft.core.lua.ResultInterpreterFunction.invoke(ResultInterpreterFunction.java:58) ~[computercraft:1.100.2] {re:classloading} at org.squiddev.cobalt.function.ResumableVarArgFunction.invoke(ResumableVarArgFunction.java:77) ~[computercraft:1.100.2] {re:classloading} at org.squiddev.cobalt.function.LuaInterpreter.execute(LuaInterpreter.java:491) ~[computercraft:1.100.2] {re:classloading} at org.squiddev.cobalt.function.LuaInterpretedFunction.resume(LuaInterpretedFunction.java:196) ~[computercraft:1.100.2] {re:classloading} at org.squiddev.cobalt.debug.DebugFrame.resume(DebugFrame.java:243) ~[computercraft:1.100.2] {re:classloading} at org.squiddev.cobalt.LuaThread.loop(LuaThread.java:566) ~[computercraft:1.100.2] {re:classloading} at org.squiddev.cobalt.LuaThread$1.run(LuaThread.java:463) ~[computercraft:1.100.2] {re:classloading} at dan200.computercraft.core.lua.CobaltLuaMachine.lambda$null$1(CobaltLuaMachine.java:80) ~[computercraft:1.100.2] {re:classloading} at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_332] {} at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_332] {} at java.lang.Thread.run(Thread.java:750) [?:1.8.0_332] {}

Web-44 commented 2 years ago

Moved to new pull request at Draconic Evolution mod. This seems to just fix the error but cause more bugs.