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
== 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>
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.
This adds a very cheap distance check when an end crystal is placed.
Attempting to respawn the dragon, which involves looking up the end crystal
entities near the portal, every time an end crystal is placed, can be slow on
some servers that have players placing end crystals as a style of combat.
The very cheap distance check prevents running the entity lookup every time.
General patch fixing slot desyncs between the server and client that
result from cancelled events/paper introduced logic.
Co-authored-by: Minecrell <minecrell@minecrell.net>
Co-authored-by: Newwind <support@newwindserver.com>
Fix several issues when a player interact with a block:
* the place sound isn't played for the dispensed shulker block
* desync of the jukebox blocks between bukkit handler and the vanilla interaction
* poi can desync when the BlockPhysicsEvent is cancelled
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
Previously maps would load all chunks in a certain radius depending on
their scale when trying to update their content. This would result in
main thread chunk loads when they weren't really necessary, especially
on low view distances or "slow" async chunk loads after teleports or
other prioritisation.
This changes it to only try to render already loaded chunks based on
the assumption that the chunks around the player will get loaded
eventually anyways and that maps will get checked for update every
five ticks that movement occur in anyways.
Allows plugins to populate profile properties from local sources to avoid calls out to Mojang API
to fill in textures for example.
If Mojang API does need to be hit, event fire so you can get the results.
This is useful for implementing a ProfileCache for Player Skulls
* Only send global sounds to same world if limiting radius
* respect global sound events gamerule
Co-authored-by: Evan McCarthy <evanmccarthy@outlook.com>
Co-authored-by: lexikiq <noellekiq@gmail.com>
Co-authored-by: Aikar <aikar@aikar.co>
First, Enchantment order would blow away seeing 2 items as the same,
however the Client forces enchantment list in a certain order, as well
as does the /enchant command. Anvils can insert it into forced order,
causing 2 same items to be considered different.
This change makes unhandled NBT Tags and Enchantments use a sorted tree map,
so they will always be in a consistent order.
Additionally, the old enchantment API was never updated when ItemMeta
was added, resulting in 2 different ways to modify an items enchantments.
For consistency, the old API methods now forward to use the
ItemMeta API equivalents, and should deprecate the old API's.
Noah van der Aa