Towards 1.13

[xoft]

I've been thinking about the block type registry. What information we want to store for blocks, and what we don't want to store / hardcode.

While peaking at cBlockInfo, I found the following "type properties":
- LightValue (how much light the block emits at night)
- SpreadLightFalloff (how much light is lost when it goes through this block)
- IsTransparent
- IsOneHitDig
- IsPistonBreakable
- IsRainBlocker
- IsSkylightDispersant
- IsSnowable
- IsSolid
- IsUseableBySpectator
- FullyOccupiesVoxel
- CanBeTerraformed (will the terrain generator overwrite such a block)

Some of these would be better represented at the respective simulators - the Snowfall simulator should work with a list of block which support snow on their top, the piston pushing should be handled by the piston simulator (could be a separate one from the redstone simulator itself). Terraforming should be handled by the generator rather than the block type itself. Still, for new blocks, especially those plugin-registered, it would make sense to have a hint for the simulators or generators what to do.

Others may depend on some further properties - the LightValue of a redstone lamp depends on whether it's turned on or off, and that's only in its BlockState, not by a separate BlockType. These would be best represented by callback function - "How much light does this BlockType with this BlockState give out?"

So I guess the best structure to support all this is a free-form map of string->string for "hints" and a list of optional callbacks:

class BlockInfo
{
  AString mTypeName;
  std::map<AString, AString> mHints;
  std::function<UInt8(const AString & aTypeName, const BlockState & aBlockState)> mLightValueCallback;
  std::function<...> mXYZCallback;//  ...
}

The BlockTypeRegistry is then basically a map of the BlockTypeName to BlockInfo structures, with some extra housekeeping.