Revvilo

Thank you, Rachel.

Much better title. A big improvement on mine.

I had suspected tick freeze would hide the bug, as it seems to force synchronisation on each step.

Your proposed fix is excellent. Could moving logic around have unintended side effects with movement caused by the environment, or would the fix only effect the synchronisation itself?

Hi, thank you for that thorough message.
I apologize for not being clearer. I'm finding this quite a complicated thing to communicate so I appreciate your input.

Yes, you have all of that correct, but I want to stress that it can take between 1 and 3 ticks to react. The inconsistency is why I want this looked into.

Every entity has an update rate set when it is registered. When the game ticks the chunks and considers sending the entity positions to the clients, it checks something like:

worldTicks % mobUpdateRate == 0 || hasImpulse == true

so if mobUpdateRate is 3 then the positions will only be sent every 3 ticks - or always if the hasImpulse flag is true.

I'm unsure if handling the attack is asynchronous on the server, but it's which tick in the 3 tick update cycle the attack takes place on which causes the most inconsistency.

Given the fact we’ve established that the entity’s ‘knockbacked’ position doesn’t manage to bypass the once-every-3-tick update cycle of entities, the following is true;
If you attack on the tick that the entity is updated, your client won't be sent the update until three ticks after, which is where I got the title from. This is very visible if you’re looking for it. It feels like lag in singleplayer. I’d like to get a video to demonstrate but I’m about to go to work.
I personally think this is the important part here, because there is actual code in the game to prevent this kind of issue, like with entering a bed, for example, but due to the order of things, with knockback, it hasn’t worked as intended.

Please let me know if you’d like some more info and I’ll get it as soon as I can.