The Bug:
Breaking blocks that can be instantly destroyed slowly breaks the targeted block behind them.
Please note that this is not a visual glitch. The targeted block will be destroyed as normal once the breaking animation on it is complete.
Steps to Reproduce:
Obtain a stack of short grass and switch to survival mode.
While looking at some dirt, constantly place and break the short grass in quick succession.
Observe the block breaking progress of the targeted block behind the short grass.
Observed Behavior:
The targeted block behind the block that can be instantly destroyed slowly breaks and shows block cracks.
Expected Behavior:
The targeted block behind the block that can be instantly destroyed would not break at all.
Linked issues
is duplicated by 80
relates to 11
MC-255057
Client/server desync when breaking block from continueDestroyBlock
Open
MC-205451
Breaking block texture remains after breaking item frame/painting
Reopened
MC-70359
Block breaking remains when eating/blocking with a sword
Resolved
MC-8472
Block cracks remain on blocks in adventure mode when losing focus of them
Reopened
MC-19676
Breaking particles, sounds, and block cracks can be created in adventure mode
Reopened
Attachments
Comments 29
Reopened since this behaviour didn't exist prior to 1.14.4-pre6, as opposed to MC-69865.
Some (maybe distracting) information to add:
The rate at which the block breaks increases if the player is wielding the appropriate tool for the block. It's not always 1 "point" of crackage.
This only works with blocks that are naturally instantly breakable with an open hand; I have not been able to recreate this using efficiency tools on dirt, shears on leaves, or by trying to hit a block through chickens.
This issue becomes very obvious when holding right-click to use bonemeal to grow crops while holding the replacement crop in off-hand. (ie: <hold right>bonemeal, <still holding right>bonemeal, <still holding right>bonemeal, <click left>break , <still holding right>place new crop, <still holding right>bonemeal... and so on). The farmland becomes damaged over time, and eventually breaks.
The "damage" to the farmland does not go away unless the farmland is hit exactly once, directly, without holding right-click, at which point the damage resets.
I found out, in which version exactly this bug was introduced. In version 1.14-pre5, this bug doesn't occur, in version 1.14-pre6, this bug occurs
Can confirm in 1.21.6-rc1
Also when the block behind is broken, it disappears and drops as an item after a short period of time.
Caused by the removal of the re-assignation of field “destroyBlockPos” at MultiPlayerGameMode’s “destroyBlock” in 1.14.4pre6, made to fix MC-156451. Instead of doing that, the assignation should’ve been moved to right after calling “destroyBlock” inside the instamine check at “startDestroyBlock“, assigning the method param value to “destroyBlockPos“.
Here is the fix demonstration in modern 26.4-snap5 source code (also tested in 1.14.4pre6):
public boolean startDestroyBlock(BlockPos pos, Direction direction) {
if (this.minecraft.player.blockActionRestricted(this.minecraft.level, pos, this.localPlayerMode)) {
return false;
} else if (!this.minecraft.level.getWorldBorder().isWithinBounds(pos)) {
return false;
} else {
[...]
if (notAir && state.getDestroyProgress(this.minecraft.player, this.minecraft.player.level(), pos) >= 1.0F) {
this.destroyBlock(pos);
this.destroyBlockPos = pos;//<-- Should add this line right here
} else {
this.isDestroying = true;
this.destroyBlockPos = pos;
this.destroyDirection = direction;
this.destroyingItem = this.minecraft.player.getMainHandItem();
this.destroyProgress = 0.0F;
this.minecraft.level.destroyBlockProgress(this.minecraft.player.getId(), this.destroyBlockPos, this.getDestroyStage());
this.minecraft.level.addBreakingBlockEffects(this.destroyBlockPos, this.destroyDirection, true);
}
return new ServerboundPlayerActionPacket(Action.START_DESTROY_BLOCK, pos, direction, sequence);
});
}
return true;
}
}Could explain more, but I’ve ran out of time.
Thank you for your report!
We're actually already tracking this issue in MC-69865, so I resolved and linked this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.