Fixes#4589
The following API methods are added:
- `XpManager->canAttractXpOrbs()`
- `XpManager->setCanAttractXpOrbs()`
Possible future scope: flip this on its head to allow spectator players to attract XP orbs, in case someone wants that for some reason ???
Co-authored-by: Dylan K. Taylor <dktapps@pmmp.io>
- The following classes have been added:
- `ItemMergeEvent`
- `ItemEntityStackSizeChangeAnimation`
- The following API methods have been added:
- `ItemEntity->isMergeable()`
- `ItemEntity->tryMergeInto()`
- `ItemEntity->setStackSize()`
Given the various limitations and flexibilities posed by EntityItemPickupEvent, I settled on this as the simplest way to deal with the problem.
- EntityItemPickupEvent may have its destination inventory changed, so we can't cache the result of getAddableItemQuantity() to use after the event.
- The item itself may have changed, so even if we thought we could add some items before the change, we might not be able to afterwards.
Considering the above facts, it's better to just give the whole itemstack to EntityItemPickupEvent, and let plugins use getAddableItemQuantity() on their own to decide if their chosen inventory can accommodate the item or not.
If it can't, then we'll just drop it on the ground.
This also fixes a potential issue where plugins changing the item to a custom one might end up with their items and the actual items both just vanishing if the target inventory was full.
closes#4499
The rationale here is that inventories don't actually pick items up - their holders do.
It's especially misleading to say that an inventory is picking up an item in creative mode when the picked-up item can't actually be added to the target inventory in the first place.
This change allows a range of new functionality, such as:
- Allowing survival players to pick items up even when their inventories are full, similarly to creative players
- Changing the destination inventory of collected items (e.g. items could be redirected to the offhand or ender chest inventory, while still allowing other plugins to understand what's happening)
As an added bonus, this obsoletes one more use case for Inventory->getHolder(), bringing us one step closer to removing the cyclic reference nightmare from inventories.
The choice of naming (EntityItemPickup, instead of EntityPickupItem) is to be consistent with other events, where the word order is SubjectObjectActionEvent.
closes#3461
literally every other particle/sound has the subject first, followed by the (optional) verb, and finally Particle (or Sound).
In addition, we refer to breaking blocks as 'break' everywhere except here, where we refer to it as 'destroy'.
the expectation is that eventually this will receive arbitrary internal runtime IDs instead of static id/meta, and RuntimeBlockMapping doesn't really care about this crap anyway.
in pretty much every case, these usages really wanted to read the tag's contents anyway, which can be combined with a getTag() and instanceof call for more concise and static analysis friendly code.
In the few cases where the tag contents wasn't needed, it still wanted to check the type, which, again, can be done in a more static analysis friendly way by just using getTag() and instanceof.
this reduces the temptation to use it in high-level code, as well as making syncNetworkData() more useful (now it can export to many data collections, which means we can start to think about having a property cache per network session, which is more flexible)
