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 was first attempted in f64dc01bd1, but reverted, since I hadn't considered how to handle stripping state data from blocks.
This removes the abusable API RuntimeBlockStateRegistry::fromTypeId() and related methods. These were only used to allow ItemBlocks to magically start referencing other blocks if the blocks were overridden by a plugin, but this was never a well-supported use-case anyway.
Instead of relying on RuntimeBlockStateRegistry, we remember the state that the block had during its constructor, and use that to normalize the non-item properties for asItem().
closes#5609
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.
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 commit removes the ability to replace centrally registered entity classes in favour of using constructors directly.
In future commits I may introduce a dedicated factory interface which allows an _actual_ factory pattern (e.g. factory->createArrow(world, pos, shooter, isCritical) with proper static analysability) but for now it's peripheral to my intended objective.
The purpose of this change is to facilitate untangling of NBT from entity constructors so that they can be properly created without using NBT at all, and instead use nice APIs.
Spawn eggs now support arbitrary entity creation functions like EntityFactory does, allowing much more flexibility in what can be passed to an entity's constructor (e.g. a Plugin reference can be injected by use()ing it in a closure or via traditional DI.
