Client Exception when using a Mekanism Cardboard Box on a Jabba Barrel
Jhary opened this issue ยท 4 comments
Here is the exception I get. The client does not crash completely but you will be kicked out of the world (at least in SMP) and have to log back in. Unpacking the box is ok, but packing the barrel in does this. I don't know on which end the error can be fixed, so I will post that in both issue trackers.
Just a thought on this: We have a packet limiter in JABBA so that packets are only sent every X amount of time (default half a second). What is happening here is that the server is sending packet info for a TE that the server expects to be a barrel, but on the client it is seeing a cardboard box.
I believe this is because the CardboardBox Item does not check against side when it is used, and as such it is running on client and server side. See here : https://github.com/aidancbrady/Mekanism/blob/master/src/main/java/mekanism/common/item/ItemBlockCardboardBox.java#L75
So what is happening is the client is using the box and immediately on the client side it is changed over to the box TE. On the server side it is not yet a box and a packet for a barrel may be getting sent out, then the TE is being changed over to a box. So the client receives a barrel packet, sees a box TE instead of a barrel TE and closes out. Upon reconnecting, the world data is sent from the server again and the server and client both see a box.
I believe that just adding a if (world.isRemote) { return false; } to the top of the above linked function should stop this crash. All logic will then be done server side and the client will receive its updates in the proper order due the the 3 flag in the set block call.
Okay, i missed the side check on L82, sorry about that. Since that is there, this issue shouldn't be occurring. It is an issue with something out of order in such that the client is being updated to a box while the server is still thinking it's a barrel. I'll investigate more.
This should be resolved on our side, sorry about this. I checked our packet code and it wasn't checking if a TE is still valid before sending packets. It now does. Next release will have the fix.
This issue should be able to be closed now.
