Client-server desync on seemingly invalid block placement

Sound related to MC-12363

Sound related to MC-12363

I guess it is a similar sort of desync as the end result is identical (wrong client-side inventory), and I can see an additional "update your inventory, client!"-message after the client failed to perform an action "band-aid-fixing" both issues.

But this report is about specific instances where the server thinks you couldn't place a block because you tried to place it inside your character model even though that can clearly not be the case, which is something that shouldn't happen in the first place, even if the band-aid-fix still makes sense. 😉

Relates to MC-99075

Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.

This is an automated comment on any open or reopened issue with out-of-date affected versions.

Is this still an issue in the latest snapshot 16w44a? If so please update the affected versions.

Updated it. Again, (in singleplayer) this happens in any version since the 1.3.1 SSP/SMP merge.

I think the main reason for this bug is, that block-placing is handled on client and server (which also causes block-placement sounds to be played/the block to be rendered for a short time even if the server cancels the block placement.)

This is because the client and the server are out of sync if either one of them lags behind and is a result of a feature rather than a bug.

Can confirm in 21w11a

This report contains two bugs.
1. The inventory desync
When a block is canceled the server doesn't update the player's inventory.

2. The invalid block placement
The server thinks you're placing a block inside yourself therefore it cancels the block. This is because the client doesn't send its position when you move less than 0.03 blocks.

at net.minecraft.client.player.localplayer.sendPosition() you can see that the client won't send its position to the server unless the player moved atleast 0.03 blocks or when 20 ticks have passed.

final double double4 = this.getX() - this.xLast;
final double double5 = this.getY() - this.yLast1;
final double double6 = this.getZ() - this.zLast;

++this.positionReminder;

boolean boolean4 = double4 * double4 + double5 * double5 + double6 * double6 > 9.0E-4 || this.positionReminder >= 20;

I can't think of a good reason for this, you want the server to have the same location as the client. A simple fix would be to send the position when the player moved more than 0 blocks.

final double double4 = this.getX() - this.xLast;
final double double5 = this.getY() - this.yLast1;
final double double6 = this.getZ() - this.zLast;

boolean boolean4 = double4 != 0 || double5 != 0 || double6 != 0;

You might think why 0, what if the client moved 0.0000001 blocks? Do you want to send the position in that case? Well basically you can't, if no keys are pressed and the client's motion is lower than 0.003 it will be set to 0. And then again, even if it is sent each tick it is such a small packet you wouldn't notice any increase in bandwidth.

Can confirm in 21w13a

Can confirm in 21w14a

Can confirm in 21w15a

I'm not very knowledgeable about how this currently works internally, but one solution could be to decrement the Count property of the item being placed on the client while waiting for the server's response.* The server will respond with the new count, and the item in the client's inventory will either reflect this or be deleted if the returned value is <1. Obviously this would make latency more visible to the client (and lead to issues if you want the player to legitimately have an item with an invalid Count), but imo the benefits would be well worth it.

*For an item with Count <1, the item will remain in the player's inventory on the client but the client will no longer consider its functionality, placeability or attribute modifiers and will not render the item in the player's hand.**
**A possible extension would be that when shift-clicking items into the hotbar or offhand, an item with Count <1 will be considered an empty slot and will swap places with the item being shift-clicked. I'm not sure if this would feel good or just add frustration, but it might be something to try.

@unknown That could work but is quite a big change, it would be much simpler to update the player's inventory after their block is being canceled.

Can confirm in 21w16a

Using cobweb you can easily verify if this bug still exists, see attachment

Can confirm in 21w17a

Can confirm in 21w18a

Can confirm in 21w19a

Thanks @unknown for testing the issue in the latest versions. Though in general it is not necessary to confirm a bug for every version; most important is to confirm it for releases or when the changelog indicates that similar bugs have been fixed or that the game logic has been changed in this area.

Can confirm in Pre-release 4

The issue shown in the video using cobweb.mp4 is MC-224949.

Can confirm in 1.17.1.

Affects 1.18.2-pre1.

Affects 1.19