The Bug:
Signs and hanging signs destroyed within spawn protection don't retain their contents for the client.
Steps to Reproduce:
Start a server, join it, give operator permissions to yourself, and switch into creative mode.
Set the world spawn to your current location by using the command provided below.
/setworldspawn ~ ~ ~Obtain a sign, place it down, and write some text on it.
Remove your operator permissions, and grant anyone else with them in order to activate spawn protection.
Break the sign that you just previously placed and observe its contents.
Take note as to whether or not signs and hanging signs destroyed within spawn protection retain their contents for the client.
Observed Behavior:
Signs and hanging signs appear empty for the client.
Expected Behavior:
Signs and hanging signs would retain their contents for the client.
Code Analysis:
Code analysis by @unknown can be found below.
The following is based on a decompiled version of Minecraft 1.11 using MCP 9.35 rc1.
The method net.minecraft.network.NetHandlerPlayServer.processPlayerDigging(CPacketPlayerDigging) sends a SPacketBlockChange when the player starts, aborts, or finishes breaking a block which they cannot destroy, but it doesn't send a tile entity packet if a tile entity is at that position, resulting in this problem occurring.
Linked issues
is duplicated by 2
relates to 2
Attachments
Comments 12
If the sign text is still Client side, then when the sign is broken your client is basically saying the text is gone and it doesn't reask the server for the informtation. When you relog, the server is then resending the information to your client, which then sends the text making it display again.
I'm assuming text was done this way to prevent lagging if there were a couple hundred signs on a server but that would be something one of the Mojang guys would have to confirm. If so this isn't a bug but working as intended. Unfortunately with the new snap shot coming out this may get lost in with all the new bugs for the new snapshot
Except the server should properly tell the client that the broken sign isn't actually broken, and because the client doesn't ask frequently for the contents (unlike chests, which are checked on opening) of the sign, it doesn't correct itself. The server is at fault for not sending the "complete story" to the client about what happened.
IMO clients should receive data about protected regions and predict what will or won't be allowed.
I agree with you fully that, that is what they should do. I wasn't saying it wasn't a bug. just that it might have been an old bug.
We have adopted a client-side fix in NeoForge for this bug here, by recording the BlockEntity before the break and restoring it in BlockStatePredidtionHandler#endPredictionsUpTo if the server notifies the client that the break was cancelled. An alternative fix to this problem would be to make the client respect ClientboundBlockUpdatePacket(s) immediately instead of storing them until endPredictionsUpTo, and sending the BE data from Server to client when the break is cancelled.
Isn't this an old bug? the Wiki had this in its trivia a long time ago. The text is client side I beleive so when you break the sign even though the sign comes back the client was already told to remove it.