past me was full of shit, because blockReplace is the same as blockClicked when we click a single slab top/bottom to make a double slab, and the logic is identical to the below block with that in mind.
this supports placement, toggling compare/subtract mode, simple stuff. No redstone functionality yet.
This is needed for blockstate mapping in blockfactory.
some of these (notably the on* methods) are internal and shouldn't be exposed via interface (same crap as Plugin->onEnable() onDisable() etc) and the rest of the stuff is entirely unused.
This reverts commit b7b05e729e4fcfbe74786342882d011f004658fa.
Apparently this was premature, because we still need these things to deal with default state remapping.
This story dates back to the days when getVariantBitmask() was introduced. The purpose of this function was to allow the variant info to be extracted from the metadata, for use with item drops. This was later changed to state bitmask for reasons I don't clearly recall.
In the great 4.0 refactor, we now store variant magic numbers separately, so we don't need any generic bitmask to split up variant and state information anymore. Variant is now only ever serialized and never deserialized. The same thing goes for blockIDs. States are read from the world by matching the full stateID against a table of prefilled known blocks, so the variant doesn't need to be deserialized - only the state does, and the state metadata readers already do bit fuckery by themselves and don't need this mask - notice how little actual changes were required to get rid of this?
This test is intended to enforce that the BlockFactory always has the same blocks in it from one commit to the next. Since there are a lot of changes going on right now around this, it's important that this is checked because bugs can go under the radar when large changes are happening.
The consistency check will need to be regenerated whenever a new block is registered, new states are found or when things are removed.
