Fix "lore" metadata duplication#239
Conversation
|
Hey, please change the branch to develop. |
There was a problem hiding this comment.
Pull request overview
Fixes lore/metadata duplication caused by mutating ItemStack instances when adding items to menus (impacting zShop, per linked issue), by separating the “source” stack from the “displayed” stack.
Changes:
- Clone the provided
ItemStackinto a newdisplayStack. - Apply anti-dupe protection to
displayStackinstead of mutating the originalitemStack. - Use
displayStackwhen placing items into the Bukkit inventory/player inventory.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -130,11 +132,11 @@ public ItemButton addItem(boolean inPlayerInventory, int slot, ItemStack itemSta | |||
| if (inPlayerInventory) { | |||
|
|
|||
| this.playerInventoryItems.put(slot, button); | |||
| if (!needCancel) this.player.getInventory().setItem(slot, itemStack); | |||
| if (!needCancel) this.player.getInventory().setItem(slot, displayStack); | |||
| } else { | |||
|
|
|||
| this.items.put(slot, button); | |||
| if (!needCancel) this.inventory.setItem(slot, itemStack); | |||
| if (!needCancel) this.inventory.setItem(slot, displayStack); | |||
There was a problem hiding this comment.
ItemButton is still constructed with the original itemStack, but the inventory slot is populated with displayStack (potentially dupe-protected). This creates a mismatch where itemButton.getDisplayItem() no longer reflects what is actually displayed/sent. In particular, InventoryListener implementations (e.g. PacketEvents listeners) use itemButton.getDisplayItem() to send items via packets when needCancel is true, which would bypass the anti-dupe protection you just applied to displayStack. Construct the ItemButton using the same stack that will be displayed (e.g., displayStack), or otherwise ensure the protected stack is what listeners and packet sends will use.
There is an issue lore duplication for some items. This affect zShop and causes this issue . Fix is blunt and straightforward. I'm open to comment on better approach.