[1.16.x] Packet Invalid Message

[urbanxx001 8]

I have a button in my screen class to send a packet to the container in order to update the inventory (client to server), according to this. Opening the gui and clicking the button in-game, I receive an invalid message error that originates from:

PacketHandler.CHANNEL.send(PacketDistributor.ALL.noArg(), new CapCompContainer(ModContainerTypes.MULTI_9X3.get(), containerID, containerInd, senderInv, 3));

According to this the issue could stem from registration, but I ensured that the packet is registered in FMLCommonSetup and specified the network direction PLAY_TO_SERVER.

 

Classes:

PacketHandler

PacketUpdateContainer

CapCompContainer

CapCompScreen

[Danebi 26]

When do you call the register method?

Edited October 27, 2020 by Danebi

[urbanxx001 8]

It's called in:

private static void commonSetup(FMLCommonSetupEvent event) {
    DeferredWorkQueue.runLater(() -> {
        CapCompScreen.register();
        PacketHandler.register();
    });
}

which in turn is called in the Common Proxy class as:

final IEventBus modEventBus = FMLJavaModLoadingContext.get().getModEventBus();
modEventBus.addListener(CommonProxy::commonSetup);

Edited October 27, 2020 by urbanxx001

[poopoodice 114]

I believe this is sending the packet to everyone

PacketDistributor.ALL.noArg()

You can simply use SimpleChannel#sendToServer()

Edited October 27, 2020 by poopoodice

[urbanxx001 8]

Ah that makes sense. I replaced it with that, but receive the same error. Hopefully it's not an issue on the receiving end (container).

Edited October 27, 2020 by urbanxx001

[poopoodice 114]

What's the reason of you sending another packet in PacketUpdateContainer.handle ?

Also in encode you've written a int array into the buffer, but then you read two ints out of the buffer which won't work because the first int will be the length of the array.

[urbanxx001 8]

Right it's being sent in two places, idk why I sent a second one in PacketUpdateContainer.  I'll fix the argument mismatch as well. Thanks for catching those.

Edited October 27, 2020 by urbanxx001

[urbanxx001 8]

Alright I've redone a bit and it's working as long as the block position is given manually in the packet handler. I've been trying to pass it from the tile entity => container => screen instead, however something strange occurs in the container. It receives the correct te and block position, but then a second te with null position is detected. Classes below.

 

ModBlock

ModTileEntity

ModContainer

Edited October 30, 2020 by urbanxx001

[vemerion 56]

35 minutes ago, urbanxx001 said:

It receives the correct te and block position, but then a second te with null position is detected. Classes below.

From what I can see, you are not using the BlockPos you are sending NetworkHooks.openGui(), and thus the 'dummy' ModTileEntity the container creates on the client will have a null BlockPos.

 

As a side note, I would encourage you to stay away from LockableLootTileEntity and IInventory, and instead use the recommended forge alternative IItemHandler.

[urbanxx001 8]

2 hours ago, vemerion said:

I would encourage you to stay away from LockableLootTileEntity and IInventory, and instead use the recommended forge alternative IItemHandler.

I'll definitely consider IItemHandler down the line, thanks.

With openGui() I was passing the block pos:

NetworkHooks.openGui((ServerPlayerEntity) player, ((INamedContainerProvider) tileentity), t -> t.writeBlockPos(pos));

 

So the problem is this isn't synced with the client. I'll try getUpdatePacket() and onDataPacket() in the te then.

Edited October 31, 2020 by urbanxx001

[urbanxx001 8]

Woo got it to sync by setting the pos in the read/write methods, which are called by getUpdateTag().