[1.14.4] ContainerGUI not syncing with Server

[Tessa]

I've been trying to build a custom container block with a GUI that has an input slot that can consume items.
So far i can open the GUI, see and use my own inventory, put items into the input slot of my GUI and by pressing a button in the GUI, the stack in the input slot is "consumed" one item at a time.
However, when i click the input slot, I get all of the items I put in back, even if the slot appears to be completely empty.
I'm assuming there is something going wrong communicating the changes in stack size to the server and when I click the slot, the game assumes nothing has changed.
Does anyone have any idea of what I could've missed?

Edited February 13, 2020 by Tessa
follow common formatting

[desht]

Hard to know for sure without seeing your code, but I'm guessing you're doing the "consume" operation client-side, and that's not to going to work.

 

When the button is clicked, the server needs to know; in other words, send a custom "this button was clicked" packet to the server, and do the inventory change there.  Changes don't get magically sent to the server if you modify a slot client-side; if you look at vanilla code, you'll see packets are used to handle this (take a look at PlayerController#windowClick() for example - modifying the container slot and sending a packet to the server are done separately).

[Tessa]

I was assuming the item/slot manipulation functions in the base container class would take care of it manually, but then i'll take a look at the vanilla click code.
Thanks a lot!

[Draco18s]

  On 2/13/2020 at 3:46 PM, Tessa said:

I was assuming the item/slot manipulation functions in the base container class would take care of it manually, but then i'll take a look at the vanilla click code.
Thanks a lot!

Expand  

GUI-Slots are, yes. But your button doesn't hook into those mechanisms. You must send a packet.

See this (old, 1.12) code:

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/client/gui/GuiContainerOreCart.java#L77

Edited February 13, 2020 by Draco18s

[Tessa]

Okay, so making and sending custom packets appears to be pretty challenging and I doubt that I have the knowledge to take that beast on. In some tutorials I see people using the ItemStackHandler Capability, in which case they often have inventories in an entity instead of a container. Would that be an alternative or do you guys know a different workaround for me?

[eatthenight]

  On 2/13/2020 at 4:43 PM, Tessa said:

Okay, so making and sending custom packets appears to be pretty challenging and I doubt that I have the knowledge to take that beast on. In some tutorials I see people using the ItemStackHandler Capability, in which case they often have inventories in an entity instead of a container. Would that be an alternative or do you guys know a different workaround for me?

Expand  

capabilities have to be synced too so no you must use packets and its not that difficult to be honest. 

https://mcforge.readthedocs.io/en/latest/networking/simpleimpl/

 

[Tessa]

Just wanted to "close" this topic by saying I managed to get the packets working. Indeed, it wasn't too difficult. I didn't feel like the Forge documentation got me all the way there, but with the help of a few tutorials and other forum posts I got it together. When clicking the GUI button a packet gets sent to the server telling it to reduce the stack size of my input slot.

[DavidM]

  On 3/23/2020 at 8:43 AM, Tessa said:

Just wanted to "close" this topic by saying I managed to get the packets working. Indeed, it wasn't too difficult. I didn't feel like the Forge documentation got me all the way there, but with the help of a few tutorials and other forum posts I got it together. When clicking the GUI button a packet gets sent to the server telling it to reduce the stack size of my input slot.

Expand  

The server should also check if the operation is successful (if you haven't added that already). Clients could just send fake information to the server, which would carry them out if no check is in place.

[Tessa]

After handling the packet I did the "setPacketHandled" thing, and the packet itself is registered through forge's SimpleChannel

	public static void handle(Packet_HandInQuest msg, Supplier<NetworkEvent.Context> ctx) {
		DangerSignTile te = (DangerSignTile)ctx.get().getSender().getServerWorld().getTileEntity(msg.pos);
		te.container.takeQuestItems(msg.questInt);
		te.container.takeKillCount(msg.questInt);
		te.container.giveRewards(msg.questInt);
		te.setQuestCompleted(msg.questInt);
		ctx.get().setPacketHandled(true);
	}

[Draco18s]

What happens if a client sends a packet with forged (fake) information in it?

[DavidM]

If I am a malicious player playing on a server, I can modify my clients to send fake quest complete packets.

Your current packet handling code will allow me to obtain quest rewards over and over, since it does not check for 1) if the quest is already completed 2) if the player has the quest items in his inventory.