SteamWar/Paper
13
0
Fork 0
geforkt von Mirrors/Paper
Code Issues Pull-Requests 1 Projekte Releases Wiki Aktivität
27cabc19a0
Paper/patches/server/1025-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
[ci skip] Add more patch identifying comments
2024-01-21 19:37:09 +01:00
index 6abc5061888d965161de979465bb625c173c59c6..93906a31ddf99cf51541994d7a5c2e4131b697fa 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
@@ -199,7 +199,7 @@ public class ServerPlayerGameMode {
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;
@@ -214,7 +214,7 @@ public class ServerPlayerGameMode {
// 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
@@ -232,15 +232,17 @@ public class ServerPlayerGameMode {
// 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);
@@ -249,7 +251,7 @@ public class ServerPlayerGameMode {
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;
}
@@ -257,7 +259,7 @@ public class ServerPlayerGameMode {
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;
}
@@ -350,7 +352,7 @@ public class ServerPlayerGameMode {
// 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);
}
@@ -376,13 +378,15 @@ public class ServerPlayerGameMode {
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
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
@@ -539,16 +543,18 @@ public class ServerPlayerGameMode {
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
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
// Paper start - extend Player Interact cancellation // TODO: consider merging this into the extracted method
} else if (iblockdata.getBlock() instanceof net.minecraft.world.level.block.StructureBlock) {
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
[ci skip] Add more identifying patch comments, merge related patches
2024-01-19 17:54:05 +01:00
index 4b9e726e6ac255e743479d5c2e0cdb98464399a4..6371f326fc86cfc53e39bf8ed13b646f7705fbbc 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
@@ -77,7 +77,7 @@ public class BucketItem extends Item implements DispensibleContainerItem {
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);
}
@@ -186,7 +186,7 @@ public class BucketItem extends Item implements DispensibleContainerItem {
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
[ci skip] Add more patch identifying comments
2024-01-21 19:37:09 +01:00
index a33f22f03c54abed5fc24022a8b5f4af007e4597..ed27a963223bfe18310ad5adabf461b5e307ef9c 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
Apply all patches
2023-12-06 19:18:53 +01:00
@@ -457,10 +457,12 @@ public final class ItemStack {
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