If the player hits at something that isn't a block and holds the button while aiming next to a block, then moves the crosshair onto the block, there is a slight delay until they actually start swinging at and break the block. This is especially noticeable when instamining blocks.
Apparently this bug was introduced far back in 1.8, so it doesn't seem to be an intended mechanic from the cooldown changes of 1.9 (which also shouldn't affect block breaking).
How to reproduce
Place any easily breakable block, set your game mode to survival.
Put your crosshair next to the block looking at air, then press left click (default punch button).
Hold the button and quickly move your crosshair to the block.
Notice how there's a slight delay before the player actually starts breaking the block.
Expected result
After looking at the block, the player would start breaking the block without any delay, like in this clip.
Observed result
When moving the camera at the block, the player has a slight delay before they start breaking it, like in this other clip (requires slowing down the video to see easily).
Linked issues
is duplicated by 1
Attachments
Comments 6
Affects 22w11a.
Confirmed in 23w44a. If possible I'd like to take ownership of the report to update some things.
May be WAI. This behavior actually dates as far back as the Survival Tests in Survival. Note that this behavior does not happen in Creative Mode. The only version without this delay in Survival Mode seems to be 1.7.x. This behavior is also responsible for the "1.8 Click Delay" or "1.8 Miss Penalty" (or, in older years, "1.8 CPS Cap") behavior which was observed in PVP.
Code analysis (Using 1.20.2 Mojang Mappings):
In net.minecraft.client.Minecraft:
private boolean startAttack() {
if (this.missTime > 0) {
return false;
}
...
else {
...
if (...) {
...
} else {
...
switch(this.hitResult.getType()) {
...
case MISS:
if (this.gameMode.hasMissTime()) {
this.missTime = 10;
}
this.player.resetAttackStrengthTicker();
}
...
}
}
}
public void tick() {
...
if (this.overlay == null && this.screen == null) {
...
if (this.missTime > 0) {
--this.missTime;
}
}
...
}We can see that in this code, there is a 10 tick "miss time" which is applied every time a hit is missed and if the game has this enabled. During this miss time, no attack is possible. However, if the mouse is not being held down the next tick, this miss time is reset to 0 and the attack may apply as seen here:
private void continueAttack(boolean bl) {
if (!bl) {
this.missTime = 0;
}
...
}where the boolean bl indicates whether the mouse is being held down. Though this also requires that this.gameMode.hasMissTime() returns true. After a quick check in net.minecraft.client.multiplayer.MultiPlayerGameMode, we can see when this miss time is enabled in:
public boolean hasMissTime() {
return !this.localPlayerMode.isCreative();
}which is all gamemodes except creative mode.
After some surface-level testing, that is finding this behavior in versions as far back as 1.6.4, 1.5.2, Beta 1.8 (which introduced most modern combat mechanics), it seems that all versions except at least 1.7.10 may have this behavior and that it was intended (missing already behaved differently as early as Classic 0.30 between Survival Test and 0.30c), and in versions before Beta 1.6 this miss time was even harsher (completely preventing any swing at all regardless of "continued attack"). This is why I think this behavior is in some way Works as Intended, even if most people would argue that it looks more like a bug. I will admit that it does look more like an old relic from the primitive combat system from early Minecraft.
This issue is undoubtedly related to what the PvP community calls the "1.8 Click Delay" or "1.8 Miss Penalty".
For more info on the "1.8 Click Delay", check out this video which relates this issue from the PvP standpoint: https://www.youtube.com/watch?v=j1pblMl9ylY
TLDR: This mechanic isn't a "bug" introduced in Release 1.8, but rather a mechanic that was here from the beginning of Minecraft except in Release 1.7.x.
Personally I would like to see the delay be made longer if an entity was hit by the attack, since right now it is very hard to destroy boats in creative mode without also breaking the block under them (the same is true when eg. breaking a boat which is on/next to slime blocks with a sword or axe in survival).
Clam, you're describing MC-73162.
Affects 20w46a