How does the Gui reference client side blocks, and how do client side blocks reference server side blocks?

[longbowrocks]

When a player has a chest inventory screen open, I'd like to allow them to press a button to store information about that chest in chunk NBT on the server, but there doesn't seem to be a clean way to do this.

 

1. When a button is pressed, you can get the inventory of the active GUI through minecraft.currentScreen.inventorySlots, but there appears to be a logical rift between that and the classes that actually refer to a block in the world (BlockChest, TileEntityChest). Is my only option to capture right click events, and cache the last block a player right clicked?
2. When I want to send information about a chest to the server, it seems the only identifier I can use is its block position, but that seems to me like it has problems. What if a piston pushes the chest right after I send the message? Wouldn't my data then be associated with whatever new block (possibly another chest) now occupies that space?

[jabelar]

I think a tile entity with an inventory should also have a Container class and that should help do the syncing. There should be a Container instance that is associated with the TileEntity instance, so any movement of the block by pistons or falling and such shouldn't cause trouble.

[Draco18s]

You need to send packets.

You send a packet on the click that tells the server "hey, this button was clicked." The server then makes sure you're looking at a chest, where it is, etc. etc. and then stores the information (which does not go into chunk NBT, because chunk NBT only exists during the save/load process).

[longbowrocks]

8 hours ago, jabelar said:

I think a tile entity with an inventory should also have a Container class and that should help do the syncing. There should be a Container instance that is associated with the TileEntity instance, so any movement of the block by pistons or falling and such shouldn't cause trouble.

While a TileEntity can create a minecraft.inventory.Container, it doesn't appear to store a reference to it. You may be thinking of the GuiContainer, which has a Container reference. That does appear to have a few members (windowId, transactionID) that map the Gui object on the client to an object on the server though, so thanks! I thought everything GUI related was client side only.

 

However, Container objects aren't saved, so I still need to map these GUI objects to blocks on the server side. Any thoughts?

[longbowrocks]

2 hours ago, Draco18s said:

You need to send packets.

You send a packet on the click that tells the server "hey, this button was clicked." The server then makes sure you're looking at a chest, where it is, etc. etc. and then stores the information (which does not go into chunk NBT, because chunk NBT only exists during the save/load process).

Thanks for the tip on Chunk NBT. That's excellent because it's exactly the behaviour I'm hoping for. I was eventually going to start listening for chunk load/unload events so I knew when/where to load or save my cache of chest info.

 

As for packets, I'm already sending plenty of packets, and I will indeed be attaching block<->gui mapping info to them once I find it, but that's not the problem. It appears that there's no logical relationship between GUI related classes (GuiContainer, ContainerChest), and Block related classes (TileEntityChest, BlockChest). That is to say, no GUI related class has a reference to a block related class, and no block related class has a reference to a GUI related class. In simple terms, if I can get a GuiContainer or ContainerChest on a server thread, and can print the associated TileEntityChest or BlockChest to the terminal, then I've gotten what I need.

[longbowrocks]

13 minutes ago, diesieben07 said:

EntityPlayer::openContainer will point to the currently open container.

That's an interesting member, but it doesn't seem to solve the problem. The currently open Container appears to be in-memory-only, and won't be saved, so I need to use that to get a reference to a TileEntityChest or BlockChest, which will be saved.

[longbowrocks]

Just now, diesieben07 said:

Yes, of course.

But that's the problem I originally stated. There are plenty of ways to get the relationship between TileEntityChest and BlockChest, and a few ways to get the relationship between GuiContainer and ContainerChest, but I've yet to draw a connection between one of those groups and the other, aside from perhaps BlockChest.getContainer(), which returns a brand new Container.

[longbowrocks]

2 minutes ago, diesieben07 said:

Well, this is your chest, right? Just store a reference to the TE in the container...

Damn. I was trying to modify the behaviour of vanilla chests. If there's no other solution, I guess the only option is for me to listen for right click events , and store a static reference to the right clicked block. May async events have mercy on my soul.

[longbowrocks]

24 minutes ago, diesieben07 said:

On the server the inventory in the ContainerChest will either be a TileEntityChest (single chest) or an InventoryLargeChest.  Both of these can give you the chest.

That's what I was looking for. Thanks!

 

 

I tried that on the client and found it to be a ContainerLocalMenu, so I assumed that TileEntityChest::creatContainer was dead code. I never thought to check it on the server. Did you just try it on both sides and find that the server side had a different object type in EntityPlayer::openContainer.lowerChestInventory?