Added StaticSupportTrait for blocks which require unconditional support
dynamic support requirements, such as those presented by item frames and torches, are not included.
in addition, double blocks, such as tallgrass, small dripleaf and doors, do not cooperate well with this, so they are also not included.
some blocks which could be migrated (such as chorus plant) were skipped due to unresolved problems.
this switches from a 'can be supported by' concept to a 'can stay at this position' paradigm, which requires way less boilerplate code.
there may be further improvements we can make from here, such as adding traits, but this is a good first step.
For blocks, we now use 'block-item state' and 'block-only state', which should be much clearer for people implementing custom stuff.
'block-item state', as the name suggests, sticks to the item when the block is acquired as an item.
'block-only state' applies only to the block and is discarded when the block is acquired as an item.
'type data' for items was also renamed, since 'type' is too ambiguous to be anything but super confusing.
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.
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 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
this implementation is very rough due to having to hack around lots more MCPE bullshit, and currently doesn't allow dynamic coral types; but it's there. We'll clean this up after 1.13 migration is done.
