Rachel Arevalo

Also sorry if I sound hostile or snarky, I have trouble with tone

Although I will admit the packet arrival time specification might be too specific

Duffy is right, for that matter, although this is redundant as all of this was said in different words before

Perhaps you could say my initial fix was wrong, which debatably it was, but my initial fix was based on the notion that it was optimal to do that, but as ChunkMap.tick() is directly responsible for the call, just moving that call later in ServerLevel.tick(…) is appropriate.

Well quite frankly I don't know the inaccuracy in what I said at all, ChunkMap.tick() is the method that is directly responsible for updating all entity trackers since 1.14. It is called inside this.getChunkSource().tick(…), as you said. Nothing I said disagrees with you, what I said was that the entities positions are not yet updated for the tick when ChunkMap.tick() is called causing the delay. Since packets are always handled at the end of the tick it is impossible for it to, on attack, update position between when knockback is called and when the entities are synced to players. What I said is the same as what you said but more specific in explaining the issue.

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?