Rachel Arevalo

Code of the “issue”:

switch (this.hitResult.getType()) {
	case ENTITY:
		...
	case BLOCK:
		...
	case MISS:
		if (this.gameMode.hasMissTime()) {
			this.missTime = 10; // Delay in client ticks to be able to hit again
		}

		this.player.resetAttackStrengthTicker();
}

However, it seems to be a feature considering miss time is introduced solely to make this happen, and it is added specifically to non-creative players.

Also I have come up with better reproduction steps

Note that the screenshot is to show how to aim oneself to reproduce the issue, it does not show the issue itself.

This still happens in 1.21.11 Pre-Release 3, despite once again being resolved as fixed. Mojang simply added a creative modifier to the effective range of the component, however it still has not actually fixed this issue (which they claim directly to have fixed again). This should either be marked as Works as Intended, or the minecraft:attack_range component should take into account entity interaction range (perhaps applying the attribute modifiers to it on top of the max reach as if it were the base value for the attribute?)

It seems unintended based on it going unmentioned.

I am not sure this is a bug, however I can confirm that this does happen.

Can confirm. The system for producing the attack speeds is automated when the items are registered, and floating point imprecisions on top of the formulas used leads to strange attack speeds.

Please rename this report. It is unrelated to the minecraft:minimum_attack_charge component, rather, this issue arises as the stabAttack() method itself ignores attack cooldown as it is both:

1. Unnecessary for the Spear’s jab attack.

2. Used for the Spear’s charge attack.

The solution to this, in theory, is adding a parameter to stabAttack() for attack strength scale, and providing the attack strength scale as one in KineticWeapon, and the actual player attack strength scale in PiercingWeapon

Also this report is mislabeled as affecting 25w42a

In theory this could be solved with adding a condition for checking food data instead of the way that they did implement it (of course, also adding a condition, unless one already exists, to check for creative to bypass it)…

By the way, can you update the to reproduce, expected result, and actual result sections to include more detail? This is what I have in mind:

Steps to reproduce:

1. Set the game’s tick rate to 5 TPS.

2. Hit a mob.

3. Observe that the mob does not visually move on the client for an arbitrary delay.

4. Repeat.

5. Notice that the delay varies in length.

Expected result:

The mob should move instantly on the client.

Actual result:

The mob experiences variable degrees of delay for the knockback to occur.

Also in 1.21.10

Confirmed in 25w42a

Neither of these reports are attribute swapping, the Spear just provides its Attack Damage modifier to the off-hand…

Isn’t this just [MC-152728] The player continues sprinting when performing actions that slow them down?

Despite claimed fix, still happens in 25w42a.

To be more specific, the spear does check if a block is in the way of its attack, however it is between min reach and max reach. If the block is in front of the player but at a distance less than the min reach, it cannot be picked and thus fails. This should be easy to fix, make it pick blocks from the entity’s eye position to its max reach instead and cancel it if the block hit result is less than the min reach.

I should note, easier fix: just move the call for ChunkMap.tick() to the end of ServerLevel.tick(BooleanSupplier booleanSupplier). This is what I did in my PR for Paper, and it works flawlessly.

If I had to speculate, the performance impact was more substantial back when the game was older, so these checks were an optimisation made to account for that. my preferred fix would be bumping the base tick speed for the game up to either run entirely on delta time or to run at a higher tick rate since this also minimises tick jitter and makes the update intervals less important.

But I do agree, though it might have minor performance impacts this would in general be an improvement, but not necessarily a bug since it’s how the server code was intentionally designed and has always worked, 1.3 just made it impact singleplayer.