
[1.9.2] Shieldbearer causing disconnect
Closed this issue ยท 12 comments
Hi we're experience a netty error when the shield bearer attacks, with us getting disconnected from the dedicated server:
Both client and server is version 1.9.2
[19:31:07] [Netty Client IO #1/ERROR]: Exception occurred in netty pipeline io.netty.handler.codec.DecoderException: java.io.IOException: Packet 0/38 (class_2675) was larger than I expected, found 4 bytes extra whilst reading packet 38 at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:489) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:280) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:323) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:444) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:280) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) ~[netty-handler-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.82.Final.jar:?] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?] at java.lang.Thread.run(Unknown Source) ~[?:?] Caused by: java.io.IOException: Packet 0/38 (class_2675) was larger than I expected, found 4 bytes extra whilst reading packet 38 at net.minecraft.class_2543.decode(class_2543.java:47) ~[client-intermediary.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:519) ~[netty-codec-4.1.82.Final.jar:?] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:458) ~[netty-codec-4.1.82.Final.jar:?] ... 36 more
The packet that seems to be crashing is the Particle packet. Can you send the whole log? That will have the mod list, there may be something interfering with the particle system since this does not happen with just Mine Cells
Edit: misclicked and closed the issue by accident
Wow that's interesting, I'll list down mods that relate to particles that I have
Particle Effects 1.0.3
AsyncParticles 1.10.1
GeckoLib 4.7
Subtle Effects 1.9.1
Fancy Block Particles 20.1.4.1
Particular 1.1.2-hotfix
Cave Dust 3.0.1
Particle Rain 3.0.6
Full log: https://mclo.gs/YCIk0K4
I'll try to disable one of each to see what's causing it.
Okay, please let me know which one fixes it, so I can maybe figure out a fix! Most likely it's not Geckolib, I can say that much for now ๐
Upon testing and disabling them all, it seems to be still happening. Do you have any tips so I can pinpoint this further?
Upon testing and disabling them all, it seems to be still happening. Do you have any tips so I can pinpoint this further?
You could try doing the same to mods that may optimize networking. There's a few of them but I don't remember the names off the top of my head ๐
If that doesn't work you can do a binary search of finding the problematic mod, while keeping Mine Cells. But with this amount of mods that may be difficult.
I found this tool that may help: https://github.com/skycatminepokie/FabricBinarySearchTool
But I can't seem to find whether it has an option to always keep a certain mod included, and only search among the remaining ones
Alright I'll do a good ol' binary search. I'll post updates here when I can. Thank you!
Alright after several hours of troubleshooting here's what happened:, all of these have Mine Cells always enabled:
- Doing a full binary search method in singleplayer in a flat world, continuously spawning the shieldbearer, causes no disconnects. I did not find any mods that causes the disconnect in singleplayer
- I did a full comparison of both client side and server side mods, both when sides match (client-only mods excluded), shieldbearer in dedicated server causes client disconnect yet again.
- Did a full binary search BOTH on client and server side (pain in the ass lmao), multiple attempts are all successes and there is no disconnect whatsoever when half the modlist is only activated. Super weird since I can't nail it down if both halves of the modlist are always working properly.
- Tried having all the mods that are activated in dedicated server that is supposed to disconnect, to see if it will disconnect me too for singleplayer. No issues, it's literally the same mods when tested in a dedicated server.
Conclusion: It's something dedicated server specific but I can't nail it down since binary searching doesn't help as both halves work the first time, it's only when the whole modlist is active then it client disconnects.
By the way, I already have packet fixer mods active, bad packets, extra thicc packets, and packet fixer. At first it was only packet fixer which I need or it breaks the server, the other two I just tested for this specific problem.
I tried what I can, unless there is some way to extend the error to find out what's breaking it, I can't seem to find the issue when it comes to multiplayer dedicated servers.
Alright I think I found out the issue, it was the Explosive Enhancement mod. It was both in the client and the server.
Deleted server side, doesn't work. Disabled client-side, now it works flawlessly.
Wow! Looks like you guys have been on an adventure here! But your issue is in another castle... maybe possibly perhaps I actually don't know it might be Explosive Enhancement's fault lol
(Making my response here instead of Explosive Enhancement's issue so we can communicate on fixing it because I'm very confused - lots of info ahead sorry lol)
I won't have time to test this all out myself until at least next week, but I'm really confused how Explosive Enhancement might be causing the issue. Its marked as client side in its fabric.mod.json
, meaning that it shouldn't even load in a server environment. With that, I don't modify or even read any packets on the 1.20.1 version(I do some cursed stuff with packets in 1.21.2+, but that code/mixin should all be commented out or not even exist on 1.20.1 thanks to Stonecutter).
I took a very quick peek at how the particles here are being spawned, (ShieldbearerEntity#tick() L79 is what I found - lmk if its wrong) and it too shouldn't be causing any issues? There actually doesn't even seem to be a vanilla explosion, which means my mod should never run any code to begin with???????
Normal explosion & explosion emitter particles are used, but Explosive Enhancement never mixins to any vanilla particles. All it should do is change which particles get spawned during a vanilla explosion, so spawning in the normal explosion particle shouldn't matter.
I've had issues in the past where EE would disconnect clients because of its smoke particle trying to divide by zero, but that should have been fixed in EE 1.3 I think. The only other thing I can recommend for now is seeing if Explosive Enhancement 1.2.2 changes anything, because that's before I started using Stonecutter. Beyond that, I have no clue. I'll need to do some testing myself, but that needs to wait for now. If you guys find anything else(or just want to wait on me to test - both works! /lh), I'd love to know!
Yeah that my mistake putting a client side only mod on the server. I tried enabling it only client side and it was disconnecting me still.
I'll give EE 1.2.2 a shot and let ya'll know if it works.