Pulling Folia API to Paper is primarily intended for plugins
that want to target both Paper and Folia without unnecessary
compatibility layers.
Add both a location based scheduler, an entity based scheduler,
and a global region scheduler.
Owned region API may be useful for plugins which want to perform
operations over large areas outside of the buffer zone provided
by the regionaliser, as it is not guaranteed that anything
outside of the buffer zone is owned. Then, the plugins may use
the schedulers depending on the result of the ownership check.
Makes sure the value returned by Projectile#getShooter in
the API matches the owner UUID specified in the entity nbt.
Previously, after the entity reloaded, Projectile#getShooter
would return null, while the entity still had an owner.
Also fixes setting the shooter/owner to null actually
clearing the owner.
Co-authored-by: Warrior <50800980+Warriorrrr@users.noreply.github.com>
For fishing hooks, the openWater field is true by default, and only calculated when a "fish" is approaching the bobber.
This patch changes the API impl to calculate the open water state itself instead of returning this field.
Relevant link: https://github.com/PaperMC/Paper/issues/9131
== AT ==
public net.minecraft.world.entity.projectile.FishingHook calculateOpenWater(Lnet/minecraft/core/BlockPos;)Z
public net.minecraft.world.entity.projectile.FishingHook outOfWaterTime
This creates a problem with Paper's item serialization
api where deserialized items, which are internally
created as a CraftItemStack, will be completely lost if
#setAmount(0) is invoked (since the underlying handle
is set to null), while a regular Bukkit ItemStack
simply sets the amount field to zero, retaining the
item's data.
Vanilla treats items with zero amounts the same as items
with less than zero amounts, so this code doesn't create
a problem with operations on the vanilla ItemStack.
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
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.
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
Gameoholic