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

When do you call the register method?

Edited October 27, 20204 yr by Danebi

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, 20204 yr by urbanxx001

I believe this is sending the packet to everyone

PacketDistributor.ALL.noArg()

You can simply use SimpleChannel#sendToServer()

Edited October 27, 20204 yr by poopoodice

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, 20204 yr by urbanxx001

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.

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, 20204 yr by urbanxx001

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, 20204 yr by urbanxx001

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.

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, 20204 yr by urbanxx001

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