How to reproduce
Look at a block and start mining it
Walk / look away from the block so you lose focus of it while still holding left click - the cracks disappear, working as intended so far
Without letting go of the mouse button, walk up to/look at it again so it is focused - cracks start to appear again, working well
Walk / look away again - the cracks stay, there's your issue
See also MC-125127.
Linked issues
is duplicated by 61
relates to 18
Attachments
Comments 75
Can confirm for 1.8.6
Some other things I found:
This bug only happens if you are only just able to reach the block when you start to break it - I found I had to be at least 4 1/3 blocks away from the block I was breaking.
If you move back into this range between 4 1/3 blocks and the limit, you can continue to break the block.Once the glitch has happened, holding down left click while moving in and out of range will allow the block to be mined in stages provided the player does not mine any other block in that time. Left click does not have to be held down all the time, just when coming into range
The most pressing exploit of this is mining trees while jumping. When you jump, you are in block-breaking range of what is sometimes the topmost tree block and if you hold left click then occasionally after a handful of jumps you will partly mine the block. I assumed it was server lag when this happened to me but apparently not.
Confirmed. You must be at the extreme edge of the block-breaking range for this bug to occur. The easiest way to replicate this bug is to place a block 6 blocks above you, and jump at it while holding the mine button. The outstanding mining progress will reset itself after a few seconds if left alone.
The main cause of this behavior is MC-255057 (continuing to destroy a block only cares if the block that was last targetted is the same as the current block, not if you were still destroying a block).
This was introduced in 14w29a (a 1.8 snapshot), which changed MultiPlayerGameMode.stopDestroyBlock from
public void resetBlockRemoving()
{
if (this.isHittingBlock)
{
this.netClientHandler.addToSendQueue(new C07PacketPlayerDigging(1, this.currentBlockX, this.currentBlockY, this.currentblockZ, -1));
}
this.isHittingBlock = false;
this.curBlockDamageMP = 0.0F;
this.mc.theWorld.destroyBlockInWorldPartially(this.mc.thePlayer.getEntityId(), this.currentBlockX, this.currentBlockY, this.currentblockZ, -1);
}to
public void resetBlockRemoving()
{
if (this.isHittingBlock)
{
this.netClientHandler.addToSendQueue(new C07PacketPlayerDigging(C07PacketPlayerDigging.Action.ABORT_DESTROY_BLOCK, this.currentBlock, EnumFacing.DOWN));
this.isHittingBlock = false;
this.curBlockDamageMP = 0.0F;
this.mc.theWorld.sendBlockBreakProgress(this.mc.thePlayer.getEntityId(), this.currentBlock, -1);
}
}i.e. prior to that version, if a block was no longer targetted, then the break progress would be reset to 0, making things mostly behave normally (though it still would fail to tell the server that it started breaking the block, and redstone ore wouldn't begin to glow in this case).
I'm not sure why this change was made. The only relevant issue fixed in 14w29a is MC-676, but I don't think this change was directly part of that fix. So perhaps it was an intentional change, but it wasn't included in the changelog and is implemented fairly awkwardly.
I studied this behavior extensively because it is part of a wireless redstone glitch that I’ve been studying over 4 years. Let me corroborate what others have said:
- This was introduced in 14w29a
- This still works as of 26.3-snapshot-9
- This is caused by a combination of continueDestroyBlock not calling startDestroyBlock when block position matches with that of the last block mined (which means isDestroying never gets set to true) and stopDestroyBlock not doing any
thing if isDestroying is false
- The changelog for 14w29a makes no mention of this change
If this were considered a bug and removed from the game, I can imagine there would be some amount of backlash, the extent of which is unclear. Under PhoenixSC’s video, a lot of people said things along the lines of:
- “this isn’t a bug this is a feature“/”how is this a bug? isn’t it a feature?” (it’s extremely old, rarely ever mentionned, and finds a decent amount of casual use, so it makes sense they’d think that)
- “I used this all the time. I hope it doesn’t get removed“ (I personally used it a LOT when I was farming large amounts of wood on a server)
- “This feels natural and is how a lot of other voxel/pixel games handle this“ (I don’t play many games but I think e.g. Terraria does this and it feels rather natural in that game at least)
Among several others ways of expressing that it would suck for this to be removed, with a lot of discontent.
I edited the game’s code to remove the check in stopDestroyBlock (which caused other issues as you can see by the attack strength ticker and the lack of a visible hand). Here’s a quick video demonstrating 4 cases that are affected by this behavior:
Farmland still gets broken if you hold down left click and press right click repeatedly with seeds. This would in theory be the case for any instabreakable block. However, if you instead let go if left click before pressing right click, the breaking progress resets, whereas without the change it does not.
Mining for the top logs of trees and ores that are just barely out of reach can no longer be done by jumping.
The original method for remote breaking no longer works but the bug can still be caused by other means (of which I have demonstrated one but there are others).
Block breaking progress no longer carries over to the next block when you mine (something which caused issues in this video), UNLESS you’re mining the block right in front of a 0-ticking piston’s head (because instead of a moving block entity you always get a block in that position).
Overall I feel like this would be a rather poor way to fix the bug, and that further consideration should be taken to get rid of the buggy-feeling aspects of this without giving players the impression that features are being taken away from them for the sake of “it’s not what we intended“. If not implemented properly, a fix could achieve the exact opposite, removing only the parts that players liked.
Can't confirm in 1.8.3. Are you still experiencing the issue?