Beyond calling the BlockFadeEvent in more places, this patch also aims
to pass the proper replacement state to the event, specifically for
potentially waterlogged block states fading.
Co-authored-by: Lulu13022002 <41980282+Lulu13022002@users.noreply.github.com>
Minecraft's prediction system does not handle block entities, so if we are manually sending block entities during
block breaking we need to set it after the prediction is finished. This fixes block entities not showing when cancelling the BlockBreakEvent.
Paper makes the entity random thread-safe
and constructing an entity off the main thread
should be supported. Some entities (for whatever
reason) use the level's random in some places.
These can be called while an entity is being added to the world,
and if the entity is being added from a chunk load context the
sync load will block indefinitely (because the chunk load context
is for completing the chunk to FULL).
This does raise questions about the current system for these
dynamic registrations, as it looks like there is _zero_ logic
to account for the case where the chunk is _not_ currently loaded
and then later loaded.
The previous solution caused a bunch of bandaid fixes inorder to resolve edge cases where minecraft/the api might spawn items that are air.
Just simply prevent them from being added to the world instead.
Craftbukkit attempts to translate worlds that use the
same generation as the Overworld, The Nether, or The End
to use those dimensions when checking the `changed_dimension`
criteria trigger, or whether to trigger the `NETHER_TRAVEL`
distance trigger. This adds a config option to ignore that
and use the exact dimension key of the worlds involved.
When calling getBedSpawnLocation on an
instance of CraftOfflinePlayer the world was incorrect
due to the logic for reading the NBT not being up-to-date.
- add auto expire setting
- add setter for block data
- add accessors for block state
== AT ==
public net.minecraft.world.entity.item.FallingBlockEntity blockState
Co-authored-by: Lukas Planz <lukas.planz@web.de>
Fixes https://github.com/PaperMC/Paper/issues/7276 and https://github.com/PaperMC/Paper/issues/8118
by using a config option that, when set to false, does not add markers to the entity
tick list at all and ignores them in Spigot's activation range checks. The entity tick
list is only used in the tick and tickPassenger methods, so we can safely not add the
markers to it. When the config option is set to true, markers are ticked as normal.
By checking if the world passed into StructureTemplate's placeInWorld
is not a WorldGenRegion, we can bypass the deadlock entirely.
See https://bugs.mojang.com/browse/MC-246262
Also standardizes how to handle EntityChangeBlockEvent before a removeBlock or destroyBlock
call. Always use 'state.getFluidState().createLegacyBlock()' to get the new state instead of
just using the 'air' state.
Also fixes the new block data for EntityBreakDoorEvent (a sub-event from
EntityChangeBlockEvent)
Co-authored-by: Lulu13022002 <41980282+Lulu13022002@users.noreply.github.com>
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
lets debug mode throw a trace in order to potentially see where
such calls are cascading from easier, but, generally, if you see one setBlock
call, you're gonna see more, and this just potentially causes a flood of logs
which can cause issues for slower terminals, etc.
We can limit the flood by just allowing one for a single gen region,
we'll also only gen a trace for the first one, I see no real pressing need
to generate more, given that that would *massively* negate this patch otherwise
