this produced a 40% performance improvement in a simulation with 800 item entities.
If the items were all different, then this would still be a problem. However, many of the same unstackable items occupying the same space is a problem for SkyBlock farms, so this should improve performance for SkyBlock quite a bit.
there's a bunch of places we can't reach with this right now:
- particles
- sounds
- tile NBT
- entity metadata
- crafting data cache
- chunk encoding
- world block update encoding
this is a work in progress, but ultimately we want to get rid of these singletons entirely.
since item merging is a potential hotspot, we want to know if this code section is a performance problem.
Current timers only tell us whether overall ticking of a particular entity is slow, but that includes movement and therefore isn't particularly helpful.
This allows plugins to modify the entity via setters in EntitySpawnEvent without their changes getting overwritten by setter calls directly after the 'new YourEntity' statement.
As well as benefiting plugins, this also clears a path for a BC-breaking change in PM5 (to have the programmer use addEntity() to spawn entities, instead of the constructor doing it, which will improve on a number of data handling aspects).
fixes#4973
This targets next-minor because it has some side effects on plugins that depended on the old behaviour, such as VanillaHopper, so it's not suitable for a patch release.
- 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.
