Bedrock block entity updates don't directly trigger block rendering
updates. This is a problem when the block entity data affects the
block's appearance directly (e.g. cauldron water colour, flower pot
contents), because it means changing them won't directly result in a
client-side render update.
This hack allows tiles to spoof block updates without actually changing
the server-side block, keeping the internals and API clean of random
shitbox workarounds.
fixes#5174fixes#4944
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 required the following:
- A generation task (taskA) to already be running for any chunk (chunkA)
- A chunk (chunkB) is requested for generation, and the task (taskB) to do the generation
is commenced immediately
- chunkB generation promise is aborted (e.g. due to chunk unload) and
taskB is orphaned
- chunkB is subsequently re-requested, but ends up in the generation
queue because taskB is still running
- taskA completes and drains the generation queue
- chunkB attempts to be populated a second time, but taskB has not yet
been collected, resulting in an assertion failure.
This bug has been appearing intermittently ever since PM 4.0 release.
For most users there is no obvious effect since production servers don't
have assertions enabled; however, it's unclear what kind of weird side
effects this bug may have had.
we don't usually add VanillaItems entries for blocks since they already exist in VanillaBlocks, but air has a special use case specifically as an itemstack, so we make an exception for this case.
this fixes a wide range of blocks with invalid blockstates becoming update! blocks on the client.
The most common occurrence of this was air with nonzero metadata left behind by world editors which set blockIDs but not block metadata. This caused large ghost structures of update! blocks to appear from nowhere.
The performance impact of this is very minimal (20 microseconds per chunk load in timings, compared to average 660 microseconds to load tiles).
if the worker selected previously had a generator registered, but has since been shutdown, the workerStartHook that cleans up generatorRegisteredWorkers won't yet have been called.
This results in the worker being started by the submission of PopulationTask, and the generator doesn't get preemptively registered.
