Support for more advanced stuff like NBT copying wasn't added in this PR, as the NBT used by PM is currently an inconsistent mess and doesn't play nice with vanilla. In the interests of avoiding this mess propagating, it's been left for another time.
Adds PlayerEntityPickEvent a la PlayerBlockPickEvent
and Entity->getPickedItem().
This allows, for example, banning the usage of spawn eggs, without preventing opening of doors, without the need for item ID whitelists.
It also allows customizing the behaviour of item and block interactions when sneaking - it's now possible to force spawn eggs to work when sneaking, or force containers to open.
Finally, this also allows preventing any interaction at all without preventing block placement (by setting both to false). Since cancelling the event will typically prevent placement too (which might not be desired).
Side note: Blocks are now always synced when right-clicking on a block.
This differs from the previous behaviour, where the blocks were only synced when the action "failed".
However, since this change introduces a situation where the action may succeed but have different results than the client expects, it's best to just always sync blocks in this situation.
Fixes#3267
Use reflection to locate BlockTypeIds and ItemTypeIds for VanillaBlocks/VanillaItems
Since BlockTypeIds and ItemTypeIds are derived from VanillaBlocks and VanillaItems respectively anyway (they only exist to allow identifying blocks/items without having to create instances of them), this hack is probably OK, and reduces the chances of mistakes.
Previously it was explored to have these IDs generated by auto-incrementing in VanillaBlocks/Items and have the constants generated that way, but this proved to be too problematic because of unstable diffs no matter how we chose to sort the elements. See #6313 for previous research on the subject.
This is obviously not a desirable hack to keep long-term. In the future it will probably make sense to redesign VanillaBlocks like so:
enum VanillaBlocks { ... }
VanillaBlocks::STONE (the type ID)
VanillaBlocks::STONE->new() (to create a block)
However, more research is needed on this, as I'd prefer not to make block creation any more verbose.
this will cause other, more confusing errors to be thrown.
to be honest, I'm not sure if enforcing the return type here is even necessary (or desirable).
there's no way to combine these without causing type compatibility issues for one side or the other.
we might be able to use traits to reduce duplication, but the separation here seems to be necessary.
