the terminology of this needs improvement, but...
the basic concept here is that 'type' data will persist on an itemstack, while 'state' data will not.
Type data consists of things like:
- Colour
- Coral type
- Wet/dry (sponges)
- Live/dead (coral)
- Wood type
State data consists of things like:
- Facing
- Axis
- Powered/unpowered
- Open/closed
In the past, with the old system, this information was separated by way of getStateBitmask(). This solution was fraught with problems, but achieved the basic goal: removing unwanted block properties from items.
this doesn't match the 1.16+ behaviour yet, but it at least recognizes walls that are already in the post-1.16 way and doesn't break them if not interacted with.
This commit completely revamps the way that blocks are represented in memory at runtime.
Instead of being represented by legacy Mojang block IDs and metadata, which are dated, limited and unchangeable, we now use custom PM block IDs, which are generated from VanillaBlocks.
This means we have full control of how they are assigned, which opens the doors to finally addressing inconsistencies like glazed terracotta, stripped logs handling, etc.
To represent state, BlockDataReader and BlockDataWriter have been introduced, and are used by blocks with state information to pack said information into a binary form that can be stored on a chunk at runtime.
Conceptually it's pretty similar to legacy metadata, but the actual format shares no resemblance whatsoever to legacy metadata, and is fully controlled by PM.
This means that the 'state data' may change in serialization format at any time, so it should **NOT** be stored on disk or in a config.
In the future, this will be improved using more auto-generated code and attributes, instead of hand-baked decodeState() and encodeState(). For now, this opens the gateway to a significant expansion of features.
It's not ideal, but it's a big step forwards.
fixes#4856fixes#458fixes#4529fixes#3299
Added API method Block::getSupportType(Facing) : SupportType
Added SupportType enum
fixes torch, lantern, door etc. placement on slabs and upside-down stairs
Not allowing this makes stuff like anvil damage, colour, wood type, live/dead bit, wet/dry etc all too much hassle to deal with.
Naturally I want to get rid of this shit altogether, but first it's necessary to construct a new system that we can shift into before all this bullshit can be addressed fully, so for now we have to work within the bounds of the old system.
This change will permit dynamic colours for concrete/concrete powder etc, dynamic wood types where the wood type isn't embedded in the legacy ID, and so forth. Allowing full flexibility requires either more old system hacks or completing the migration to a new system which doesn't have these limitations. I prefer to do the latter, but this change will make it somewhat easier to do.
this fixes TNT spawning multiple entities when lit by flaming arrows.
The problem here is a bit more complex (entities aren't immediately notified when local block updates happen, so they cache stuff that becomes unusable). The simplest option would be to just lose the cache, but that would have some impacts on performance.
Barring a rethink of the block updating mechanism, this solution seems usable for now.
this new form allows skipping some useless checks during sky light calculation and also allows getting rid of the last hard dependency on core Block classes.
We're getting real close to native light now.
Now, blocks do not respond to silk touch unless specifically opted into. Since this always involves custom drops in one way or another, it's easy enough to figure out which blocks need to be marked for silk touch - anything that overrides getDrops, getDropsForCompatibleTool or getSilkTouchDrops is a block which _might_ need to be flagged. Using these criteria to reduce the number of blocks needing to be checked, I was able to manually invert the behaviour as needed.
This fixes reoccurring bugs with blocks erroneously dropping themselves whenever new blocks are added and someone forgot to set that flag, granting players access to internal blocks with strange behaviour.
