[MC-5694] High efficiency tools / fast mining destroys some blocks client-side only Created: 03/Jan/13 Updated: 06/May/24 Resolved: 07/Dec/17 |
|
| Status: | Resolved |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Minecraft 1.4.6, Minecraft 15w42a, Minecraft 15w47a, Minecraft 15w49b, Minecraft 15w50a, Minecraft 15w51b, Minecraft 16w03a, Minecraft 16w05b, Minecraft 1.9 Pre-Release 2, Minecraft 1.9 Pre-Release 4, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.2, Minecraft 16w15b, Minecraft 1.9.4, Minecraft 1.10, Minecraft 1.10.2, Minecraft 16w32a, Minecraft 16w32b, Minecraft 16w33a, Minecraft 16w39b, Minecraft 16w39c, Minecraft 16w44a, Minecraft 1.11, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 17w18a, Minecraft 1.12 Pre-Release 6, Minecraft 1.12 Pre-Release 7, Minecraft 1.12, Minecraft 1.12.1, Minecraft 1.12.2 Pre-Release 1, Minecraft 1.12.2 |
| Fix Version/s: | Minecraft 17w50a |
| Type: | Bug | ||
| Reporter: | Martin Bittermann | Assignee: | [Mojang] Grum (Erik Broes) |
| Resolution: | Fixed | Votes: | 165 |
| Labels: | block-breaking, client-side, efficiency, ghost-block, haste | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Game Mode: | Survival | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
The bugMining lots of blocks at once by holding your mouse while equipped with a tool capable of instamining blocks (efficiency 5 diamond shovel vs dirt, for example) will leave some blocks on the server, but the client thinks they're gone. This bug 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. How to reproduce (with provided structure)Partwise by francois137
How to reproduceSee Ghost-block reproduction (1.12).mp4
Code analysisBased on 1.12 decompiled using MCP 9.40 PRE 1 It looks like this bug is caused by the server thinking that the player is not on ground and therefore cannot instamine a block while the client thinks it can. This can be seen when setting a breakpoint in net.minecraft.server.management.PlayerInteractionManager.onBlockClicked(BlockPos, EnumFacing) for the specific block position where a ghost block will be (see "How to reproduce (with provided structure)") and then following the method calls to EntityPlayer.getDigSpeed(IBlockState). For lagging servers or clients this another cause could likely be the method net.minecraft.network.NetHandlerPlayServer.processPlayerDigging(CPacketPlayerDigging) which is not sending a SPacketBlockChange packet to resync the block if the block position is too far away from the player. Suggested fix by gnembon can be found in fix_miningGhostBlocks.PNG |
| Comments |
| Comment by [Mod] Pokechu22 [ 27/Jan/20 ] |
|
Both this issue and a clone of it ( |
| Comment by dust [ 27/Jan/20 ] |
|
Confirmed 1.15.2 |
| Comment by [Mod] Asteraoth [ 31/Jul/19 ] |
|
Please see |
| Comment by Sergio Mendez [ 31/Jul/19 ] |
|
As the other commenters said above me, this bug is back in the game. |
| Comment by Vectole [ 22/Jul/19 ] |
|
Can confirm, the issue is back in 1.14.4, tested with no mods / full vanilla. |
| Comment by Farafelix [ 21/Jul/19 ] |
|
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. |
| Comment by Early Reflections [ 07/Dec/17 ] |
|
@Grum Thank you so much! |
| Comment by [Mojang] Grum (Erik Broes) [ 07/Dec/17 ] |
|
<3 |
| Comment by [Mojang] Gnembon [ 19/Nov/17 ] |
|
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:
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. |
| Comment by Hugo Martín Fernández [ 04/Nov/17 ] |
|
I did a report (duplicate) (Thanks for the report in 1.4, now it's updated) |
| Comment by Marcono1234 [ 01/Oct/17 ] |
|
@Xcom6000, 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:
|
| Comment by Fabian Röling [ 01/Oct/17 ] |
|
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. |
| Comment by Xcom6000 [ 01/Oct/17 ] |
|
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. |
| Comment by reaverofdarknes1 [ 10/Sep/17 ] |
|
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. |
| Comment by Karuna Boyum [ 03/Aug/17 ] |
|
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. |
| Comment by user-f2760 (Inactive) [ 31/Jul/17 ] |
|
Please take further discussion to reddit. |
| Comment by Timothy Miller [ 31/Jul/17 ] |
|
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. |
| Comment by [Mojang] Gnembon [ 23/Jul/17 ] |
|
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. |
| Comment by Marcono1234 [ 23/Jul/17 ] |
|
@theosib2 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 gnembon'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. |
| Comment by Timothy Miller [ 22/Jul/17 ] |
|
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. |
| Comment by [Mojang] Gnembon [ 22/Jul/17 ] |
|
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. |
| Comment by franswa [ 26/Jun/17 ] |
|
I've forgotten to say that player must sprint while going forward. It won't work without sprinting. |
| Comment by Marcono1234 [ 26/Jun/17 ] |
|
@francois137 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. |
| Comment by franswa [ 25/Jun/17 ] |
|
I made a system that prove that the bug has no random and that we can generate ghost block as we want. |
| Comment by Timothy Miller [ 25/Jun/17 ] |
|
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 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. |
| Comment by SunCat [ 01/Feb/17 ] |
|
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. |
| Comment by franswa [ 01/Feb/17 ] |
|
All the blocks that were supposed to be broken in this hole. They appeared after reconnecting. Tested in 1.11.2 vanilla. |
| Comment by Julien Ricoeur [ 01/Feb/17 ] |
|
It is true that this problem is rather annoying |
| Comment by bibiche3801@gmail.com [ 01/Feb/17 ] |
|
ca arive en 1.11.2 ausi |
| Comment by Connor Snow [ 17/Jan/17 ] |
|
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. |
| Comment by jo [ 27/Dec/16 ] |
|
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. |
| Comment by Fabian Röling [ 29/Nov/16 ] |
|
With farmland you probably mean |
| Comment by Timothy Miller [ 29/Nov/16 ] |
|
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. |
| Comment by bdm68 [ 28/Nov/16 ] |
|
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. |
| Comment by Synthestra [ 26/Nov/16 ] |
|
Confirmed for 1.11 |
| Comment by Fabian Röling [ 07/Nov/16 ] |
|
Try it. |
| Comment by CDES5 (Inactive) [ 07/Nov/16 ] |
|
Does this affect 16w44a? |
| Comment by Thomas Darnell [ 05/Oct/16 ] |
|
I have tried this and it didn't work after multiple times. |
| Comment by [Mod] tryashtar [ 05/Oct/16 ] |
|
I can still reproduce up through 16w39c. |
| Comment by Fabian Röling [ 20/Aug/16 ] |
|
Can someone reproduce for 16w33a? I tried for a while and either it's fixed or it got much rarer. |
| Comment by Daniel Busch [ 07/Jul/16 ] |
|
Any ideas when this bug is going to be fixed? |
| Comment by Bengineer8 [ 23/May/16 ] |
|
@fenxjox google is not yielding any satisfying results. Can you give me a link? |
| Comment by fienxjox [ 21/May/16 ] |
|
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. |
| Comment by Bengineer8 [ 21/May/16 ] |
|
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. |
| Comment by [Mod] Pokechu22 [ 21/May/16 ] |
|
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. |
| Comment by Bengineer8 [ 21/May/16 ] |
|
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]) |
| Comment by user-f2760 (Inactive) [ 20/May/16 ] |
|
Singleplayer=locan 1 man server |
| Comment by Bengineer8 [ 20/May/16 ] |
|
I've had this happen in single player, how is that even possible? I´m not on any server, what is getting desynchronized? |
| Comment by [Mod] Pokechu22 [ 08/May/16 ] |
|
Code check, yes, there is definitely a difference between the two:
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. |
| Comment by [Mod] Pokechu22 [ 08/May/16 ] |
|
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. |
| Comment by Fabian Röling [ 08/May/16 ] |
|
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. |
| Comment by [Mod] Pokechu22 [ 07/May/16 ] |
|
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. |
| Comment by SunCat [ 13/Apr/16 ] |
|
Still in 16w15b |
| Comment by Ken Pearson [ 26/Mar/16 ] |
|
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 |
| Comment by SunCat [ 12/Mar/16 ] |
|
Still in 1.9.1-pre3 |
| Comment by Fabian Röling [ 26/Feb/16 ] |
|
For the F3+A I created |
| Comment by jo [ 26/Feb/16 ] |
|
confirmed for 1.9 pre 4. |
| Comment by Stryker [ 24/Feb/16 ] |
|
Confirmed for 1.9 pre2 |
| Comment by g10r [ 25/Jan/16 ] |
|
Confirmed in singleplayer 16w03a. |
| Comment by Sam Bone [ 24/Jan/16 ] |
|
Happens to me in SSP in 15w50a |
| Comment by Zigworf [ 13/Dec/15 ] |
|
Confirmed for 15w50a |
| Comment by Zigworf [ 08/Dec/15 ] |
|
Confirmed for 15w49b |
| Comment by Zigworf [ 08/Dec/15 ] |
|
Confirmed for 15w47c |
| Comment by [Mod] redstonehelper [ 19/Oct/15 ] |
|
cubetrace: Thanks, I split them up and made you the reporter of both tickets since the original reporters are both inactive. |
| Comment by Martin Bittermann [ 22/Aug/15 ] |
|
Not a duplicate of 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: This bug ( By the way, |
| Comment by Tails [ 03/Jan/13 ] |
|
Duplicate of |