This resolves some issues which caused entities to not be resent correctly.
Entities that are interacted with need to be resent to the client, so we resend all the entity
data to the player whilst making sure not to clear dirty entries from the tracker. This makes
sure that values will be correctly updated to other players.
This also adds utilities to aid in further preventing entity desyncs.
This also also fixes the bug causing cancelling PlayerInteractEvent to cause items to continue
to be used despite being cancelled on the server.
For example, items being consumed but never finishing, shields being put up, etc.
The underlying issue of this is that the client modifies their synced data values,
and so we have to (forcibly) resend them in order for the client to reset their using item state.
See: https://github.com/PaperMC/Paper/pull/1896
== AT ==
public net.minecraft.server.level.ChunkMap$TrackedEntity serverEntity
Fixes#11649 - As noted in the issue, when CommandNodes are serialized
they are used as the key in a Map. Their equals()/hashcode() should only
match if they are equal nodes (name & command), but due to the erasure of the command field pre-serialization, nodes with different commands can be mapped onto the same value. This causes the client to interpret both nodes as the same, causing suggestions where they should not.
This is fixed by creating a different no-op command for the
erasure, instead of them holding the same lambda.
Exposes the data component logic used by vanilla ItemStack to API
consumers as a version-specific API.
The types and methods introduced by this patch do not follow the general
API deprecation contracts and will be adapted to each new minecraft
release without backwards compatibility measures.
== AT ==
public net/minecraft/world/item/component/ItemContainerContents MAX_SIZE
public net/minecraft/world/item/component/ItemContainerContents items
== AT ==
public net.minecraft.core.MappedRegistry validateWrite(Lnet/minecraft/resources/ResourceKey;)V
public net.minecraft.resources.RegistryOps lookupProvider
public net.minecraft.resources.RegistryOps$HolderLookupAdapter
Fixes incorrect spigot handling of the invulnerability damage
reduction applied when an already invulnerable entity is damaged with a
larger damage amount than the initial damage.
Vanilla still damages entities even if invulnerable if the damage to be
applied is larger than the previous damage taken. In that case, vanilla
applies the difference between the previous damage taken and the
proposed damage.
Spigot's damage modifier API takes over the computation of damage
reducing effects, however spigot invokes this handling with the initial
damage before computing the difference to the previous damage amount.
This leads to the reduction values to generally be larger than expected,
as they are computed on the not-yet-reduced value.
Spigot applies these reductions after calling the EntityDamageEvent and
*then* subtracts the previous damage point, leading to the final damage
amount being smaller than expected.
This patch cannot simply call the EntityDamageEvent with the reduced
damage, as that would lead to EntityDamageEvent#getDamage() returning
the already reduced damage, which breaks its method contract.
Instead, this patch makes use of the DamageModifier API, implementing
the last-damage-reduction as a DamageModifier.
Spigot uses a no longer valid ClientboundContainerSetSlotPacket with the
slot -1, which would update the carried stack in versions <=1.21.1 but
now leads to an IOOB.
1.21.2 instead introduced the ClientboundSetCursorItemPacket, which this
patch uses instead.
The javadocs for BlockDispenseEvent suggest the ItemStack is a single
item which is being dispensed. Before this fix, sometimes it was the whole
stack before a single item had been taken. This fixes that so the stack size
is always 1.
Players are able to use alt accounts and enderpearls to travel
long distances utilizing the pearls in unloaded chunks and loading
the chunk later when convenient.
This disables that by not saving the thrower when the chunk is unloaded.
This is mainly useful for survival servers that do not allow freeform teleporting.
Note: Currently removed as enderpearls are ticked as long as their owner is online in 1.21.2.
Might be worth to re-add once an option to disable the above vanilla mechanic is added, to
fully prevent enderpearl travel exploits.
== AT ==
public net.minecraft.world.entity.projectile.Projectile ownerUUID
When enabled, ender pearls will not load chunks and will save to the world instead of the player.
== AT ==
public net.minecraft.world.entity.projectile.Projectile cachedOwner
Execute processQueue tasks during sleep: needed for console tab completions, pre join event, etc.
Upstream has set precedent that the bukkit scheduler will still tick during sleep, which avoids some problems
with plugins not accounting for the new sleep feature, but can still lead to others. Because of this we have disabled
sleep by default, which avoids the problem and makes it more obvious to check if this is the cause of issues when
enabled. We also unload chunks during sleep to prevent memory leaks caused by plugin chunk loads.
The mojang client will not remove patterns from a Banner when none
are sent inside of an update packet, given that this is not an expected
flow for them, this is not all too surprising. So, we shall resort to always
sending the patterns over the network for update packets.
Anvils, by default, limit applied enchantment levels to their respective
maximum level. The added API enables plugins to disable this behaviour,
allowing enchantments that are overleveled to be applied via the anvil.
Reduces json size by about 25%
Not sure why advancements even had pretty printing enabled.
My best guess was by accident on mojang's part, especially since stats json files don't have pretty printing.
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.
The CraftPlayerInventory implementation sends a container_set_slot
packet to the client which will error if an invalid slot is passed to
the setSlot method, making a validation necessary over simply silently
ignoring invalid slot values.
If a plugin sets the health of a living entity above 0 after it has already died, the entity will be "revived".
It will behave the exact same as before, except with the internal "dead" flag set, resulting in 2 behavior changes,
A: it's completely invulnerable to all damage
B: it's unable to pickup items
isValid() for these bugged entities will return true, isDead() will return false, despite the dead flag.
This patch checks that the mob isn't dead before saying its alive.
Also, even if the plugin is responsibly checking !isDead() before modifying health, on very rare circumstances
I am currently unable to replicate, these "revived" entities can still appear
In the case where multiple messages from different players are being processed in parallel, there was a potential race condition where the messages would be sent to the client in a different order than the message signature cache was updated. However, the cache relies on the fact that the client and server get the exact same updates in the same order. This race condition would cause the caches to become corrupted, and any future message received by the client would fail to validate.
This also applies to the last seen state of the server, which becomes inconsistent in the same way as the message signature cache and would cause any messages sent to be rejected by the server too.
In VanillaChestLoot, compasses accidentally have a setdamage loot
function on them, but compasses don't take durability, resulting in a warning.
This patch simply removes attempting to add damage to the compass item.
== AT ==
public net.minecraft.world.inventory.AbstractContainerMenu quickcraftSlots
public net.minecraft.world.inventory.AbstractContainerMenu quickcraftStatus
public net.minecraft.world.inventory.AbstractContainerMenu quickcraftType
public net.minecraft.world.inventory.AbstractContainerMenu resetQuickCraft()V
In worlds that are extremely large (greater than 1TB), it can take an insanely long time to walk the entire world for symlinks.
This patch adds a system property to disable the symlink scan, which can be used to speed up world loading.
Most of the visual artifacts that result from having item merge radius above vanilla levels is from items merging vertically,
which realistically, only happens when a player is dropping items, or items are dropping from breaking a block.
Most of the scenarios where item merging makes sense involves the two item entities being on the same Y level. i.e on the ground next to each other.
This is even more apparent since paper fixed items being able to merge through blocks.
This patch allows us to configure items to only merge horizontally, which is what vanilla does.
This allows us to have both the reduced number of item entities a high item-merge radius provides,
without most of the visual artifacts caused by items merging vertically.
The server validates incoming interaction packets by ensuring the player
sending them is inside their interaction range. For this, the server adds
a magic value, by default 1.0, to the original interaction range to
account for latency issues.
This value however may be too low in high latency environments.
The patch exposes a new configuration option to configure said value.
The recent upstream update moved around the event logic for
EntiyDamageEvent and its derivatives.
However, the event was called on every call to #hurt as it was moved out
of actuallyHurt.
This patch moves the invocation directly before the #actuallyHurt calls,
respective invulnerable timings.
Horse inventories now combine 2 inventories (like
result inventories).
== AT ==
public net/minecraft/world/inventory/HorseInventoryMenu SLOT_BODY_ARMOR
Exposes a new suspicious effect entry type that properly represents
storable effects in the context of suspicious effects as they only
define the potion effect type and duration.
This differentiates them from the existing PotionEffect API found in
bukkit and hence clarifies that storable values in the parts of the API
in which it replaces PotionEffect.
Co-authored-by: Yannick Lamprecht <yannicklamprecht@live.de>
== AT ==
public net.minecraft.commands.arguments.blocks.BlockInput tag
public net.minecraft.commands.arguments.DimensionArgument ERROR_INVALID_VALUE
public net.minecraft.server.ReloadableServerResources registryLookup
public net.minecraft.server.ReloadableServerResources
Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
Co-authored-by: Marc Baloup <marc.baloup@laposte.net>
== AT ==
public net.minecraft.world.level.block.ChestBlock isBlockedChestByBlock(Lnet/minecraft/world/level/BlockGetter;Lnet/minecraft/core/BlockPos;)Z
== AT ==
private-f net/minecraft/world/item/ItemStack components
public net/minecraft/world/food/FoodProperties DEFAULT_EAT_SECONDS
public org/bukkit/craftbukkit/block/CraftBlockStates getBlockState(Lorg/bukkit/World;Lnet/minecraft/core/BlockPos;Lnet/minecraft/world/level/block/state/BlockState;Lnet/minecraft/world/level/block/entity/BlockEntity;)Lorg/bukkit/craftbukkit/block/CraftBlockState;
public net/minecraft/world/level/block/entity/BlockEntity saveId(Lnet/minecraft/nbt/CompoundTag;)V
Co-authored-by: GhastCraftHD <julius.gruenberg@leghast.de>
Re-adds missing functionality for HIDE_DESTROYS and
HIDE_PLACED_ON. Also adds new flag in HIDE_STORED_ENCHANTS
which was split from HIDE_ADDITIONAL_TOOLTIP.
== AT ==
public net.minecraft.world.item.AdventureModePredicate predicates
This fixes exploits that let players destroy bedrock by Pistons, explosions
and Mushrooom/Tree generation.
These blocks are designed to not be broken except by creative players/commands.
So protect them from a multitude of methods of destroying them.
A config is provided if you rather let players use these exploits, and let
them destroy the worlds End Portals and get on top of the nether easy.
For saddles, carpets, horse armor, and chests for horse-likes
a BlockDispenseEvent handler that always mutated the item without
changing the type would result in a SO error because when it went
to find the replacement dispense behavior (since the item "changed")
it didn't properly handle if the replacement was the same instance
of dispense behavior.
Additionally equippable mob heads, wither skulls, and carved pumpkins
are subject to the same possible error.
Furthermore since 1.21.2, the DISPENSER_REGISTRY map doesn't have a default
return value anymore and some dispense behaviors like equippable and
regular items will not have a defined behavior in that map and might throw
a NPE in that case.
== AT ==
public net.minecraft.world.level.block.entity.HopperBlockEntity setCooldown(I)V
public net.minecraft.world.level.block.entity.HopperBlockEntity cooldownTime
This causes spawnAfterBreak to spawn xp by default, removing the need to manually add xp wherever this method is used.
For classes that use custom xp amounts, they can drop the resources with disabling
Called whenever a players shield is disabled. This is mainly caused by
attacking players or monsters that carry axes.
The event, while similar to the PlayerItemCooldownEvent, offers other
behaviour and can hence not be implemented as a childtype of said event.
Specifically, cancelling the event prevents the game events from being
sent to the player.
Plugins listening to just the PlayerItemCooldownEvent may not want said
sideeffects, meaning the disable event cannot share a handlerlist with
the cooldown event
EntityTeleportEvent#setTo is marked as nullable and so is the
getTo method. This fixes the handling of a null "to" location
by treating it the same as the event being cancelled. This is
already existing behavior for the EntityPortalEvent (which
extends EntityTeleportEvent).
In general, the client now has an acknowledgment system which will prevent block changes made by the client to be reverted correctly.
It should be noted that this system does not yet support block entities, so those still need to resynced when needed.
Instead of just tracking the itemstacks, this tracks with it, the
action to take with that itemstack to apply the correct logic
on dropping the item instead of generalizing it for all dropped
items like CB does.
Fixes EntityPotionEffectEvent
Fixes EntityPoseChangeEvent
Asynchronous chunk generation provides an opportunity for things
to happen async that previously fired synchronous-only events. This
patch is for mitigating those issues by various methods.
Also fixes correctly marking/clearing the entity generation flag.
This patch sets the generation flag anytime an entity is created
via StructureTemplate before loading from NBT to catch uses of
the flag during the loading logic. This patch clears the generation
flag from an entity when added to a ServerLevel for the situation
where generation happened directly to a ServerLevel and the
entity still has the flag set.
For each player on each tick, enter block triggers are invoked, and these create loot contexts that are promptly thrown away since the trigger doesn't pass the predicate
To avoid this, we now lazily create the LootContext if the criterion passes the predicate AND if any of the listener triggers require a loot context instance
Upstream did not account for different hands when storing
the breed item for later use in the event. Also they only
stored a reference to the stack, not a copy so if the stack
changed after love mode was started, the breed item in the event
also changed. Also in several places, the breed item was stored after
it was decreased by one to consume the item.
== AT ==
public net.minecraft.world.level.storage.DimensionDataStorage readSavedData(Ljava/util/function/Function;Lnet/minecraft/util/datafix/DataFixTypes;Ljava/lang/String;)Lnet/minecraft/world/level/saveddata/SavedData;
Objectives displayed in team sidebars were not cleared when switching
scoreboards. If a player's scoreboard has a displayed objective for the
'gold' sidebar, and their scoreboard was switched to one where they
still had a 'gold' team, it would still be displayed
The CHUNKY_FIXERS field is modified during the constructors
of the BlockFixers, but the code that uses CHUNKY_FIXERS does
not properly ensure that BlockFixers has been initialised before
using it, leading to a possible race condition where instances of
BlockFixers are accessed before they have initialised correctly.
We can force the class to initialise fully before accessing the
field by calling any method on the class, and for convenience
we use values().
The tile entities are not accessible and so should not be loaded.
This can happen as a result of users moving regionfiles around,
which would cause a crash on Folia but would appear to function
fine on Paper.
