This has several advantages:
Easier to implement new blocks (one less file to modify)
Easier to adjust serialization of existing blocks
Guaranteed consistency between serializers and deserializers
Potentially, exposes more metadata for programmatic analysis, instead of having everything baked inside opaque Closures
There are some exceptions which still use the old approach: big dripleaf, cauldrons, mushroom stems, and pitcher crops. These all have multiple PM block types for a single ID, with relatively complex logic to select which to use. These weren't worth the effort to unify due to their small number. I may revisit this in the future, but I already spent a lot of brainpower on it.
in the future we should be able to unify these, similarly to simple mappings.
unifying blocks with states will, however, be considerably more work.
only color benefits from this so far
PlayerRespawnAnchorUseEvent is also added with options SET_SPAWN and EXPLODE, which allows plugins to customise the outcome of using the anchor in PM, which currently doesn't support dimensions. The event is also cancellable.
I want to do the same for items, but items are going to be a pain in the ass.
For items there are multiple possible entry points and all of them will need to be checked:
- dropped items
- inventory contents
- lecterns
- item frames
I don't see a good way to deal with all these. We can't check for registration in the constructor
because we need to fully construct the item in order to register it.
Blocks are also a potential issue in other areas, but setBlock() is definitely the biggest offender.
Added the following new blocks:
- All types of Copper Bulb
- All types of Copper Door
- All types of Copper Trapdoor
- All types of Chiseled Copper
- All types of Copper Grate
these started to get flattened in 1.19, and rather than dump them in random places in the main function I made a new method, creating placement inconsistencies.
At the time when I wrote this code, I was still in the head space of the kind of ID hijacking that PM4 plugins do to override built-in blocks.
However, this kind of internal ID reuse makes no sense in PM5, since said IDs are only used in the core itself at runtime to identify types and states.
Even if we were to allow overriding block deserializers, overriding serializers makes no sense whatsoever, since the original block would continue to exist and be accessible.
There is a case to be made to allow overriding the deserializer, but not for the serializer.
right now, I don't see an obvious reason to do this. If it turns out I was wrong later on, we can add functionality back, but we can't remove functionality after release.
