Mirrors/Paper
3
0
Fork 1
Mirror von https://github.com/PaperMC/Paper.git synchronisiert 2024-11-15 04:20:04 +01:00
Code Issues Projekte Releases Wiki Aktivität
1dc142534d
Paper/patches/unapplied/server/0911-Dont-resend-blocks-on-interactions.patch

172 Zeilen
13 KiB
Diff
Originalformat Normale Ansicht Verlauf

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
Remove wall-time / unused skip tick protection (#11412) Spigot still maintains some partial implementation of "tick skipping", a practice in which the MinecraftServer.currentTick field is updated not by an increment of one per actual tick, but instead set to System.currentTimeMillis() / 50. This behaviour means that the tracked tick may "skip" a tick value in case a previous tick took more than the expected 50ms. To compensate for this in important paths, spigot/craftbukkit implements "wall-time". Instead of incrementing/decrementing ticks on block entities/entities by one for each call to their tick() method, they instead increment/decrement important values, like an ItemEntity's age or pickupDelay, by the difference of `currentTick - lastTick`, where `lastTick` is the value of `currentTick` during the last tick() call. These "fixes" however do not play nicely with minecraft's simulation distance as entities/block entities implementing the above behaviour would "catch up" their values when moving from a non-ticking chunk to a ticking one as their `lastTick` value remains stuck on the last tick in a ticking chunk and hence lead to a large "catch up" once ticked again. Paper completely removes the "tick skipping" behaviour (See patch "Further-improve-server-tick-loop"), making the above precautions completely unnecessary, which also rids paper of the previous described incompatibility with non-ticking chunks.
2024-09-19 16:36:07 +02:00
index 87cae96faf33fa0491b13add79e02fc225bd2f70..e9a9c89bd6a4ce7cb30c2fcf79a537fc18204aeb 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.
In neuem Issue referenzieren Permalink kopieren