== AT ==
public net.minecraft.server.level.ServerPlayer wardenSpawnTracker
public net.minecraft.world.entity.monster.warden.WardenSpawnTracker ticksSinceLastWarning
public net.minecraft.world.entity.monster.warden.WardenSpawnTracker cooldownTicks
public net.minecraft.world.entity.monster.warden.WardenSpawnTracker increaseWarningLevel()V
Fixes where the user has permission for selectors but not their
suggestions, which especially matters when we force suggestions to
the server for this type
Crashes caused by the missing AWT dependency come up in the support channels fairly often.
This patch detects the missing dependency and stops the server with a clear error message,
containing a link to instructions on how to install a non-headless JRE.
Fixes double firing of the event in PiglinAi
Fixes cancelling the event for piglins still triggering the
advancement trigger
Fires the event when a Raider tries to pick up a raid banner
to become raid leader.
By default, spigot shifts chat over to an unbounded thread pool,
on a normal server, this really offers no gains, the creation of a thread
on submitting to the pool on these servers eats more time vs just running it in
the netty pipeline, however, on servers using plugins which do work in here, there
could be some overall benefits to moving this stuff outside of the pipeline.
In general, this patch does two things:
1) Exposes the core size for the pool, this allows for ensuring that a number of threads
sit around in the pool, mitigating the need for creating new threads; This IS however
caveated, the ThreadPoolExecutor will ONLY create core threads as they're needed, it
just won't allow for us to dip back under the # of core threads, this can potentially
be mitigated by calling prestartCoreThread, however, I'm not sure if there is much justification
for this
2) Exposes a max size for the pool, as stated, by default this is unbounded, for most
servers limiting the size of the pool is going to have 0 effects given how fast chat
is actually processed, this is honestly really just exposed for the misnomers or people
who just wanna ensure that this won't grow over a specific size if chat gets stupidly active
While Velocity supports BungeeCord-style IP forwarding, it is not secure. Users
have a lot of problems setting up firewalls or setting up plugins like IPWhitelist.
Further, the BungeeCord IP forwarding protocol still retains essentially its original
form, when there is brand new support for custom login plugin messages in 1.13.
Velocity's modern IP forwarding uses an HMAC-SHA256 code to ensure authenticity
of messages, is packed into a binary format that is smaller than BungeeCord's
forwarding, and is integrated into the Minecraft login process by using the 1.13
login plugin message packet.
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.
