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 filters out over 200 invalid states which were previously considered just fine, including zero-width cakes, buttons with broken facing values, furnace/chest with crazy values, and more.
This is a major change to the way block metadata is handled within the PM core. This separates variant metadata (which really ought to be part of the ID) from state metadata, and in a couple of cases flattens separate states of blocks together.
The result of this is that invalid variants can be much more easily detected, and additionally state handling is much cleaner since meta is only needed at the serialize layer instead of throughout the code.
This allows the removal of lots of ugly code, and also exposes lots of similarities with how this update type was handled. This can be further improved in the future to more generically handle cases.
I realized in the process of changing this, that it might actually be simpler to treat to treat scheduled updates and neighbour updates as one and the same. They use the same mechanism for being saved on chunks (TileTicks),
and doing that would make updating only require one queue instead of two.
RedstoneOre: use onActivate() to trigger glowing
this is not technically correct behaviour, but this preserves the current behaviour.
* Fixed an age-old light calculation bug causing solid blocks to filter their own light, fixed#375, probably fixed#288
Light spread reduction should be done based on the _target's_ light filter level, not the source.
* Revert "Fix Glowing Obsidian lighting"
This hack is no longer necessary.
This reverts commit 35c33ba980887e9680d62bbcb65f8537bb063f2c.
* Fixed wrong light levels for torch and redstone torch
* Take adjacent light levels and opacity changes into account, block light will now spread when an obstruction is removed, close#455
* Added timings for Level->setBlock() and lighting updates
