SlotUpdate
com.jsmacrosce.jsmacros.client.api.event.impl.inventory.EventSlotUpdate
Fires for a server update to one menu slot or the cursor stack. Unlike EventContainerUpdate, it does not represent a whole-container update. It is dispatched at the update site before the menu receives the new stack.
'HELD' uses slot -999 for the cursor. For 'UNKNOWN', the reported screen is the player inventory even though the packet addressed another menu; see the member descriptions for the implications.
Constructors
new EventSlotUpdate
new EventSlotUpdate(AbstractContainerScreen<?> screen, String type, int slot, ItemStack oldStack, ItemStack newStack)#Stores the supplied event values and wraps both stacks without copying them; stack arguments may be
null. This constructor does not validate or normalize the supplied values.Parameters:
screen: screen associated with the event; may benulltype: source label, stored unchanged and not validated; may benullslot: menu slot index, stored without validationoldStack: previous raw stack; may benullnewStack: replacement raw stack; may benull
Fields
newStack
what is in the
slot now, wrapped in an ItemStackHelper. Read the id from getItemID(), the count from getCount() and the data from getNBT(). For an emptied slot this is an empty stack rather than null, so check it with isEmpty() before reading anything off it.oldStack
what was in the
slot before the update, wrapped in an ItemStackHelper. Read the id from getItemID(). This is the stack object itself rather than a copy of it, and the game replaces the slot's stack right after this event, so read what you need while the event is running rather than holding on to it. It is read out of the menu the update was addressed to: the player's current menu for a 'CONTAINER' or 'UNKNOWN' update, and the player's own inventory for an 'INVENTORY' one. For a 'INVENTORY' or 'CONTAINER' update that is the menu this event reports, so this is the stack that really was in slot a moment ago, and for a 'HELD' update it is the stack the cursor was carrying. For an 'UNKNOWN' update the packet still addressed the player's current menu, but the screen this event reports is a throwaway player inventory, so getInventory() can be a different menu from the one this field and slot describe. Read this field directly in that case rather than going back through the inventory.slot
the index of the slot that changed, in the numbering of the menu the update was addressed to. That is the numbering getSlot() uses, but only as long as the menu behind the screen this event reports is that same menu. For a
'CONTAINER' update it is, since the reported screen is the container the packet addressed. For an 'UNKNOWN' update it is not: the packet addressed the player's current menu while the reported screen is a throwaway player inventory, so a getSlot() call on the getInventory() result reads a different menu than slot indexes. This is -999 for a 'HELD' update, because the item on the cursor does not live in a menu slot. Reading it back through getInventory() will fail in that case.type
Methods
getInventory
a fresh Inventory wrapper around the menu behind the screen this event reports, the same way EventClickSlot.getInventory() is. That menu is the one
slot indexes for a 'CONTAINER' or 'INVENTORY' update, so the two can be used together, with two exceptions. A 'HELD' update has no slot to look up, so slot is -999 and cannot be used with this. An 'UNKNOWN' update reports a throwaway player inventory screen, so this wraps the player's inventory menu while slot still indexes the menu the packet addressed; read oldStack and newStack directly there instead of looking slot up in here.Returns: a wrapper around the menu behind the reported screen
toString
Formats the event name, stored slot, and current screen name as a diagnostic string in the form
%s:{"slot": %d, "screen": "%s"}. A null screen is represented by the quoted name "null"; this does not include the event type or stack values.Returns: diagnostic string containing the event name, slot, and screen name