Hi,

 

I'm building a machine with a GUI that has multiple screens with different slots on each screen. That means the Container method transferStackInSlot needs to behave differently for the different screens.  My approach so far is:

 - GUI calls TileEntity.setField(1, guiId) to set the ID on switching

 - Container calls TileEntity.getField(1) to get the ID in transferStackInSlot

Unfortunately, the GUI call happens only on Client, the Container call happens on both Server and Client but of course only the Client  gets the updated value.

 

I was looking at an IMessage example which should be triggered by TileEntity.setField in case of !world.isRemote which would send the ID to the Server TileEntity; is that the best approach? Any other suggestions on how to achieve this?

 

Lyn

I have an instance of a block with 2 UIs. The way I handle it:

• First UI opens on clicking the block, as usual; there is a button that opens the second UI;
• When this button is pressed, a packet is sent to the server which opens the second UI; it has a button that opens the first UI;
• And so I can switch between these UIs back and forth.

You might try using vanilla packet system for sending GUI ids: net.minecraft.world.World#addBlockEvent and net.minecraft.tileentity.TileEntity#receiveClientEvent. The first method sends the packet, the second method recieves it.

 

I implemented as follows (my TE's also implements IInventory which has getField/setField methods):

The class MessageUpdateTileEntityField implements IMessage, constructor like: MessageUpdateTileEntityField(TileEntity te, int field, int value) which creates a message with TE's pos, dimension, field id and value.

 

On click of the button in the GUI it calls te.setField(1, id) (of course, this is CLIENT), in the TE class, setField triggers a simpleNetworkWrapper.sendToServer call with the new MessageUpdateTileEntityField(this, 1, id).

The internal IMessageHandler class of MessageUpdateTileEntityField, on receiving a message, finds the TE based on pos/dimension (world.getTileEntity(pos)) and calls setField(fieldId, value) (this is on the SERVER).

My Container class has a reference to the TE, it overrides transferStackInSlot and calls te.getField(1) to get the GUI ID and adjust its behaviour.

With this, there's no need to reinitialize the Container and TE to open the new GUI.

 

I based the setup of my TE, Container and GUI classes on the vanilla Furnace.

 

Edit: Oh, and this is working... worth mentioning ?

 

Edited February 6, 20187 yr by lyn mimistrobell

IInventory is a really over-complicated interface. You should use item capability instead.

Can you provide some details how would I use a capability for this? My TE class already returns the inventoryStacks through getCapability.

It really isn't that hard. If you're already supplying a capability, stop implementing IInventory and use SlotItemHandler instead of Slot in your gui.

I've been looking for examples that use IItemHandler capability (nothing in the decompiled source seems to use this) with a Container and GUI. I believe I understand how it can replace IInventory tho I currently fail to see the benefits.

 

More importantly: How do I achieve my multiple-gui solution through IItemHandler?

Vanilla doesn't know WTF capabilities are, they are a Forge thing.

Use Choonster's test mod instead:

https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/1.12.1/src/main/java/choonster/testmod3/inventory/container/ContainerModChest.java

I've refactored my blocks to use IItemHandler(I actually used your ReasonableRealism as an example/guide, Draco18s, thanks for that), this also meant I lost the IIventory's setField and getField.  So, back to my original question:

 

How do I communicate from Gui  (Client) to the Container (Server) which needs this info for transferStackInSlot?

 

OOTB the Container seems to use updateProgressBar (called from IContainerListener.sendWindowProperty, looks like) as a setField but it's marked as @SideOnly(Side.CLIENT).

 

1) I could again call a TileEntity setter method from an IMessageHandler and call a TileEntity getter method from my Container. 

2) I could create a custom method in my Container and use player.openContainer to get the Container instance on the server; I'm not sure that's the best approach tho

3) Perhaps I can create a custom INetHandler Packet with listener, seems a bit overengineered.

 

Any suggestions? I looked at ContainerModChest but it just calls TileEntity methods from the Container... !?

 

For now, I've changed updateProgressBar to be both server and client. Gui calls client side container updateProgressBar and uses  SimpleNetworkWrapper.sendToServer with a custom IMessage; its handler uses player.openContainer updateProgressBar to set the same on the server. Any feedback is appreciated.

 

Edited February 10, 20187 yr by lyn mimistrobell

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/internal/CommonContainer.java#L37

 

I use this class as a "base" class that my other containers then extend, meaning I need this logic written once.

Edited February 10, 20187 yr by Draco18s

I noticed and I already had a similar approach; I have like a BlockMachineBase, ContainerMachineBase, GuiMachineBase (extends GuiInventoryBase which extends GuiContainer) and TileEntityMachine base and each machine extends that, e.g. BlockFurnaceGenerator, ContainerFurnaceGenerator, etc.

But you don't have Client Gui -> Server Container communication, as far as I could tell.

Edited February 10, 20187 yr by lyn mimistrobell

2 hours ago, lyn mimistrobell said:

But you don't have Client Gui -> Server Container communication, as far as I could tell.

Containers are automatically synced by vanilla.

They're synced from server to client using IContainerListener; I've found now client to server syncing...