I am trying to figure out if there's a way to get ItemHandler capability sync to client when the itemstack it's attached to is in a non player inventory.

 

Basically this breaks for me showing tooltips for ItemHandlers as I can send sync packets when these are in players inventory, but can't seem to find a way to know that player is looking at a inventory and sync the data in that case.

Any thoughts on how I could go about that?

 

Look for solution in the first reply from Leviathan143.

The code for one of them is here https://github.com/P3pp3rF1y/Reliquary/blob/1.10.2/src/main/java/xreliquary/items/ItemVoidTear.java

 

But the problem here is that the data isn't stored in nbt which gets synced, but in capNBT which as you know doesn't get synced to client and thus needs to be synced through special packets.

 

In the code above you can see the packets being triggered, but that only is the case when the item is in player's inventory. As soon as it is in a container this code does nothing which means on dedicated server there's no information on client on the actual capability data.

The only way I can think of when it comes to dealing with this is using regular NBT and store the data to be displayed on client in there as well. But that means that I would end up with the exact same data stored in two different places at least in case of this item.

 

Sounds to me like another reason for itemstack caps to be synced with the stack data (or at least part of the cap data marked to be synced to client)

PlayerContainerEvent.Open fires when a player opens a Container. If you just need to sync the cap on opening a container that should suffice.

 

If you need to sync the cap while the container is open, you can attach an IContainerListener. On PlayerContainerEvent.Open attach an IContainerListener with

Container#addListener()

, on PlayerContainerEvent.Close detach it with

Container#removeListener()

. You can then override

IContainerListener#sendSlotContents()

to sync your capability.

IContainerListener#sendSlotContents()

is called every time an ItemStack in the container changes.

If you need to sync the cap while the container is open

 

Say...hoppers?

If you need to sync the cap while the container is open

 

Say...hoppers?

I don't quite get your meaning here. Hoppers have a container.

I don't quite get your meaning here. Hoppers have a container.

 

Hoppers pulling from or pushing to YOUR container would require an update while the player is looking at the GUI.

Hoppers pulling from or pushing to YOUR container would require an update while the player is looking at the GUI.

 

No problem there. Removal or addition of ItemStacks causes

IContainerListener#sendSlotContents()

to be called, allowing you to sync the cap if the itemstack is being inserted. If it's being extracted, you don't care as it's now in an inventory which the player isn't looking at. The next time it's caps are synced is when the player opens the inventory it was extracted to.

If it's being extracted, you don't care as it's now in an inventory which the player isn't looking at

 

Cough, change in stack size, cough.

If it's being extracted, you don't care as it's now in an inventory which the player isn't looking at

 

Cough, change in stack size, cough.

*Cough*

Look at the call hierarchy of

IContainerListener#sendSlotContents()

.

*Cough*

IContainerListener#sendSlotContents()

is called if

ItemStack.areItemStacksEqual()

returns false. Changes in stacksize, damage value, contained Item or NBT will cause

ItemStack.areItemStacksEqual()

to return false.

 

You also missed the bit where I said that you'd need to have an IContainerListener otherwise hoppers break things.  You assumed that I was saying that hoppers make an IContainerListener insufficient.

So this solution sounds fairly good.

One thing I don't like about it is the fact I will need to listen to all the itemstack changes passing through just in case my item shows up, but I guess that will just have to do.

So I finally got to plugin this in and have to say it's not as easy as it may seem.

First of all removeListener for some reason is client side only method, which is just annoying and was fairly easy to solve with reflection (just removing from listeners collection directly).

 

However the listener part is way worse. I am going through all the stacks when inventory opens and then checking for just updates which is all good until a player clicks on anything that has capabilities.

When that happens CPacketClickWindow is triggered which then triggers EntityPlayerMP.updateCraftingInventory in case that the stack it just got from packet doesn't match the one on server and because capabilities are not synced it won't match ever. Which is bad because updateCraftingInventory sends back to client all of the inventory contents yet again.

So basically what I can do is on every sendSlotContents call in my listener go through all of the inventory because I have no way of knowing if the player just clicked on stack that will cause sync of just one slot or full inventory.

 

Right now I am going with a more limited variant which checks if a stack with itemhandler capability was clicked and only in that case it scans inventory and sends updates. this still means that if an item with different capability was clicked my items would lose their context, but I am going to accept that as an ok solution.