This event is currently fired for tree and bamboo growth. Its intended use is for any plant growth that affects multiple blocks at once.
TODO: We could explore using this for cacti and sugarcane?
this makes just about everything easily accessible via commands.
There are some stuff that shouldn't be here due to not being actual items (e.g. door blocks, bed blocks, wall coral fans) but since there were legacy aliases for all those things already, I figured what the heck - it's more effort to exclude them, so whatever.
this isn't specced up with some of the finer features of LegacyStringToItemParser such as metadata parsing, but those are still a work in progress (and probably limited to specific items like durable stuff).
The goal is to unbind these aliases from legacy internal IDs, while also providing a nice flexible way for plugins to add their own items and aliases to the existing system.
This system allows mapping a string to any item at all, irrespective of state, internal IDs, or any of that nonsense. This means it's finally possible to have stuff like lapis_lazuli and bone_meal aliases in commands.
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.
these weren't getting corrected since php-cs-fixer 3.0 due to a change in the default configuration for native_function_invocation. Since the builds are randomly choosing to use php-cs-fixer 2.19 at the moment, the consistency is a problem.
