OpenSource/PaperMC
OpenSource/PaperMC
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-12-02 13:07:06 +01:00
Code Issues Projects Releases Packages Wiki Activity
PaperMC/patches/server/0913-Dont-resend-blocks-on-interactions.patch

172 lines
13 KiB
Diff
Raw Normal View History

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
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Owen1212055 <23108066+Owen1212055@users.noreply.github.com>
Date: Tue, 27 Jun 2023 21:09:11 -0400
Subject: [PATCH] Dont resend blocks on interactions
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.
diff --git a/src/main/java/net/minecraft/server/level/ServerPlayerGameMode.java b/src/main/java/net/minecraft/server/level/ServerPlayerGameMode.java
956
2024-06-14 10:56:28 +02:00
index d839f8df658c894f144ba4637d290ffbed77e132..415d9802ae4dd75b44055b8faf19672fa50c585f 100644
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
--- a/src/main/java/net/minecraft/server/level/ServerPlayerGameMode.java
+++ b/src/main/java/net/minecraft/server/level/ServerPlayerGameMode.java
956
2024-06-14 10:56:28 +02:00
@@ -204,7 +204,7 @@ public class ServerPlayerGameMode {
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
PlayerInteractEvent event = CraftEventFactory.callPlayerInteractEvent(this.player, Action.LEFT_CLICK_BLOCK, pos, direction, this.player.getInventory().getSelected(), InteractionHand.MAIN_HAND);
if (event.isCancelled()) {
// Let the client know the block still exists
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos)); // Paper - Don't resync blocks
// Update any tile entity data for this block
[ci skip] Add more identifying patch comments
2024-01-18 15:56:25 +01:00
capturedBlockEntity = true; // Paper - Send block entities after destroy prediction
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;
956
2024-06-14 10:56:28 +02:00
@@ -219,7 +219,7 @@ public class ServerPlayerGameMode {
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
// Spigot start - handle debug stick left click for non-creative
if (this.player.getMainHandItem().is(net.minecraft.world.item.Items.DEBUG_STICK)
&& ((net.minecraft.world.item.DebugStickItem) net.minecraft.world.item.Items.DEBUG_STICK).handleInteraction(this.player, this.level.getBlockState(pos), this.level, pos, false, this.player.getMainHandItem())) {
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos)); // Paper - Don't resync block
return;
}
// Spigot end
956
2024-06-14 10:56:28 +02:00
@@ -237,15 +237,17 @@ public class ServerPlayerGameMode {
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
// CraftBukkit start - Swings at air do *NOT* exist.
if (event.useInteractedBlock() == Event.Result.DENY) {
// If we denied a door from opening, we need to send a correcting update to the client, as it already opened the door.
- BlockState data = this.level.getBlockState(pos);
- if (data.getBlock() instanceof DoorBlock) {
- // For some reason *BOTH* the bottom/top part have to be marked updated.
- boolean bottom = data.getValue(DoorBlock.HALF) == DoubleBlockHalf.LOWER;
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, bottom ? pos.above() : pos.below()));
- } else if (data.getBlock() instanceof TrapDoorBlock) {
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
- }
+ // Paper start - Don't resync blocks
+ //BlockState data = this.level.getBlockState(pos);
+ //if (data.getBlock() instanceof DoorBlock) {
+ // // For some reason *BOTH* the bottom/top part have to be marked updated.
+ // boolean bottom = data.getValue(DoorBlock.HALF) == DoubleBlockHalf.LOWER;
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, bottom ? pos.above() : pos.below()));
+ //} else if (data.getBlock() instanceof TrapDoorBlock) {
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ //}
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ // Paper end - Don't resync blocks
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
} else if (!iblockdata.isAir()) {
956
2024-06-14 10:56:28 +02:00
EnchantmentHelper.onHitBlock(this.level, this.player.getMainHandItem(), this.player, this.player, EquipmentSlot.MAINHAND, Vec3.atCenterOf(pos), iblockdata, (item) -> {
this.player.onEquippedItemBroken(item, EquipmentSlot.MAINHAND);
@@ -257,7 +259,7 @@ public class ServerPlayerGameMode {
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
if (event.useItemInHand() == Event.Result.DENY) {
// If we 'insta destroyed' then the client needs to be informed.
if (f > 1.0f) {
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos)); // Paper - Don't resync blocks
}
return;
}
956
2024-06-14 10:56:28 +02:00
@@ -265,7 +267,7 @@ public class ServerPlayerGameMode {
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
if (blockEvent.isCancelled()) {
// Let the client know the block still exists
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos)); // Paper - Don't resync block
return;
}
956
2024-06-14 10:56:28 +02:00
@@ -356,7 +358,7 @@ public class ServerPlayerGameMode {
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
// Tell client the block is gone immediately then process events
// Don't tell the client if its a creative sword break because its not broken!
- if (this.level.getBlockEntity(pos) == null && !isSwordNoBreak) {
+ if (false && this.level.getBlockEntity(pos) == null && !isSwordNoBreak) { // Paper - Don't resync block
ClientboundBlockUpdatePacket packet = new ClientboundBlockUpdatePacket(pos, Blocks.AIR.defaultBlockState());
this.player.connection.send(packet);
}
956
2024-06-14 10:56:28 +02:00
@@ -382,13 +384,15 @@ public class ServerPlayerGameMode {
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
if (isSwordNoBreak) {
return false;
}
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ // Paper start - Don't resync blocks
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
// Let the client know the block still exists
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
+ //this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos));
// Brute force all possible updates
- for (Direction dir : Direction.values()) {
- this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos.relative(dir)));
- }
+ //for (Direction dir : Direction.values()) {
+ // this.player.connection.send(new ClientboundBlockUpdatePacket(this.level, pos.relative(dir)));
+ //}
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ // Paper end - Don't resync blocks
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
// Update any tile entity data for this block
[ci skip] Add more identifying patch comments
2024-01-18 15:56:25 +01:00
if (!captureSentBlockEntities) { // Paper - Send block entities after destroy prediction
956
2024-06-14 10:56:28 +02:00
@@ -537,16 +541,18 @@ public class ServerPlayerGameMode {
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
if (event.useInteractedBlock() == Event.Result.DENY) {
// If we denied a door from opening, we need to send a correcting update to the client, as it already opened the door.
if (iblockdata.getBlock() instanceof DoorBlock) {
- boolean bottom = iblockdata.getValue(DoorBlock.HALF) == DoubleBlockHalf.LOWER;
- player.connection.send(new ClientboundBlockUpdatePacket(world, bottom ? blockposition.above() : blockposition.below()));
+ // Paper start - Don't resync blocks
+ // boolean bottom = iblockdata.getValue(DoorBlock.HALF) == DoubleBlockHalf.LOWER;
+ // player.connection.send(new ClientboundBlockUpdatePacket(world, bottom ? blockposition.above() : blockposition.below()));
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ // Paper end - Don't resync blocks
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
} else if (iblockdata.getBlock() instanceof CakeBlock) {
player.getBukkitEntity().sendHealthUpdate(); // SPIGOT-1341 - reset health for cake
} else if (this.interactItemStack.getItem() instanceof DoubleHighBlockItem) {
// send a correcting update to the client, as it already placed the upper half of the bisected item
- player.connection.send(new ClientboundBlockUpdatePacket(world, blockposition.relative(hitResult.getDirection()).above()));
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ //player.connection.send(new ClientboundBlockUpdatePacket(world, blockposition.relative(hitResult.getDirection()).above())); // Paper - Don't resync blocks
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
// send a correcting update to the client for the block above as well, this because of replaceable blocks (such as grass, sea grass etc)
- player.connection.send(new ClientboundBlockUpdatePacket(world, blockposition.above()));
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ //player.connection.send(new ClientboundBlockUpdatePacket(world, blockposition.above())); // Paper - Don't resync blocks
[ci skip] Add more patch identifying comments
2024-01-22 18:04:55 +01:00
// Paper start - extend Player Interact cancellation // TODO: consider merging this into the extracted method
Extend Player Interact cancellation to cover Jigsaw blocks (#10719)
2024-05-26 22:54:55 +02:00
} else if (iblockdata.is(Blocks.JIGSAW) || iblockdata.is(Blocks.STRUCTURE_BLOCK) || iblockdata.getBlock() instanceof net.minecraft.world.level.block.CommandBlock) {
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
player.connection.send(new net.minecraft.network.protocol.game.ClientboundContainerClosePacket(this.player.containerMenu.containerId));
diff --git a/src/main/java/net/minecraft/world/item/BucketItem.java b/src/main/java/net/minecraft/world/item/BucketItem.java
956
2024-06-14 10:56:28 +02:00
index 6caed156ed0cfe0017d578f58cb963ee68272d78..321188173918d0d60858a258400dfd682ccdb21c 100644
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
--- a/src/main/java/net/minecraft/world/item/BucketItem.java
+++ b/src/main/java/net/minecraft/world/item/BucketItem.java
956
2024-06-14 10:56:28 +02:00
@@ -79,7 +79,7 @@ public class BucketItem extends Item implements DispensibleContainerItem {
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
PlayerBucketFillEvent event = CraftEventFactory.callPlayerBucketFillEvent((ServerLevel) world, user, blockposition, blockposition, movingobjectpositionblock.getDirection(), itemstack, dummyFluid.getItem(), hand);
if (event.isCancelled()) {
- ((ServerPlayer) user).connection.send(new ClientboundBlockUpdatePacket(world, blockposition)); // SPIGOT-5163 (see PlayerInteractManager)
+ // ((ServerPlayer) user).connection.send(new ClientboundBlockUpdatePacket(world, blockposition)); // SPIGOT-5163 (see PlayerInteractManager) // Paper - Don't resend blocks
((ServerPlayer) user).getBukkitEntity().updateInventory(); // SPIGOT-4541
return InteractionResultHolder.fail(itemstack);
}
956
2024-06-14 10:56:28 +02:00
@@ -187,7 +187,7 @@ public class BucketItem extends Item implements DispensibleContainerItem {
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
if (flag2 && entityhuman != null) {
PlayerBucketEmptyEvent event = CraftEventFactory.callPlayerBucketEmptyEvent((ServerLevel) world, entityhuman, blockposition, clicked, enumdirection, itemstack, enumhand);
if (event.isCancelled()) {
- ((ServerPlayer) entityhuman).connection.send(new ClientboundBlockUpdatePacket(world, blockposition)); // SPIGOT-4238: needed when looking through entity
+ // ((ServerPlayer) entityhuman).connection.send(new ClientboundBlockUpdatePacket(world, blockposition)); // SPIGOT-4238: needed when looking through entity // Paper - Don't resend blocks
((ServerPlayer) entityhuman).getBukkitEntity().updateInventory(); // SPIGOT-4541
return false;
}
diff --git a/src/main/java/net/minecraft/world/item/ItemStack.java b/src/main/java/net/minecraft/world/item/ItemStack.java
Updated Upstream (Bukkit/CraftBukkit/Spigot) (#11405) 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: 1fc1020a PR-1049: Add MenuType API 8ae2e3be PR-1055: Expand riptiding API cac68bfb SPIGOT-7890: AttributeModifier#getUniqueId() doesn't match the UUID passed to its constructor 7004fcf2 SPIGOT-7886: Fix mistake in AttributeModifier UUID shim 1ac7f950 PR-1054: Add FireworkMeta#hasPower 4cfb565f SPIGOT-7873: Add powered state for skulls CraftBukkit Changes: bbb30e7a8 SPIGOT-7894: NPE when sending tile entity update ba21e9472 SPIGOT-7895: PlayerItemBreakEvent not firing 0fb24bbe0 SPIGOT-7875: Fix PlayerItemConsumeEvent cancellation causing client-side desync 815066449 SPIGOT-7891: Can't remove second ingredient of MerchantRecipe 45c206f2c PR-1458: Add MenuType API 19c8ef9ae SPIGOT-7867: Merchant instanceof AbstractVillager always returns false 4e006d28f PR-1468: Expand riptiding API bd8aded7d Ignore checks in CraftPlayerProfile for ResolvableProfile used in profile components 8679620b5 SPIGOT-7889: Fix tool component deserialisation without speed and/or correct-for-drops 8d5222691 SPIGOT-7882, PR-1467: Fix conversion of name in Profile Component to empty if it is missing 63f91669a SPIGOT-7887: Remove duplicate ProjectileHitEvent for fireballs 7070de8c8 SPIGOT-7878: Server#getLootTable does not return null on invalid loot table 060ee6cae SPIGOT-7876: Can't kick player or disconnect player in PlayerLoginEvent when checking for cookies 7ccb86cc0 PR-1465: Add FireworkMeta#hasPower 804ad6491 SPIGOT-7873: Add powered state for skulls f9610cdcb Improve minecart movement Spigot Changes: a759b629 Rebuild patches Co-authored-by: Jake Potrebic <jake.m.potrebic@gmail.com>
2024-09-15 21:39:53 +02:00
index 355e461da5551e38bbc2ede69c5818f7db27011c..abacf779b3eb2de126137d3c4166a7fc648b291c 100644
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
--- a/src/main/java/net/minecraft/world/item/ItemStack.java
+++ b/src/main/java/net/minecraft/world/item/ItemStack.java
956
2024-06-14 10:56:28 +02:00
@@ -500,10 +500,12 @@ public final class ItemStack implements DataComponentHolder {
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
world.preventPoiUpdated = false;
// Brute force all possible updates
- BlockPos placedPos = ((CraftBlock) placeEvent.getBlock()).getPosition();
- for (Direction dir : Direction.values()) {
- ((ServerPlayer) entityhuman).connection.send(new ClientboundBlockUpdatePacket(world, placedPos.relative(dir)));
- }
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ // Paper start - Don't resync blocks
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
+ // BlockPos placedPos = ((CraftBlock) placeEvent.getBlock()).getPosition();
+ // for (Direction dir : Direction.values()) {
+ // ((ServerPlayer) entityhuman).connection.send(new ClientboundBlockUpdatePacket(world, placedPos.relative(dir)));
+ // }
[ci skip] Add more patch identifying comments
2024-01-13 16:35:59 +01:00
+ // Paper end - Don't resync blocks
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
SignItem.openSign = null; // SPIGOT-6758 - Reset on early return
} else {
// Change the stack to its new contents if it hasn't been tampered with.
Reference in a new issue Copy permalink