Upstream/Paper
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-11-26 20:46:59 +01:00
Code Issues Projects Releases Wiki Activity
28abbaa7bd
Paper/patches/server/1001-Fix-inventory-desync.patch

20 lines
1.2 KiB
Diff
Raw Normal View History

Fix inventory desync (#9640)
2023-08-25 01:53:02 +02:00
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Jake Potrebic <jake.m.potrebic@gmail.com>
Date: Wed, 23 Aug 2023 13:22:09 -0700
Subject: [PATCH] Fix inventory desync
diff --git a/src/main/java/net/minecraft/world/item/BlockItem.java b/src/main/java/net/minecraft/world/item/BlockItem.java
Dont resend blocks on interactions (#9413) 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.
2023-12-03 04:41:35 +01:00
index ce0a22b5084cb382b7c1036960793e3a8314a26f..efdf56044396b4ce486948d2c993971f99174a5e 100644
Fix inventory desync (#9640)
2023-08-25 01:53:02 +02:00
--- a/src/main/java/net/minecraft/world/item/BlockItem.java
+++ b/src/main/java/net/minecraft/world/item/BlockItem.java
@@ -116,7 +116,7 @@ public class BlockItem extends Item {
if (placeEvent != null && (placeEvent.isCancelled() || !placeEvent.canBuild())) {
blockstate.update(true, false);
- if (this instanceof SolidBucketItem) {
+ if (true) { // Paper - if the event is called here, the inventory should be updated
((ServerPlayer) entityhuman).getBukkitEntity().updateInventory(); // SPIGOT-4541
}
Dont resend blocks on interactions (#9413) 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.
2023-12-03 04:41:35 +01:00
return InteractionResult.FAIL;
Reference in New Issue Copy Permalink