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.
Upstream has released updates that appear to apply and compile correctly. This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
38866413 SPIGOT-6765: Pass WorldInfo, Random and coordinates to ChunkGenerator should methods
CraftBukkit Changes:
f3dab3a48 SPIGOT-7191: TNT minecart explosions crash the server
b5aa0bed9 SPIGOT-7184: ExplosionPrimeEvent not called for ExplosiveMinecart
e7aab5493 SPIGOT-6765: Pass WorldInfo, Random and coordinates to ChunkGenerator should methods
The modified patch prevents entity loading off the main thread when
entities are initially loaded.
However, the initial loading of an entity is not the only time the
Entity#readAdditionalSaveData method is called. Commands like /data also
invoke the method (through Entity#load) to update an entities data
without completely re-creating it.
This however breaks with the current patch, as the patch moves parts of
the entity lookup for persistent anger deserialisation into the first
tick of an entity (which obviously is only called once and hence not
re-run when an already ticking entity is modified as laid out above).
This change actively runs the now split logic for deserialisation again
if the entity has already ticked its first tick. This way, initial
deserialisation is still split into one off thread and the first tick
parts, but following main thread deserialisations can happen completely
inside Entity#readAdditionalSaveData is called.
Due to the weakly consistent of ConcurrentLinkedQueue iterator, at some points, packet will be resent twice times or more, causing some weird behaviors (e.g. kicked for illegal movement since the same ClientboundPlayerPositionPacket was sent two times). This changes for the patch add a flag for marking if the packet was consumed to prevent such issue and ensure consistently of the packet queue.
