High efficiency tools / fast mining destroys some blocks client-side only

Duplicate of MC-858.

Not a duplicate of MC-858.

I can confirm this bug on vanilla 1.8.x servers. This happens often to me when mining blocks with instant-speed in Survival. It's a server-client synchronization issue and has little to nothing to do with lag.

To make the distinction clear: MC-858 describes the internal server having low TPS and therefore registering the block-breaking action from the client very late. This leads to the client re-displaying the block again, until it gets the confirmation from the server that its actually broken, seconds later, or not at all. At the end, the block is either broken or still there, on both client and server.

This bug (MC-5694) is different in that it can occur on a server running 20 TPS constantly. It only occurs when the time to break a block is instant, e.g. with a diamond pickaxe on Nether rack or high-Efficiency diamond shovel on dirt. While the block in question disappears from the client's view (it is not rendered anymore and is removed from clientside collision), the server says it's still there and pushes the players' movement back when the client tries to move within the block's space. This can be a quite tricky and dangerous situation, especially when taking down a pillar below you: You fall into the ghost block again and again (many times a second) and cannot move. Client and server arrive at no consensus over whether the block is still there or not. Reloading the chunks on the client by pressing F3+A does not resolve this. It can be resolved by trying to place a new block in the old location. This of course fails server-side, the new block is not placed, but the old one reappears client-side. It can also be resolved by rejoining the server.
So this is a persistent client-server asynchronicity and must be fixed independently from the (in my opinion) non-bug MC-858.

By the way, MC-7409 is a duplicate of this.

@unknown: Thanks, I split them up and made you the reporter of both tickets since the original reporters are both inactive.

Confirmed for 15w47c

Confirmed for 15w49b

Confirmed for 15w50a

Happens to me in SSP in 15w50a

Confirmed in singleplayer 16w03a.
This happens more often in the 1.9 snapshots than in 1.8

Confirmed for 1.9 pre2
I would very much agree that this is just block lag.
However there are some cases where my computer set up should be plenty good enough to handle simple things like this, and it should not be a problem for the block to update.

confirmed for 1.9 pre 4.
I do not suspect lag, as the block stays gone to the client, cannot be struck, and F3+A does not help, strangely.
Attempting to place a block/torch/etc... in the location will cause the block to appear, as described.
Dying, warping, teleporting away will also recover the block.

For the F3+A I created MC-96142.

Still in 1.9.1-pre3

I can also confirm this bug. I picked up an enchanted spade from the ground after defeating a zombie carrying it. It was an iron spade with Efficiency III. I blasted through a load of dirt blocks and when walking through where they were, I bumped into and became stuck briefly within thin air. I also became stuck at one point within these "invisible blocks" and started loosing health. Hope this gets fixed. Thanks Mojang 🙂

Still in 16w15b

The easiest way to fix this would be to have the server send a block update packet whenever a player ends up clipping inside of a block. There isn't any good way to see which block they clipped into, though, so it might be easier to resend all blocks within their (moved) bounding box.

That would be a workaround, no fix. It would only happen if you walk into it. But if you clear out a big area, go away, come back and find a floating block outside your reach, that can be very annoying.
I think the only possible "easy" fix is to make sure the result of the method for measuring if a block is broken is the same in the part that gets used for the visual client display and for the data that gets sent to the server.
It's after 2am here, I don't even know if that long sentence made any sense. Please ask if it doesn't.

That's a valid point which I thought I addressed in my comment, but I evidently didn't. Yes, resending it is definitely only a workaround, but IMO is better than getting stuck without being able to move.

Regarding the ability to break blocks: I'll check MCP in a second, but I'm pretty sure they're the same. Generally when this bug happens to me it's a nearby block with the block behind it broken successfully... I think.

Code check, yes, there is definitely a difference between the two:

• The logic to determine what block is currently being looked at happens in EntityRenderer.getMouseOver, in a profiler section named "pick". It first gets the player's reach distance using PlayerController.getBlockReachDistance, which returns 5.0 if the player is in creative and 4.5 otherwise. A ray trace is performed using Entity.rayTrace, ray tracing from the eye position to a position calculated with a vector in the direction of the look vector and with a magnitude of the block reach distance. That ray trace is done via World.rayTraceBlocks(Vec3d, Vec3d, boolean, boolean, Boolean), which is convoluted and I'm not going to try to explain. Then, back in EntityRenderer.getMouseOver, there follows some weirdly written logic (probably from recompilation) regarding reach distance if the looked entity is too far away (further changing the distance, limiting it to 3 in a weird way if in survival - probably the due to the way [MC-76493] was fixed), but we don't care about entities and this bug still happens when entities aren't a factor. TLDR, for the client, a ray trace from the eyes in the look direction is performed with a max length of the reach distance.

• The server's logic, found in NetHandlerPlayServer.processPlayerDigging, computes the square distance from the center of the block (each coordinate in the block position has .5 added to it), to the player's position, using the feet position plus 1.5 as the y coordinate. If that distance is greater than 36 (or the block position is above the world height limit), the action is rejected. It does not seem like any resending occurs when it is rejected there. Further processing is then done, and if the digging state is STOP_DESTROY_BLOCK, PlayerInteractionManager.blockRemoving is called. That does some checking that seems to be for if the block was fully mined, and then calls PlayerInteractionManager.tryHarvestBlock. There isn't any other distance-based checking. Note that, at that point, back in NetHandlerPlayServer.processPlayerDigging, if the block is not air after calling blockRemoving, a setblock packet is sent.

So, there is a discrepancy. However, the server logic is more lenient (6 blocks rather than 4.5), so that probably isn't the cause. If that is the cause, though, then it would make sense since the block is not reverted. Yet I've had it happen (or at least I think I've had it happen) where it's a block near me that failed to break, not a distant one.

I've had this happen in single player, how is that even possible? I´m not on any server, what is getting desynchronized?

Singleplayer=locan 1 man server

can you explain what that means? I still dont get why it is happening.

[Ill remove this part after getting a response]:PS, where should I go to ask how to uncorrupt a world? I managed to get it so that all enchants cost 1 lvl by turning off my laptop mid game (I accidentally killed everything in my world when just trying to kill some bats via /kill @e[type=Bat])

It's still not known why this bug itself happens.

However, when you play singleplayer it actually runs a server that only you can connect to. So, some glitches that you'd think would only make sense in multiplayer still do apply in singleplayer. This "integrated server" helps with performance and also means that singleplayer and multiplayer use mostly the same code.

I thought that would create unnecessary redundancy, resulting a lower performance and thus avoided. Please note that programming in basic on my calculator is practically my only programming experience.

Please keep all discussion not specifically and directly related to the bug to Reddit or the forums. Discussions about why Minecraft was split up this way have been had before and explanations can be found via google pretty easily.

@fenxjox google is not yielding any satisfying results. Can you give me a link?
[I´ll remove this comment when it gets an answer]

Any ideas when this bug is going to be fixed?

Can someone reproduce for 16w33a? I tried for a while and either it's fixed or it got much rarer.

I can still reproduce up through 16w39c.

I have tried this and it didn't work after multiple times.

Does this affect 16w44a?

Try it.

Confirmed for 1.11

1.11. The behaviour of this bug is not random, but happens more often in certain circumstances.

I was mining a diagonal tunnel in the Nether using Efficiency 4 diamond picks. My mining technique is not just to dig at random, but to try digging out only the blocks that need to be removed with some precision at the edges but just mine everything in the middle of the tunnel. For the edges and corners, this technique involves standing in such a position that blocks that are not to be removed are out of range of the pick, but when digging the middle of the tunnel I just mine everything. I have noticed that with this digging technique the ghost blocks tend to appear with much higher frequencies at the corners of the tunnel than they appear elsewhere. On average I will get about one of these ghost blocks per chunk, mostly at the corners.

The impression I get is that there is some disagreement between the client and server as to whether a block is in range of a tool.

This sounds like something I've observed in farms and with netherrack. Sometimes I'll get stuck in a farm block and the screen gets all jittery and I can't get unstuck unless I break the block. And a couple of times in the nether I've gotten partially stuck in a nether rack wall and took damage. One time, I even got knocked in by a mob and died from suffocating in the block.

With farmland you probably mean MC-104259.

Verified for 1.11.2.

Reminder: getting stuck in the block and suffocating is no fun, the block is not minable as it's not present on the client... it can be cleared by trying to place a new block in that location, mind - or by logging in and out. f3+a does not re-download the block, as again - it is not known to the client.

I can also confirm this glitch for 1.10.2, 1.11, and 1.11.2. I'm assuming it's present throughout many versions, as well.

ca arive en 1.11.2 ausi

It is true that this problem is rather annoying

All the blocks that were supposed to be broken in this hole. They appeared after reconnecting. Tested in 1.11.2 vanilla.

Thank you for the confirmation that 1.11.2 is affected by this bug, but one confirmation per version is enough. We don't need any additional comments, unless you want to say something very important regarding the issue. Also, this is not a discussion forum, and your emotions about the bug or your experiences when you faced it are not important.

Now that I'm looking at game code, I'm starting to get an intuition about many of these things. I have a hypothesis that server-side ghost blocks are caused by client and server disagreeing on ORIENTATION.

I've observed an extreme case, which I reported as MC-118710. I believe it was inappropriate to close that bug as "invalid," but at the same time, it may actually be a slow-motion dupe of this one. Or more likely, "relates to," since that case does not involve high-efficiency tools. But since it's in slow-mo, this may offer us an opportunity to investigate the problem more deeply.

Here's a guess: As you're swinging your pick around with Haste II, you're changing your orientation. I think either (a) the client is not updating the user's orientation frequently enough, or (b) the orientation update can get delayed if the user's upload path back to the server is lagged. Either way, while the client thinks you're pointed in one direction and animates a block break, the server thinks you're pointed in a different direction and just trying to break air.

I made a system that prove that the bug has no random and that we can generate ghost block as we want.
The nbt structure is linked and a screenshot shows it.
How to use:
-Stand at the perfect middle of the yellow concrete block
-Take an efficiency 5 diamond pickaxe
-Target the middle of the first Sandstone block you can reach
-Hold your Attack control and don't change your direction
-Keep hold your Attack control and go forward without moving your mouse
-The red Sandstone block should be a ghost block, or one other that will be always the same at each trial.

@@unknown thank you very much for these reproduction steps. I am going to include them in the description.

Edit: Could you please remove your attached structure? I re-uploaded it with a valid resource location name (space replaced with underscore) and added two command blocks to give a pickaxe and position the player correctly.

I've forgotten to say that player must sprint while going forward. It won't work without sprinting.

suggested fix added to the Attachments. Since Client and Server are disagreeing about player speed, updating the client while they are mining the block makes sure client is always informed by the final state of the block, regardless if the client thought they mined it or not.

I think Gnembon's fix should be implemented as soon as possible, involving time machines where applicable.

But I also think that the problem can be mitigated by making the client update the player position and orientation more frequently while hit or use buttons are being held down. This may reduce the likelihood of client/server disagreement on which blocks are mined, especially when there is lag. But note that my suggestion will only make ghost blocks less likely, because the player can change orientation faster than any reasonable limit in update rate. Gnembon's fix is critical, because it will fix up all remaining cases where ghose blocks happen anyway.

@@unknown the main problem seems to be a disagreement about wether the player is on the ground or not. The client thinks it is letting you instantly mine a block while the server says the client is in the air which slows down the dig speed and prevents instant mining.

Regarding @unknown's "fix", I would rather call it a hack. If I recall this correctly it marks the block as changed for all players instead of only the one mining and does this everytime you start mining. A proper fix would probably be to have the client tell the server that it thinks it just instantly mined a block.

How it is implemented its up to the devs. This solution is very simple. Going one execution step deeper, you could notify only the proper event listener (not all of them) in World.java, or do it client side, by client reconfirming the block they mined. Its all about the source of the issue - lack of ACK after block is mined.

The devs may also want to consider a "lesser of two evils" approach to this. What's worse, the way it currently is, or some of the side-effects of Gnembon's (or rather Xcom's?) solution? I don't know how bandwidth-efficient client-server communication is, but from what little I know, it's probably more than adequate, even when not compressed. I don't have any reason to believe that informing all clients is going to generate an excessive amount of extra traffic.

The other thing to consider is the time to getting a workable fix. There are some pretty severe game-breaking bugs that have been sitting around for years. The user community has gotten to the point where we're looking at game code ourselves to figure these things out. If Xcom's fix is implemented now, then the game will be improved immediately, and then the devs can take their time to work on a "better solution" for later.

Finally, Marcono1234, while I'm sure you're right about what you're saying, and the fix could be improved, that would add complexity. The more complex of a fix that is offered by the community, the less likely it is to be adopted. The devs are very risk-averse (for good reason), so the objective with a "simpler" fix is to reduce risk. Since the devs aren't actually giving any feedback on this (that I know of), we're doing our best here to guess what they will find acceptable.

Please take further discussion to reddit.

I'm having this issue mining large mushroom blocks with an axe. It's mainly an issue because it breaks my large mushroom farm - leaving an invisible block means no new mushroom can grow until it's been removed.

I see an easy fix for this. Have the client ping the server each time it breaks a block, and make the server agree or disagree. If the server disagrees, the client puts the block back. You don't have to ping every client, only one client has to ping the server.

The sole reason to update all players with any block update is that there doesn't exist any code currently that can update a single block for a single player. There would need to be added 6-7 new methods going from World.java to ServerWorldEventHandler.java, PlayerChunkMap.java, PlayerChunkMapEntry.java. These classes would need additional functions just to handle updating a single targeted player regarding a block update. This would resolve the issue of not updating all players but it would honestly be a large rewrite that would probably be discarded because of the amount of changes.

There is no need to add heavy rewrite when the block updates are only sent to nearby players that can view the mined block in that same area around that block. There is often no more then 10-30 players at maximum in the same exact spot in minecraft getting at max 29 extra unneeded block updates. This update also only is sent out when blocks are not instant mined which also reduces the spam significantly. Adding the notification as shown is acceptable with the current architecture in place unless the number of players some day increases into the 100s in the same chunk. When and if that ever becomes a common practice then adding the tweaked optimized 100lines of code is a valid concern. But with the current state where at most 4-5 players view the same block and having the server send a few extra packages is a legitimately acceptable load. Carpet mod have been running this fix for a few months without noticing any performance changes at all on the server.

If this was a small little project that a single person programs for a small amount of people with good PCs, that would be ok. But Minecraft is going on the direction of cleaner code and every bit of performance counts for someone who has a bad PC. So a proper solution should always be preferred over a workaround.

@@unknown, I assume you could just send a SPacketBlockChange to the affected client which already done by the method net.minecraft.network.NetHandlerPlayServer.processPlayerDigging(CPacketPlayerDigging) in other situations in which the player was not able to destroy a block, for example because it was protected.

Nonetheless a "proper" fix for this bug probably consists at least of the following:

• Client has to send that it just instantly mined a block (currently only a start destroying without stop destroying packet is send).

• Server has to indicate that client should not have been able to mine block. Notifying other clients even for the animation should not be needed since at this point nothing was send to them.

• Possibly: Send position and on-ground in mining packet to prevent desync?

I did a report (duplicate)
I hope that they will fix this terrible bug, please vote, comment and watch 🙂

(Thanks for the report in 1.4, now it's updated)

If I may add to the discussion based on my observation based on using this fix for extended time. Sending updates to the client while a player mines a block is a way to prevent this issues, however the update that the block is still there occasionally reaches the client after they mined it, which sometimes causes flickering of the blocks after they got mined:

• client mines a block, removed from view

• server packet about block being there arrives with a delay (block is recreated)

• server sends a packed about block being broken (block is removed again)

Currently the server only knows only about the current block mined by the client, and doesn't do anything when a client starts mining a new block.

The "proper" fix in this situation would be to let the server keep track of the previously mined block and the current mined block. If a player aborts mining of a current block server side and moves to the other block, the previous block could be safely updated with no flickering effects (its either still there client side, client just skimmed over a block to mine something else), so update will have no effect, or it is actually mined client side, and is a ghost block and needs updating).
Another approach - server can assume different scenarios when client reports new block mined. Most if not all ghost blocks come from the situation where player is standing client side (faster mining speed) and floating server side (jumping, ladder, what have you). If player abandons mining a block ss, and had mining penalty ss, the server can compute time it would have taken the client to mine it without penalty, and if it would be possible - send a preventative update to the client.
Both of these solutions would fix these typical scenarios with minimum required updates sent to the client and it woudn't cause any extra visual flickering client side.
Bottom line: even occasional flicker feels much better than dealing with these pesky ghost blocks.

<3

@Grum

Thank you so much! 🙂

I am experiencing this again in 1.14.4!

Insta-breaking blocks (in my case, netherrack) while the player is falling (in my case, making a downwards staircase) creates client-side ghost blocks. I am on a Realms server, and I am using the pre-release of Optifine. More testing may be required.

Can confirm, the issue is back in 1.14.4, tested with no mods / full vanilla.

As the other commenters said above me, this bug is back in the game.
Should I make another ticket for it?

Please see MC-156852 if you have this issue in 1.14.4.

Confirmed 1.15.2

Both this issue and a clone of it (MC-156852) have been resolved as fixed, in 17w50a and 19w34a respectively. If you're still experiencing it, create a new issue, with updated steps to reproduce, please.