Band-aid fix for the player profile api resolution for a profile with
name but without uuid. The real solution is a proper refactoring of the
completeFromCache and complete method internally, however this needs
further consideration regarding existing faulty behaviour around name
lookups from uuid-only profiles.
* Add PlayerInsertLecternBookEvent
* Rebase
Additionally, moves the event call higher up and removes the lectern
block state clone from the event.
* jSpecify
* Shrink correctly
* style fixups
* move methods
* rename param to cancel
* fix javadocs
* more javadoc fixes
* fix co-author on patch from yesterday
* last fix
---------
Co-authored-by: Mariell Hoversholm <proximyst@proximyst.com>
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
This intends to give plugin developers more control over explosions created using the World#createExplosion method, specifically by adding the option for explosions to damage the explosion cause (not the default behavior, and previously impossible to do, as far as I know). This is done by overloading existing methods with an extra `excludeSourceFromDamage` parameter.
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
The method's implementation uses Block#getDrops
which re-computes the drops from the loot table each
call leading to isValidTool returning different values
with subsequent calls.
* fix: check datatype of particles rather than particle-type
* feature: add ARGB channels
It keeps the functionality of the original color(int).
* fix: order
* fixes
---------
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
Previously, the velocity forwarding secret could only be configured via
the configuration option in the global paper configuration.
This makes configuring/passing such a value rather difficult for
containerized/orchestrated servers as these configuration files are
usually part of the server data volume itself and hence cannot be
sourced from a secret.
This commit enables administrators to define the PAPER_VELOCITY_SECRET
environment variable, which will override any potentially configured
velocity secret.
While BlockType is still marked as internal, it mirrors the already
paper-deprecated method #isInteractable.
The commit marks said method as deprecated if/when BlockType becomes
experimental/non-internal.
The launch API on LivingEntity only respected the WindCharge type, not
its near-clone BreezeWindCharge.
This commit correctly accounts for BreezeWindCharge in
CraftLivingEntity.
The Bukkit#getRegistry(Class) method contract specifies that it returns
null for unknown registry types. The current implementation however
requires the passed class to be mappable to a known registry key.
For types like Material, which have a SimpleRegistry in bukkit's
Registry interface, no server side registry exists and such the type
cannot be mapped to a registry key.
The commit correctly returns null for types that are not mappable to a
registry key instead of throwing a NullPointerException.
Spigot still maintains some partial implementation of "tick skipping", a
practice in which the MinecraftServer.currentTick field is updated not
by an increment of one per actual tick, but instead set to
System.currentTimeMillis() / 50. This behaviour means that the tracked
tick may "skip" a tick value in case a previous tick took more than the
expected 50ms.
To compensate for this in important paths, spigot/craftbukkit
implements "wall-time". Instead of incrementing/decrementing ticks on
block entities/entities by one for each call to their tick() method,
they instead increment/decrement important values, like
an ItemEntity's age or pickupDelay, by the difference of
`currentTick - lastTick`, where `lastTick` is the value of
`currentTick` during the last tick() call.
These "fixes" however do not play nicely with minecraft's simulation
distance as entities/block entities implementing the above behaviour
would "catch up" their values when moving from a non-ticking chunk to a
ticking one as their `lastTick` value remains stuck on the last tick in
a ticking chunk and hence lead to a large "catch up" once ticked again.
Paper completely removes the "tick skipping" behaviour (See patch
"Further-improve-server-tick-loop"), making the above precautions
completely unnecessary, which also rids paper of the previous described
incompatibility with non-ticking chunks.
* Only mark decorations dirty if a removal actually occurs
Vanilla calls this method blindly inside of a loop which erroniously marks
map data files as being dirty even if nothing has actually changed.
* Merge into existing patch
---------
Co-authored-by: Bjarne Koll <git@lynxplay.dev>
In the recent upstream update, the paper player profile was updated to
correctly return null for both name and id if constructed as such. This
change however broke the serialisation logic, as it depended on the name
never being null.
The commit moves the checks over to the newly introduced emptyName/UUID
fields that track if the profile was constructed with a null name or
uuid to differentiate it against an empty string or the NIL_UUID.
