thedarkcolour/ExDeorum

[1.20.4-2.5] Registration of Network Handler loads client-only class on server

Closed this issue · 3 comments

EDIT> Getting a similar crash with Curios and their code looks correct too. This may be a NeoForge bug.

Server crashes on start up:

NeoForge: 20.4.225

https://mclo.gs/2Ggre9U

Caused by: java.lang.RuntimeException: Attempted to load class net/minecraft/client/player/LocalPlayer for invalid dist DEDICATED_SERVER
        at net.neoforged.fml.common.asm.RuntimeDistCleaner.processClassWithFlags(RuntimeDistCleaner.java:57) ~[loader-2.0.17.jar%2362!/:2.0]
        at cpw.mods.modlauncher.LaunchPluginHandler.offerClassNodeToPlugins(LaunchPluginHandler.java:88) ~[modlauncher-10.0.9.jar%2365!/:?]
        at cpw.mods.modlauncher.ClassTransformer.transform(ClassTransformer.java:120) ~[modlauncher-10.0.9.jar%2365!/:?]
        at cpw.mods.modlauncher.TransformingClassLoader.maybeTransformClassBytes(TransformingClassLoader.java:50) ~[modlauncher-10.0.9.jar%2365!/:?]
        at cpw.mods.cl.ModuleClassLoader.readerToClass(ModuleClassLoader.java:169) ~[securejarhandler-2.1.24.jar:?]
        at cpw.mods.cl.ModuleClassLoader.lambda$findClass$20(ModuleClassLoader.java:275) ~[securejarhandler-2.1.24.jar:?]
        at cpw.mods.cl.ModuleClassLoader.loadFromModule(ModuleClassLoader.java:288) ~[securejarhandler-2.1.24.jar:?]
        at cpw.mods.cl.ModuleClassLoader.findClass(ModuleClassLoader.java:275) ~[securejarhandler-2.1.24.jar:?]
        at cpw.mods.cl.ModuleClassLoader.loadClass(ModuleClassLoader.java:191) ~[securejarhandler-2.1.24.jar:?]
        at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
        at thedarkcolour.exdeorum.network.NetworkHandler.lambda$register$0(NetworkHandler.java:28) ~[exdeorum-2.5.jar%23409!/:?]
        at net.neoforged.neoforge.network.registration.ModdedPacketRegistrar.play(ModdedPacketRegistrar.java:74) ~[neoforge-20.4.225-universal.jar%23573!/:?]
        at thedarkcolour.exdeorum.network.NetworkHandler.register(NetworkHandler.java:27) ~[exdeorum-2.5.jar%23409!/:?]
        at thedarkcolour.exdeorum.event.EventHandler.registerPayloadHandler(EventHandler.java:188) ~[exdeorum-2.5.jar%23409!/:?]
        at net.neoforged.bus.ConsumerEventHandler.invoke(ConsumerEventHandler.java:26) ~[bus-7.2.0.jar%2370!/:?]
        at net.neoforged.bus.EventBus.post(EventBus.java:386) ~[bus-7.2.0.jar%2370!/:?]
        at net.neoforged.bus.EventBus.post(EventBus.java:365) ~[bus-7.2.0.jar%2370!/:?]
        at net.neoforged.fml.ModContainer.acceptEvent(ModContainer.java:210) ~[loader-2.0.17.jar%2362!/:2.0]

The sidedHandler.client() call doesn't appear to prevent the loading of classes used by the handler method when on a server (You'd think it should though).

public final class NetworkHandler {
public static void register(IPayloadRegistrar registrar) {
registrar.play(MenuPropertyMessage.ID, MenuPropertyMessage::decode, sidedHandler -> {
sidedHandler.client(ClientMessageHandler::handleMenuProperty);
});
registrar.play(VisualUpdateMessage.ID, VisualUpdateMessage::decode, sidedHandler -> {
sidedHandler.client(ClientMessageHandler::handleVisualUpdate);
});
// not sure if these stop working if they're in the wrong phase, so I'll put them in both
registrar.common(VoidWorldMessage.ID, buffer -> VoidWorldMessage.INSTANCE, sidedHandler -> {
sidedHandler.client(ClientMessageHandler::handleVoidWorldMessage);
});
}

public static void handleMenuProperty(MenuPropertyMessage msg, PlayPayloadContext ctx) {
ctx.workHandler().execute(() -> {
Player player = Minecraft.getInstance().player;
if (player != null && player.containerMenu instanceof AbstractMachineMenu<?> menu && menu.containerId == msg.containerId()) {
menu.setClientProperty(msg.index(), msg.value());
}
});
}

Somehow, changing the method references to lambdas seemed to do the trick.

Looks like this may have been caused by a wayward mixin from Inventorio:

https://www.github.com/RubixDev/Inventorio/issues/339

No, I was able to crash with no other mods. Still, that isn't the first mixin issue I've seen with Inventorio haha