RegistryAccess is independant from CraftServer and
doesn't require one to be created allowing the
org.bukkit.Registry class to be loaded earlier.
== AT ==
public net.minecraft.server.RegistryLayer STATIC_ACCESS
Faster version for isSolid() that utilizes NMS's state for isSolid instead of the slower
process to do this in the Bukkit API
Adds API for buildable, replaceable, burnable too.
When new advancements are added via the UnsafeValues#loadAdvancement
API, it triggers a full datapack reload when this is not necessary. The
advancement is already loaded directly into the advancement registry,
and the point of saving the advancement to the Bukkit datapack seems to
be for persistence. By removing the call to reload datapacks when an
advancement is loaded, the client no longer completely freezes up when
adding a new advancement.
To ensure the client still receives the updated advancement data, we
manually reload the advancement data for all players, which
normally takes place as a part of the datapack reloading.
On servers with plugins that constantly churn through scoreboards, there is a risk of
degraded GC performance due to the number of scoreboards held on by weak references.
Most plugins don't even need the (vanilla) functionality that requires all plugin
scoreboards to be tracked by the server. Instead, only track scoreboards when an
objective is added with a non-dummy criteria.
This is a breaking change, however the change is a much more sensible default. In case
this breaks your workflow you can always force all scoreboards to be tracked with
settings.track-plugin-scoreboards in paper.yml.
== AT ==
public net/minecraft/world/level/block/state/BlockBehaviour getMenuProvider(Lnet/minecraft/world/level/block/state/BlockState;Lnet/minecraft/world/level/Level;Lnet/minecraft/core/BlockPos;)Lnet/minecraft/world/MenuProvider;
Uses correct setPositionRotation for Entity teleporting instead of setLocation
as this is how Vanilla teleports entities.
Cancel any pending motion when teleported.
Tamion