Opening a hopper inventory created by Server.createInventory will
currently have no effect as proper handling code is missing in
CraftEntityHuman for hopper inventories that aren't associated with a tile
entity or minecart. Initialization logic for hoppers is also missing from
CraftContainer, which is necessary for the opening of custom hopper
inventories.
This commit fixes the two aforementioned by adding proper handling to
CraftHumanEntity for opening inventories not associated with a tile
entity, and by adding initialization logic for hoppers to CraftContainer.
Adds:
- Getting/Setting equipment
- getting/setting drop rates
- getting/setting ability to pick up items
-- As an added feature, players with this flag start off with a canceled PlayerPickupItemEvent
Details:
- The attributes of custom inventory views are no longer ignored
- Enchanting or crafting inventories no longer ignore the passed inventory and open a new one
- Inventories associated with tile entities no longer raise a class cast exception if there was no associated tile entity
- InventoryOpenEvent and InventoryCloseEvent (if they already had some other inventory open) now fire in all cases
- If for any reason the inventory failed to open, the method now returns null instead of returned the previous inventory they had open (or the default inventory, if none)
See the corresponding Bukkit commit for details.
Implementation details:
- Any packets that include an itemstack will send air stacks as null; maybe this will even eliminate the client crash that occurs if the client receives an air stack
- Better handling of null itemstacks in general (ie less converting them to air stacks)
- Inventory.setContents() can now take an array smaller than the inventory without error
- Player.updateInventory() should now correctly update the result slot in a crafting inventory
Some small credit goes to Afforess (initial implementation of openInventory() methods) and Drakia (initial implementation of InventoryOpenEvent and InventoryCloseEvent).
Also, standardise getHandle and clean up in general.
getHandle is now using the 'entity' member variable instead of
super.getHandle, as this reduces the number of chained calls needed.
