I don't plan to make wood-like blocks have a dynamic wood/leaves/sapling type, as it's entirely possible their type properties will continue to diverge in future versions.
TreeType includes a bunch of stuff that don't have regular saplings associated with them, such as mangrove and azalea trees.
Mangrove has a dedicated propagule block with different behaviour than the others, and azalea trees are grown from azalea blocks, which are solid and have different behaviour to saplings.
We may also want to account for crimson and warped 'trees' in TreeType too, although I'm not sure if those belong there or not.
this doesn't support editing the rear side of a sign, since the 1.12 format doesn't allow us to represent the rear text, and it would necessitate API breaks to support anyway.
However, we can quite trivially support APIs for the sign GUI, which plugins can use to enable editing signs. PocketMine-MP doesn't currently permit this, since it's currently an experimental feature in 1.20, but plugins can simply use Player->openSignEditor() to mimic it.
This is, however, a byproduct of the fact that APIs needed to be added in order to facilitate the use of OpenSignPacket in 1.19.80.
This was first attempted in f64dc01bd1, but reverted, since I hadn't considered how to handle stripping state data from blocks.
This removes the abusable API RuntimeBlockStateRegistry::fromTypeId() and related methods. These were only used to allow ItemBlocks to magically start referencing other blocks if the blocks were overridden by a plugin, but this was never a well-supported use-case anyway.
Instead of relying on RuntimeBlockStateRegistry, we remember the state that the block had during its constructor, and use that to normalize the non-item properties for asItem().
closes#5609
This reverts commit f64dc01bd1.
I forgot that the ItemBlock constructor implicitly strips off any states
of the origin block, which is something that we unfortunately can't do
any other way right now, since the blocks don't remember their default
states.
