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.
random other server classes
Note: Scoreboards may need handling for the waypoints.
/net/minecraft/world/entity/animal/wolf
Also properly mark the item dropped when shearing as force drops
net/minecraft/world/entity/vehicle/
Nothing much to note, reworked the loot table inventory serialization a bit
net/minecraft/world/level/
net/minecraft/world/entity/player
Note that a method was removed on Armorstand for a bug fix that makes literally zero sense, probably very old.
Also added and fixed the logic for leashes, as any entity can hold leashes but anything can be leashed.
Also very sad hack used to detect if the value was set.
/net/minecraft/world/level/block/entity/trialspawner/
/net/minecraft/server/network
The recent commit 121a7bf4eb added
the interface FeatureElement to the GameRules.Type class to expose the
stored feature flags of gamerules.
This however messed with the reobf mappings spigot uses, as the now
overridden method requiredFeatures needs to be mapped to the same
obfuscated name as FeatureElement#requiredFeatures.
To avoid having this in the mappings patch, the commit removes the
inheritance again and instead exposes a wrapper method.
This reverts commit ab984a0711.
The block damage is null *and has been* null in cases where the block
has already been cleared. Consumers are supposed to use the
getDamagerBlockState instead.
Always passes the respective block to a damage source when passing a
block state. While we could technically use the damageSourcePosition
here by, we'd have to translate it back to a block position by
subtracting .5 from all its components.
Such behaviour however relies on the caller logic's mutation of the
damageSourcePosition and will break once this position is not the centre
of the block.
Passing in the block at the specific callsite is a lot more future
proof.
