* catch destroyBlock calls in the populator, this is needed when sponge
absorb water around plants.
Some of them are destroyed in the process and can only live underwater and plugin
should get the final state in that case and not the not waterlogged state.
* handle drying process for waterlogged blocks on the living world at the end,
while the populator will catch any block changes, it will however not trigger
the particle effects done in destroyBlock
* always try to set block entity data even if the underlying block state doesn't
change for snapshot exposed by the events
- fix a regression for minecart entity type's class
- stable alphanumeric order for fields and data holder fields for CraftBlockData
- properly register bed and conduit block entity metas
If an exception is thrown during decompress then the read process
would be started again, which of course would eventually throw in
the decompress process.
As seen in https://github.com/PaperMC/Paper/issues/12645, the BlockStateListPopulator always destroy
block entity data when the block state change. However this is something that should be supported
so plugin can retrieve block entity data of captured blocks.
Additionally only create snapshots at the end of the capture so we don't need to refresh block entity
data for decorator like the beehive, this is possible since multiple capture
at the same position is not supported and will overwrite the previous data anyway.
alternative to 320f25cb04, this commit has the side effect of
not including the waterlogged block into the block list for the later event. Generally this logic is fragile and should be handled by
the BlockStateListPopulator in the future.
The underlying components seem to still be appended in a different order compared to vanilla but that is fine as the order does not really matter in an ItemStack's component map.
However, 'hidden_components' seem to have defined order that must be respected. We use a hashset and keep the fixing order that is on the vanilla datafixer.
This uses the ClientboundSetPlayerInventoryPacket... in general this logic should be investigated and seen if it can be cleaned up by using this packet.
This is needed for the test plugin, as the bukkit api does not support these versions in the plugin manifest.
Alternatively we could add another gradle property
This allows us to append to the vanilla permission check object to avoid having to look into a map.
This also fixes non vanilla commands from technically being able to be skipped through permissions.
Usual methods of adding force loaded chunks sync load them, so
they should be loaded already. This should avoid the more expensive
getChunkAt and more importantly allow this function to properly work
on Folia due to avoiding thread checks.
We can use the existing full chunk map so that we do not need
to iterate over all ChunkHolders. Additionally, do not use streams
to do the iteration either.
The player inventory now allows setting the saddle and body equipment
slot. The client menu for this however does not contain slots. As such,
updating the player for such slots leads to an IOOB exception.
