[1.9.4] Strange issue with capabilities

[P3pp3rF1y]

I have a very strange issue with capabilities losing their state on client side when connected to dedicated server. They basically default to the default value that's set when they are initialized for the given ItemStack. However what's even more strange is the fact that if I put breakpoint in to check for the default value and it stops there when I try to retrieve the capabilities again (ItemStack.capabilities) they have the correct state (not the default one that it just evaluated to in breakpoint)

 

I was trying to debug the issue and stopped when I was in EntityPlayer onUpdate (looking at itemstack.capabilities):

       
if (!ItemStack.areItemStacksEqual(this.itemStackMainHand, itemstack))
        {
            if (!ItemStack.areItemsEqualIgnoreDurability(this.itemStackMainHand, itemstack))
            {
                this.resetCooldown();
            }

            this.itemStackMainHand = itemstack == null ? null : itemstack.copy();
        }

 

It's always the same - breakpoint set to stop on default value which it does and even if I have watches set to show me the capabilities value they would show the default, but the moment I start editing them and just hit enter they would show the correct state.

 

It almost seems as if there was some async call happening which wouldn't be done when the caps are queried by breakpoint, but is done immediately after. But I don't believe there is anything like that in there.

 

Any thoughts on what could be causing this?

 

The primary issue that I have with this is that I use the caps to store charge of staff of flight (Rending Gale) and thus it needs to understand client side if there is a charge and player can still fly. However as it stands it breaks mid air quite a bit.

The same code doesn't seem to have any issues in 1.9 so I suspect some 1.9.4 change.

[P3pp3rF1y]

So I have figured out what's going on here.

 

Basically it relates to packets and a recent forge change. When I start using the flight stuff capabilities get modified and because there was a change to forge which made capabilities part of ItemStack.areItemStackTagsEqual comparison it figures out that stacks are different. https://github.com/MinecraftForge/MinecraftForge/commit/9df1e4b11e0d2d0fbf938cedae2da130d40cca89

 

Which then triggers SPacketSetSlot to be sent to client, which would be ok if this actually included capabilities. However that is not the case and it only syncs stackTagCompound. Which means that deserialized itemstack on client gets capabilities set to default value.

 

I have my own packet that syncs the capability I need, however packets based on what I have seen seem to be treated async, which means that I am not guaranteed that the capability value gets synced before client starts using it. Thus client a lot of the times suddenly sees 0 in the Staff's charge and stops flying.

 

Now the question is what should be the solution here.

Should forge make a change and sync capabilities in SetStackInSlot given that it uses capability value to see if the packet needs to be sent?

Or should it start ignoring capability comparison in this case again to avoid sending slots that delete capability data on client?

 

Or is the solution really for my case to save capability data on player to avoid this issue? That would seem like an awkward one to me, but at the moment seems like the only solution on the mod side apart from reverting to looking at just charge at the start minus ItemUseDuration and approximating how much charge is still remaining.