Get inventory slots from InventoryMoveItemEvent

There are getDestination() and getSource() methods, but they only return Inventory's.
There are no getDestinationSlot() or getSourceSlot() methods, or any other ones that return a slot.
Is there a workaround to figure out which inventory slots are being modified?

Thanks in advance!

 

InventoryMoveItemEvent fires when an item gets moved regardless of initiation. So not only on player interaction but also hoppers. InventoryMoveEvent is from what i discern not picky about position.

If a player moves an item InventoryClickEvent occurs.

 

For now I want to print a message whenever a certain hopper pushes an item into the chest below. I don't want a message when it can't push anything (because the chest is full or the hopper is powered).

The problem is that InventoryMoveItemEvent is triggered even if the chest is full and no items were actually moved. So I need some way to find out whether anything actually moved. The only way I could think of doing that is to check the source and destination inventory slots of the hopper and the chest during the event and after the event. Then, by seeing what has changed I might be able to determine whether any item had moved.

Unfortunately there are problems with that:

1. According to the documentation of InventoryMoveItemEvent: 'When this event is called, the initiator may already have removed the item from the source inventory'. The fact that the item may or may not have been removed from the hopper makes checking its slots during the event very unreliable.
2. Suppose there are 50 sticks in the hopper. When I use getItem(..) on the hopper's slots during the event, it returns there being 1 stick in the hopper, which is of course completely wrong. There was never 1 stick, there were only 50 or 49. This might be a bug, or maybe you just shouldn't use getItem at all during the event.

Do you have any advice on how to check whether the item actually moved?
Thanks in advance!

 

@Jesbus2 the event code is handled before the event completes, so you can map the source and destination inventories and then schedule a task on the next tick that compares the two. This will work for any situation where a hopper isn't disposing and receiving the same kind of item at the same time.