how ContainerScreen get data from Container

[nooblong 0]

I storge data in an item's nbt, how can i get these data in the ContainerScreen and storge data into item's nbt again.

i have no idea how to communicate between client's screen and container.

My purpose is to save different data for different item and show them on gui

[diesieben07 7697]

Show your code. I don't know why you put "Note! No linkage here!" there. There should be a linkage - if there isn't, it is a bug in your code.

[TheGreyGhost 819]

3 hours ago, diesieben07 said:

Show your code. I don't know why you put "Note! No linkage here!" there. There should be a linkage - if there isn't, it is a bug in your code.

Hi DieSieben

That diagram is for an ItemStack which has an inventory of other ItemStacks (held in an Item_Handler_Capability) 

 

There is no client side link between the Client ItemStack and the inventory contents of the Client Container.  If I recall correctly the Client ItemStack doesn't even get a copy of the server's ItemStackHandler unless you manually synchronise it.  

 

The equivalent diagram for TileEntity might be a bit clearer what the intent is, ie that the client side container is initialised with empty inventory that is not linked to the client-side inventory.  The synchronisation is always from server container to server inventory then to client inventory.  If you try to link the client-side container to the client-side inventory, you get two different synchronisation methods fighting with each other (quite noticeable when there is a bit of lag).

 

-TGG

 

 

[TheGreyGhost 819]

4 hours ago, nooblong said:

I storge data in an item's nbt, how can i get these data in the ContainerScreen and storge data into item's nbt again.

i have no idea how to communicate between client's screen and container.

My purpose is to save different data for different item and show them on gui

Do you just want your ContainerScreen to read the NBT for an item?  That should be automatically transmitted to the client container, assuming you have set the NBT properly.  Your ContainerScreen should be able to just read the tag for the ItemStack.

Or do you mean - you want your screen to be able to modify the nbt for an item?

If so - your Screen will need to send custom packets to the server.  Have a look at the vanilla code for Screens, how they drag ItemStacks from one slot to another.  Basically, the screen sends a packet back to the server saying "drag the ItemStack from slot X to slot Y".

In your case - your Screen will need to send a packet to the server that says "Change the NBT for the ItemStack in slot X for the currently open container", and you will need a packet handler on the server that makes the corresponding modification to the ItemStack in the Server Container.

 

-TGG

 

 

[diesieben07 7697]

2 hours ago, TheGreyGhost said:

There is no client side link between the Client ItemStack and the inventory contents of the Client Container.  If I recall correctly the Client ItemStack doesn't even get a copy of the server's ItemStackHandler unless you manually synchronise it.  

This is the case for all inventories. This synchronization happens by the Container.

[diesieben07 7697]

2 hours ago, TheGreyGhost said:

The synchronisation is always from server container to server inventory then to client inventory. 

What? The container itself does not store items, at all. It only delegates to the inventory - on both server and client.

[TheGreyGhost 819]

 

8 hours ago, diesieben07 said:

This is the case for all inventories. This synchronization happens by the Container.

Are you sure?  Last time I checked (admittedly a few versions ago now), many of the client Inventories appear to be synchronised using NBT packets for their inventory contents even when there is no open container.

  

8 hours ago, diesieben07 said:

What? The container itself does not store items, at all. It only delegates to the inventory - on both server and client.

Based on my testing (from a few versions ago I admit), there are three inventories; one on the server and two on the client.

Using TileEntity as an example:

1a) The Server TileEntity has(is) an inventory.

1b) The Server Container gets a reference to that Inventory.

2) The Client TileEntity has(is) an inventory.  It is synchronised to the Server TileEntity via the usual packets for TileEntities.  It is not used by the Client Container.

3) The Client Container creates an empty Inventory which is then synchronised to the Server Container's referenced inventory using the Container packets.

 

If you're sure that's not right, I will spend some time testing it on vanilla to see what's actually happening.

 

Cheers

  TGG

 

[diesieben07 7697]

7 hours ago, TheGreyGhost said:

Are you sure?  Last time I checked (admittedly a few versions ago now), many of the client Inventories appear to be synchronised using NBT packets for their inventory contents even when there is no open container.

On initial chunk load they are - yes. But that's just because vanilla's TileEntity#getUpdateTag default implementation is franky terrible and sends way too much data.

The contents of a container are synced through SWindowItems (sent when the container is opened) and SSetSlotPacket (when a change is detected). The Slots then write-through directly to the underlying inventory.

 

7 hours ago, TheGreyGhost said:

1a) The Server TileEntity has(is) an inventory.

1b) The Server Container gets a reference to that Inventory.

2) The Client TileEntity has(is) an inventory.  It is synchronised to the Server TileEntity via the usual packets for TileEntities.  It is not used by the Client Container.

3) The Client Container creates an empty Inventory which is then synchronised to the Server Container's referenced inventory using the Container packets.

2 and 3 depends. Vanilla does it this way for many inventory. However this is not at all required. The client can receive additional info in it's "open GUI" packet and use the inventory from the tile entity, entity, or whatever. And that is what I've seen any mod I have looked at do.

[TheGreyGhost 819]

OK, so if I understand you correctly, your point is that the client TileEntity has an Inventory but it's actually useless.  You can sync it if you like, and vanilla sometimes does, but it's not used for anything.

When the player opens a container, the client container gets a temporary inventory which is synched with the server via the container, not via the tileentity.  Vanilla usually creates a new temporary inventory, but if the mod wants to use the useless client inventory in the TileEntity instead of creating a new temporary inventory, it may as well.

 

When I tried it that way in 1.12.2 it led to occasional random visual glitches under stress testing.  The problem was particularly noticeable for TrackedInts being stored in the TileEntity (for example - the furnace burn progress would jump back and forth because it was being updated simultaneously by the GUI (container) packets and the TileEntity update packets), but also occasionally occurred for items in the inventory.  However if you don't dirty the server TileEntity, or the TileEntity update packets do not synch the inventory (for example you are using a Capability), then I imagine it's not a problem.

 

I can't think of any reason a client TileEntity would need to know the contents of the Inventory, unless it is changing its rendering like the campfire does.  In which case using the client tileentity as the container inventory would be a bad idea, i.e. because the tile entity update packets and the container modifications would clash with each other.  The worst symptom would be visual glitches I imagine.

 

-TGG

 

 

 

[diesieben07 7697]

15 minutes ago, TheGreyGhost said:

However if you don't dirty the server TileEntity, or the TileEntity update packets do not synch the inventory (for example you are using a Capability), then I imagine it's not a problem.

Dirtying the entity (markDirty) does not send the update packet. Only a full block update will send it, or you can send it manually.

 

And yes, in my opinion the update packet (and update tag - there are actually two syncing mechanisms for tile entities, one for the initial chunk load and one for later updates) should not contain the full TE NBT, instead they should contain specialized data for what is needed on the client.