In general, the client now has an acknowledgment system that will cause block changes made by the client to be reverted correctly.
Essentially:
The client enters a "prediction" stage, where any block changes made will have its old blockstate captured (this is referred to as "server state").
If you update blocks during this stage, the client will update this captured server state as long as they're still currently predicting.
After prediction is done (via an ack packet) all captured blockstates are reverted to their captured server state.
This means that if the server actually updated a block and send a block update packet, it's correctly set, while if a block wasn't updated on the server but WAS updated on the client (server state wasn't updated), that change will be reverted.
It should be noted that this system does not yet support block entities, so those still need to be resynced when needed.
I discovered this when noticing that blocks broken outside of the player's valid interaction distance are still properly reverted, even though the server doesn't send any block updates, only an ack packet.
* Updates documentation in EntityEquopment.java to reflect behavior mentioned in issue #9867
* rebase and squash patches
---------
Co-authored-by: schwaa96 <schwaa96@mi.fu-berlin.de>
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:
96340858 PR-938: Various Sound API improvements
cbfe0ff0 PR-937: Minor improvements to World#rayTrace documentation
e979ee95 PR-935: Change Consumer and Predicates to super
27ae46dc SPIGOT-3641, SPIGOT-7479, PR-931: Add missing values to EntityEffect
0616ec8b Add eclipse .factorypath file to .gitignore
CraftBukkit Changes:
8e162d008 PR-1301: Various Sound API improvements
eeb7dfc2d SPIGOT-7520: Attribute LootTableSeed missing for generated containers with attached LootTable
d433f086d PR-1297: Change Consumer and Predicates to super
864f616da SPIGOT-7518: Fix NullPointerException when calling Block#applyBoneMeal()
5a2d905af Add eclipse .factorypath file to .gitignore
7c6bf15d4 Fix SkullMeta configuration serialization / deserialization with note block sound
Spigot Changes:
7de1049b Rebuild patches
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
* Add attribute modifier from UUID API
* Add method to remove by UUID
* Add overload for UnmodifiableAttributeInstance, better precondition messages
* rebase
The existing EntityPickupItemEvent fixes patch moves the call to LivingEntity#onItemPickup for piglins after the respective EntityPickupItemEvent calls, which is correct.
However the patch moved the call so far down the line that the existing logic already mutated the picked up item entity, leading to faulty state being passed to the onItemPickup method.
To prevent logic in LivingEntity#onItemPickup to read from an ItemEntity that was already mutated, this commit moves the calls prior to the two respective mutations (either gold_nugget or rest).
This was chosen above taking a copy of the original item and restoring state later on to avoid a full item stack clone.
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.
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:
fde5602a PR-927: Add PlayerRecipeBookSettingsChangeEvent
949ff217 PR-930: Add methods to get/set evoker fang attack delay
f6f7c79d SPIGOT-7514, PR-929: Add "Enchantment Roll" API to enchant items according to Minecraft mechanics
d40e22da PR-712: Add API to get full result of crafting items
CraftBukkit Changes:
c8feb0629 PR-1291: Improve precondition message in Entity#playEffect
482c56a00 PR-1285: Add PlayerRecipeBookSettingsChangeEvent
cdf798800 PR-1290: Add methods to get/set evoker fang attack delay
2c1b5f78f SPIGOT-7514, PR-1289: Add "Enchantment Roll" API to enchant items according to Minecraft mechanics
6aa644ae9 PR-992: Add API to get full result of crafting items
ffb1319bc PR-1287: Fix scoreboards not updating in Player#setStatistic
Cost is a property of individual enchantments, and is used by vanilla in combination with environmental aspects like tool enchantability and bookshelf count to determine the final cost of an enchantment as shown in an enchanting table.
Having access to the base cost of an enchantment using these vanilla methods can allow plugin developers to determine the "value" of an enchantment, and use it in custom logic where needed. I came across this recently when trying to assign an economic value to enchantments during tool repairing, and noticed these values don't seem to be obtainable under the current API.
* Add predicate for block data when raytracing blocks
* Match based on block, instead of block data
* Use instanceof instead of casting
* Use Position instead of Location, add overload for rayTraceEntities
* Implement requested changes
* Invert predicate
* Cleanup
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:
19830133 PR-925: Add hit entity/block to events extending ProjectileHitEvent
CraftBukkit Changes:
5a72c3c04 SPIGOT-7510: Try to fix broken reflection usage of plugins
6fa69f235 PR-1281: Add hit entity/block to events extending ProjectileHitEvent
224f733ac Fix NPE introduced in #f4d977e
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:
897a0a23 SPIGOT-5753: Back PotionType by a minecraft registry
255b2aa1 SPIGOT-7080: Add World#locateNearestBiome
ff984826 Remove javadoc.io doc links
CraftBukkit Changes:
71b0135cc SPIGOT-5753: Back PotionType by a minecraft registry
a6bcb8489 SPIGOT-7080: Add World#locateNearestBiome
ad0e57434 SPIGOT-7502: CraftMetaItem - cannot deserialize BlockStateTag
b3efca57a SPIGOT-6400: Use Mockito instead of InvocationHandler
38c599f9d PR-1272: Only allow one entity in CraftItem instead of two
f065271ac SPIGOT-7498: ChunkSnapshot.getBlockEmittedLight() gets 64 blocks upper in Overworld
Spigot Changes:
e0e223fe Remove javadoc.io doc links
When ChunkAccess was converted to an abstract class some versions
ago, the code to initialise nibble arrays should have been moved.
However, the code was not moved and so now mods constructing their
own implementations of ChunkAccess would not have the nibble arrays
initialised.
This is ported to Paper from Starlight to keep the code base in sync,
not because it fixes anything known.
During feature generation, light data is not initialised and
will always return 15 in Starlight. Vanilla can possibly return
0 if partially initialised, which allows some mushroom blocks to
generate.
In general, the brightness value from the light engine should not
be used until the chunk is ready. To emulate Vanilla behavior better,
we return 0 as the brightness during world gen unless the target
chunk is finished lighting.
The regular light retrieval outside of WorldGenRegion remains
the same, as behaviorally chunks not lit should be at max
skylight and zero block light.
There is no point in initialising the sources in Starlight,
as we do not use them. Additionally, they are not saved to
disk so we do not need them.
Maintaining and initialising them is not a negligible cost,
which is why they are being removed.
