The EntityResurrectEvent logic is supposed to locate a totem of undying
in any of the interaction slots of the player inventory and then, if the
called EntityResurrectEvent is not cancelled, shrink that item by 1,
usually reducing it to zero.
For this, the logic iterates over the items in the interaction slots and
breaks out the loop if a totem of undying was found.
However, even if no totem of undying was found, the iteration item stack
variable remains as a refernce to the last interaction slot probed.
Plugins uncancelling a EntityResurrectEvent, which is published
pre-cancelled to listeners if no totem of undying could be found,
would hence cause the server logic to shrink completely unrelated items
found in, at the writing of this patch, the players off hand slot.
This patch corrects this behaviour by only shrinking the item if a totem
of undying was found and the event was called uncancelled.
Menus don't add slots for the offhand, so on sendAllDataToRemote calls the
offhand slot isn't sent. This is not correct because you *can* put stuff into the offhand
by pressing the offhand swap item
When the server is stopping, the default execution handler method will throw a
RejectedExecutionException in order to prevent further execution, this causes
us to lose the actual kick reason. To mitigate this, we'll use a seperate marked
class in order to gracefully ignore these.
Adds methods notify clients about item breaks and
to simulate damage done to an itemstack and all
the logic associated with damaging them
== AT ==
public net.minecraft.world.entity.LivingEntity entityEventForEquipmentBreak(Lnet/minecraft/world/entity/EquipmentSlot;)B
== 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
