OpenSource/PaperMC
OpenSource/PaperMC
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-12-29 07:48:53 +01:00
Code Issues Projects Releases Packages Wiki Activity
PaperMC/patches/server/0943-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
955
2024-04-25 01:25:57 +02:00
index cef3a64b5e6c4d34ed079078420078a7adfcd574..3dff328c5e4456aae291a8dec82766681f49af06 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
955
2024-04-25 01:25:57 +02:00
@@ -202,7 +202,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;
955
2024-04-25 01:25:57 +02:00
@@ -217,7 +217,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
955
2024-04-25 01:25:57 +02:00
@@ -235,15 +235,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()) {
iblockdata.attack(this.level, pos, this.player);
f = iblockdata.getDestroyProgress(this.player, this.player.level(), pos);
955
2024-04-25 01:25:57 +02:00
@@ -252,7 +254,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;
}
955
2024-04-25 01:25:57 +02:00
@@ -260,7 +262,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;
}
955
2024-04-25 01:25:57 +02:00
@@ -351,7 +353,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);
}
955
2024-04-25 01:25:57 +02:00
@@ -377,13 +379,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
955
2024-04-25 01:25:57 +02:00
@@ -532,16 +536,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
[ci skip] Cleanup events (#10202)
2024-02-01 10:15:57 +01:00
} else if (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
955
2024-04-25 01:25:57 +02:00
index 6d494b80ae002aea00afa44adf83dad1ae5bbbc1..49557d6f22c5725c663a231deab019d4f6fe95fa 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
955
2024-04-25 01:25:57 +02:00
@@ -78,7 +78,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);
}
955
2024-04-25 01:25:57 +02:00
@@ -185,7 +185,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) 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: 69fa4695 Add some missing deprecation annotations f850da2e Update Maven plugins/versions 8d8400db Use regular compiler seeing as ECJ doesn't support Java 21 JRE c29e1688 Revert "BUILDTOOLS-676: Downgrade Maven compiler version" 07bce714 SPIGOT-7355: More field renames and fixes 6a8ea764 Fix bad merge in penultimate commit 50a7920c Fix imports in previous commit 83640dd1 PR-995: Add required feature to MinecraftExperimental for easy lookups fc1f96cf BUILDTOOLS-676: Downgrade Maven compiler version CraftBukkit Changes: 90f1059ba Fix item placement 661afb43c SPIGOT-7633: Clearer error message for missing particle data 807b465b3 SPIGOT-7634: Armadillo updates infrequently 590cf09a8 Fix unit tests always seeing Mojang server as unavailable 7c7ac5eb2 SPIGOT-7636: Fix clearing ItemMeta 4a72905cf SPIGOT-7635: Fix Player#transfer and cookie methods ebb50e136 Fix incorrect Vault implementation b33fed8b7 Update Maven plugins/versions 6f00f0608 SPIGOT-7632: Control middle clicking chest does not copy contents db821f405 Use regular compiler seeing as ECJ doesn't support Java 21 JRE 8a2976737 Revert "BUILDTOOLS-676: Downgrade Maven compiler version" 0297f87bb SPIGOT-7355: More field renames and fixes 2d03bdf6a SPIGOT-7629: Fix loading banner patterns e77951fac Fix equality of deserialized display names c66f3e4fd SPIGOT-7631: Fix deserialisation of BlockStateMeta 9c2c7be8d SPIGOT-7630: Fix crash saving unticked leashed entities 8c1e7c841 PR-1384: Disable certain PlayerProfile tests, if Mojang's services or internet are not available ced93d572 SPIGOT-7626: sendSignChange() has no effect c77362cae SPIGOT-7625: ItemStack with lore cannot be serialized in 1.20.5 ff2004387 SPIGOT-7620: Fix server crash when hoppers transfer items to double chests 8b4abeb03 BUILDTOOLS-676: Downgrade Maven compiler version
2024-04-25 23:21:18 +02:00
index fb85a7da9da8063c2b781377f62e7db34c467859..2d2b436cae5693051df14e5777d385d38d5f4dd6 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
work on adventure
2024-04-25 05:14:51 +02:00
@@ -480,10 +480,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