[SPIGOT-3228] InventoryClickEvent.getClickedInventory() returns wrong inventory. Created: 06/May/17  Updated: 07/May/17  Resolved: 07/May/17

Status: Resolved
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Magyar Dávid Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: InventoryClickEvent, inventory
Environment:

SPIGOT: git-Spigot-a3f6ea5-a2af8f0 (MC: 1.11.2)
(Implementing API version 1.11.2-R0.1-SNAPSHOT)
(Currently 7 version(s) behind)

OS: Windows 8.1

Attachments: PNG File error.png    

 Description   

 

Inventory.getClickedInventory()

returns different value for clicking one inventory in the first and last rows, if the top inventory is a Dropper inventory typed one. I guess the problem is that the top inventory is not a Chest typed and the index checking of which inventory contains the given clicked RawIndex is miscalculated. Depending on the .getClickedInventory(), it returns the top inventory for some slots of the botton inventory's top slots.

 

Occurance details:
The right result, the second/bottom inventory is returned only from the RawSlot with value of 27, the thirt row of shown PlayerInventory, the 2nd line from the bottom of InventoryView, right above the toolbar row. ---- with using a Dropper inventory on the top. Different inventory, like a HopperInventory on the top may return different results.

_*Attacked file:*_
**I made a message showing inside an InventoryClickEvent listener, to show me in chat which Inventory object is returned for .getClickedInventory(), represented by their hashCode() in HEX form (the fastest way I know to identify objects runtime easily). It can be seen, that for the slot from the 2nd row (the upper one) returns an Inventory with #1b6c7f2, but the slot from the third row of the PlayerInventory returns an inventory with #129da8c on click. The right results would be the matching of the two object id's, because the two slots are in the same inventory (not inventory-view, inventory), but they do differ. It is checked via == (reference equal check), that the object returned for the upper slot matches the inventory object for the TopInventory of the View (as if it would be still the top inventory, while it is not already, and it seems like the border between the top and the botton inventory is 2 rows downer, than it should be).

The problem, I guess:
I think the Inventory returned is calculated from the clicked RawIndex, and that calculation must be fixed. May I guessed wrong, this is just a tip.

 Comments   
Comment by Magyar Dávid [ 07/May/17 ]

The problem is not about not returning Dropper, it is about retuning the DropperInventory for the click of the bottom inventory. I tested it with the latest version, and the bug still there.

EDIT: My bad, but the top inventory was Dropper inventory, meanwhile the InventoryView.getType() was overwritten and returned ShulkerBox. Maybe. I'm currently digging into it.

UPDATE: yeah, it was my bad, I returned a ShulkerInventory for the .getTopInventory() and the type of another inventory, a DropperInventory's type for the .getType().

SUGGESTION: You could define the .getType() method in the abstract InventoryView class, if possible, to return the type of the result of .getTopInventory(), since it MUST match, unless misindexing will occur, like in my case. For now, it's up to the programmer to implement the InventoryView correctly, that way it will be more ... safe code.

Thank you, for caring about Spigot and investigated my issue!

Comment by md_5 [ 07/May/17 ]

Cannot reproduce, all slots return Dropper:

   @EventHandler
    public void click(InventoryClickEvent event)
    {
        getServer().broadcastMessage( "Clicked: " + event.getClickedInventory().getType());
    }
Generated at Fri Mar 14 09:44:39 UTC 2025 using Jira 10.3.3#10030003-sha1:d220e3fefc8dfc6d47f522d3b9a20c1455e12b7b.