mojira.dev
MC-52881

Knockback distance incorrect, depends on login order

Currently there are 2 bugs which completely break pvp, and this is one of them.

The knockback distance is determined by the order of players logging in to the server. So, the players that logged in last get the correct knockback, but players who logged in earlier get incorrect knockback.

Steps to reproduce:
1- Setup a command to teleport your TestPlayer to a fixed location, and don't move your test player;
2- Setup some signs to signal the distance that you knock the player back;
3- Relog.
4- Now sprint and hit the player once. Notice how far you send the player. Try this a few times, you should get similar results.
5- Relog your test player. Now, with your main account, repeat step 4. Notice that now the test player is getting the correct knockback (and not being sent "flying"). Again, try a couple times.

According to TrazLander ( https://www.youtube.com/watch?v=kp4h0O_YKYw ), something that might be causing this is something that we think that can be named "Packet Priority", where the packets are not being sent to all players in the correct order. This is a logical explanation as if the player logs in last gets the correct knockback, means that the client is getting the packets in the correct order and faster than other clients.

Yes, this is in vanilla Minecraft. No mods, neither on the server nor on the client.

Linked issues

Comments 6

Thanks for reporting this! And also linking my video.

So, I also found this: MC-7873 - Server lag reduces knockback received
and this: MC-17556 MC-32329 - Multiplayer PvP glitch (relog glitch)

These two old bugs, one of them incorrectly marked, have combined with the recent update to be able to hotkey your sprint key to a single button, and avoid a 3RD sprint-knockback bug where you can quickly toggle on another sprint-knockback (which is more of an exploit of current mechanics). This has created a SUPER bug that allows players to be able to knock back players 12+ blocks in TWO hits (example of how to do this in the video link). Which obviously can be a bit much in a PvP fight.

They still haven't fIxed this. I think that the problem is somehow related to the Netty framework but I can't say for sure as I don't know exactly how and when knockback is applied. Still, I'm both a big fan of pvp and a big fan of coding, sรณ, I would like to see this issue addressed. And btw, no problem in posting your video; that's how I found out about these bugs, and thanks for telling me workarounds ๐Ÿ˜›

Hello, I can explain exactly what causes this and provide a patch to fix it.

First of all, the description has it backwards. The player who connected first receives the correct knockback. The later connected player receives less knockback when hit by the earlier connected player.

This happens because the server applies friction to the player's velocity every time it receives a movement packet from the player. The later connected player's serverbound packets are processed in between the hit from the earlier player and the velocity update packet being sent to the client, which is deferred to the end of the tick. So, each of the later player's movement packets in the queue will reduce the knockback velocity, before it is sent to the client. If those movement packets say that the player is on the ground, then ground friction will be applied, which cuts velocity roughly in half every tick, so it only takes a few packets in the queue to reduce knockback to nearly zero.

For players A and B, who connected in that order, the sequence of events looks something like this (this all happens in a single tick):

  • server processes inbound packets from all players, in the order they connected

    • server processes an inbound packet from A saying to attack B, which changes B's server velocity (but does not yet update the client)

    • server processes any number of inbound movement packets from B saying that B is standing on the ground, and applies a tick of ground friction to B's velocity for each one

  • server ticks all players

    • server sees that B's velocity changed and sends a velocity update packet to the client

Packets from B attacking A are processed after A's movement packets, so the velocity is NOT reduced before it is sent to the client at the end of the tick, and A receives the full knockback.

The simplest fix for this is probably the one implemented in this Bukkit patch:
https://github.com/OvercastNetwork/SportBukkit/commit/0a6819e11487d6fef0b5bdc4fbd635ef8a512101

That patch simply sends the velocity update to the client immediately after the hit, rather than waiting for the end of the tick. It also does not update the server velocity from the knockback, it just sends it to the client and then forgets about it. This effectively disables server-side velocity tracking entirely.

We have playtested this patch and it works great. It makes melee combat very noticeably less erratic.

An even better fix for this would be to get rid of server velocity entirely, as it does not seem to serve any useful purpose. It is essentially meaningless because it is not affected by player movement at all, only by knockback and gravity. So, the player's server velocity is generally zero, unless they are falling or getting knocked back. And when it is not zero, the friction applied from incoming packets still makes it extremely inaccurate. Also, knockback is the only the only thing that actually causes the server velocity to be sent to the client. At all other times, server velocity is entirely passive.

It would be simpler and more accurate to just give the client exclusive control over velocity (since it already has exclusive control over movement) and for things like knockback to be implemented by sending relative velocity changes (impulses) to the client.

Feel free to contact me for details or clarification of anything.

Used suggested fix by Last Username for time being, will investigate full fix at a later date.

Do you know if this bug was present in 1.6.4 or under? I'm not sure if it was, and I can't test that right now. If it wasn't, it might be because of the network code rewrite, or probably some bug in the Netty framework or something like that. But, if it's Netty, the Network code rewrite probably caused a lot more yet to be found bugs, but fixed some other ones, didn't it? ๐Ÿ™‚

Well, I'm not a fan of the removal of server velocity. That's just one more hack for server admins to deal with, and, as a server moderator which also finds hackers it's gonna be harder, I mean, one more hack to look for...

KnockBackFixer, a spigot plugin develop by me fix this bug.
http://www.spigotmc.org/resources/knockbackfixer.6388/
It's free!

D4rKDeagle

Nathan Adams

Unconfirmed

Minecraft 1.7.5, Minecraft 1.7.8

Minecraft 14w20a

Retrieved