Equipment changes cannot tell if the same item changed its state
SalekDev opened this issue ยท 4 comments
I have a trinket that needs special syncing methods to be called when equipping and unequipping so I override the onEquip() and onUnequip() methods of the Trinket interface. However when debugging I notice that sometimes when equipping the trinket onEquip() only runs on the client and subsequently when unequipping onUnequip() will run both on the client and server. Sometimes the opposite happens: onEquip() runs both on the client and server but then onUnequip() runs only on the client. This leads to a bit of a pain regarding networking matters. This happens with Trinkets API 3.9.0
Yes, according to Minecraft, an item stack that "changed it's state" is no longer the same stack. With the sort of item you mention that uses durability for charge etc., some sort of id component is virtually a necessity, as internally what is really the difference between the "same" stack that had 50 durability and now has 100, and two stacks one with 50 dura one with 100.
Even adding an ID will lead to the same issue, though, as the durability component is still changing on a stack with the same ID.
I believe the only robust way to fix this issue would be a new defaulted method in Trinket itself something like
default boolean areEqual(ItemStack thisTrinket, ItemStack otherTrinket) {
return ItemStack.areEqual(thisTrinket, otherTrinket);
}
Which would allow a custom implementation of stack equality checking that, for example, only checks an ID component and otherwise ignores components (as a stack with the same ID would be considered as the same stack always)
The issue with creative mode etc. could be avoided by assigning/unassigning the ID on equip/unequip (after the ability to provide custom equality checks). The item not having an ID would be a clear marker that it isn't "equal", and allow them to interact more generically outside of the trinket slot.
Never mind it was kind of a niche issue and I'm kind of dumb, weird shit happened with these two methods because i have a trinket with components that are constantly being updated so the code thought the trinket item itself was being changed completely resulting in weird updates. If you have a trinket that takes damage or has any other kind of component update you should note that you must filter these updates out so that they don't trigger false equipment changes.
The scuffed part now that I'm trying to implement a solution for this is that in Minecraft's code two item stacks are the same if they are of the same item, have the same count and have the same components, so if the trinket changes components while in your slot (for example, like having a collar that stores energy and charges up) then there is virtually no way of telling it is the same item as it was before of the update other than implementing an additional ID component. Then, in the crafting recipe you can randomize a UUID or assign numerical ids or something along those lines. But even with this solution you run into the problem that if you add this item to a creative mode tab then when the user picks up multiple instances of it they will all have the same ID so again you have no way of telling them apart in this case