Client-server desync when player attacks while holding sprint key
If the player is holding the sprint key and attacks something (like a mob or other player), this will not interrupt their sprint, as it does with a double-tap sprint. However, the server assumes that this does interrupt the sprint, and the player's server state is changed accordingly. This results in a situation where the client thinks the player is sprinting and the server thinks they are not.
One effect of this is that knockback distance is reduced, since that is calculated on the server. From the player's perspective, their first hit while sprinting will cause much more knockback than all following hits, until they restart their sprint. This is counter-intuitive, since the sprint could go on for any length of time, reducing knockback for no apparent reason, whereas restarting the sprint will instantly allow the extra knockback.
Here is a video demonstration of the bug:
https://www.youtube.com/watch?v=kp4h0O_YKYw#t=9m50s
Any fix for this will change gameplay noticeably. Preserving the client behavior and fixing the server to stay in sync will make sprint knockback much more powerful. Changing the client to match the server means that sprinting will be interrupted when attacking, which players may consider regressive.
Some possible compromises:
- Fix the server to match the client, but reduce the sprint knockback bonus in general, to balance it out
- Fix the server, and add a timed cooldown between sprint knockbacks
- Fix the server, but use other factors to reduce knockback, such as the target's velocity and sprinting state
Linked Issues
is duplicated by6
MC-93664Sprinting players can perform sweep attacks after a single knockback attackDuplicateMC-238744Holding Ctrl to sprint then attacking causes the sprint distance statistic to not incrementDuplicateMC-249978Run foreverDuplicateMC-259707Hitting an entity while sprinting makes the game think you are walkingDuplicateMC-264787Sprinting flags become inconsistent after attacking an entity while sprinting if the sprint key is heldDuplicateMC-266910Sprinting while being attacked + attacking player has weird behaviorDuplicate
Importantrelates to6
MC-142180You cannot perform sweeping attacks while swimmingConfirmedMC-11608Sprinting is cancelled when attacking a mobWorks As IntendedMC-175968An attack with a sword does not hit nearby enemies while sprintingWorks As IntendedMC-271427Sweep attacks no longer trigger consistentlyFixedMC-129568Sprint swimming underwater and hitting a mob will stop the player from sprinting under certain conditions
NormalMC-56229Sprint scoreboards won't increase after sprint-attacking (with the sprint key held down)Duplicate- Unresolved
Solo Alguien
Last Username- 39
- 20
- Confirmed
- Normal
- Platform
- Combat Networking
1.8-pre2 - 1.21.4
1.8-pre2 1.8 1.8.1 1.8.2-pre1 15w49a 15w49b 15w50a 15w51b 16w02a 16w04a 16w06a 1.9.1 1.9.2 1.10.2 16w43a 1.13.1 1.14.3-pre1 1.15.1 1.16.1 20w49a 21w03a 21w05b 21w06a 21w07a 1.17.1 1.18.2 22w14a 22w15a 22w16b 22w17a 22w18a 1.19.2 22w42a 22w43a 22w44a 22w45a 22w46a 1.19.3-pre1 1.19.3-pre2 1.19.3-pre3 1.19.3-rc1 1.19.3-rc2 1.19.3 23w03a 23w04a 23w05a 23w06a 23w07a 1.19.4-pre1 1.19.4-pre2 1.19.4-pre3 1.19.4-pre4 1.19.4-rc1 1.19.4-rc2 1.19.4-rc3 1.19.4 23w12a 23w13a 23w14a 23w16a 23w17a 23w18a 1.20-pre1 1.20-pre2 1.20-pre4 1.20-pre5 1.20-pre6 1.20-pre7 1.20-rc1 1.20 1.20.1-rc1 1.20.1 1.20.2 1.20.4 1.21 24w36a 1.21.2-pre3 1.21.3 24w46a 1.21.4
Created Issue:
Client-server desync when player attacks while holding sprint key
If the player is holding the sprint key and attacks something (like a mob or other player), this will not interrupt their sprint, as it does with a double-tap sprint. However, the server assumes that this does interrupt the sprint, and the player's server state is changed accordingly. This results in a situation where the client thinks the player is sprinting and the server thinks they are not.
One effect of this is that knockback distance is reduced, since that is calculated on the server. From the player's perspective, their first hit while sprinting will cause much more knockback than all following hits, until they restart their sprint. This is counter-intuitive, since the sprint could go on for any length of time, reducing knockback for no apparent reason, whereas restarting the sprint will instantly allow the extra knockback.
Any fix for this will change gameplay noticeably. Preserving the client behavior and fixing the server to stay in sync will make sprint knockback much more powerful. Changing the client to match the server means that sprinting will be interrupted when attacking, which players may consider regressive.
Some possible compromises:
- Fix the server to match the client, but reduce the sprint knockback bonus in general, to balance it out
- Fix the server, and add a timed cooldown between sprint knockbacks
- Fix the server, but use other factors to reduce knockback, such as the target's velocity and sprinting state
If the player is holding the sprint key and attacks something (like a mob or other player), this will not interrupt their sprint, as it does with a double-tap sprint. However, the server assumes that this does interrupt the sprint, and the player's server state is changed accordingly. This results in a situation where the client thinks the player is sprinting and the server thinks they are not.
One effect of this is that knockback distance is reduced, since that is calculated on the server. From the player's perspective, their first hit while sprinting will cause much more knockback than all following hits, until they restart their sprint. This is counter-intuitive, since the sprint could go on for any length of time, reducing knockback for no apparent reason, whereas restarting the sprint will instantly allow the extra knockback.
Any fix for this will change gameplay noticeably. Preserving the client behavior and fixing the server to stay in sync will make sprint knockback much more powerful. Changing the client to match the server means that sprinting will be interrupted when attacking, which players may consider regressive.
Some possible compromises:
- Fix the server to match the client, but reduce the sprint knockback bonus in general, to balance it out
- Fix the server, and add a timed cooldown between sprint knockbacks
- Fix the server, but use other factors to reduce knockback, such as the target's velocity and sprinting state
If the player is holding the sprint key and attacks something (like a mob or other player), this will not interrupt their sprint, as it does with a double-tap sprint. However, the server assumes that this does interrupt the sprint, and the player's server state is changed accordingly. This results in a situation where the client thinks the player is sprinting and the server thinks they are not.
One effect of this is that knockback distance is reduced, since that is calculated on the server. From the player's perspective, their first hit while sprinting will cause much more knockback than all following hits, until they restart their sprint. This is counter-intuitive, since the sprint could go on for any length of time, reducing knockback for no apparent reason, whereas restarting the sprint will instantly allow the extra knockback.
Here is a video demonstration of the bug:
https://www.youtube.com/watch?v=kp4h0O_YKYw#t=9m50s
Any fix for this will change gameplay noticeably. Preserving the client behavior and fixing the server to stay in sync will make sprint knockback much more powerful. Changing the client to match the server means that sprinting will be interrupted when attacking, which players may consider regressive.Some possible compromises:
- Fix the server to match the client, but reduce the sprint knockback bonus in general, to balance it out
- Fix the server, and add a timed cooldown between sprint knockbacks
- Fix the server, but use other factors to reduce knockback, such as the target's velocity and sprinting state
If the player is holding the sprint key and attacks something (like a mob or other player), this will not interrupt their sprint, as it does with a double-tap sprint. However, the server assumes that this does interrupt the sprint, and the player's server state is changed accordingly. This results in a situation where the client thinks the player is sprinting and the server thinks they are not.
One effect of this is that knockback distance is reduced, since that is calculated on the server. From the player's perspective, their first hit while sprinting will cause much more knockback than all following hits, until they restart their sprint. This is counter-intuitive, since the sprint could go on for any length of time, reducing knockback for no apparent reason, whereas restarting the sprint will instantly allow the extra knockback.
Here is a video demonstration of the bug:
https://www.youtube.com/watch?v=kp4h0O_YKYw#t=9m50s
Any fix for this will change gameplay noticeably. Preserving the client behavior and fixing the server to stay in sync will make sprint knockback much more powerful. Changing the client to match the server means that sprinting will be interrupted when attacking, which players may consider regressive.Some possible compromises:
- Fix the server to match the client, but reduce the sprint knockback bonus in general, to balance it out
- Fix the server, and add a timed cooldown between sprint knockbacks
- Fix the server, but use other factors to reduce knockback, such as the target's velocity and sprinting state
If the player is holding the sprint key and attacks something (like a mob or other player), this will not interrupt their sprint, as it does with a double-tap sprint. However, the server assumes that this does interrupt the sprint, and the player's server state is changed accordingly. This results in a situation where the client thinks the player is sprinting and the server thinks they are not.
One effect of this is that knockback distance is reduced, since that is calculated on the server. From the player's perspective, their first hit while sprinting will cause much more knockback than all following hits, until they restart their sprint. This is counter-intuitive, since the sprint could go on for any length of time, reducing knockback for no apparent reason, whereas restarting the sprint will instantly allow the extra knockback.
Here is a video demonstration of the bug:
https://www.youtube.com/watch?v=kp4h0O_YKYw#t=9m50sAny fix for this will change gameplay noticeably. Preserving the client behavior and fixing the server to stay in sync will make sprint knockback much more powerful. Changing the client to match the server means that sprinting will be interrupted when attacking, which players may consider regressive.
Some possible compromises:
- Fix the server to match the client, but reduce the sprint knockback bonus in general, to balance it out
- Fix the server, and add a timed cooldown between sprint knockbacks
- Fix the server, but use other factors to reduce knockback, such as the target's velocity and sprinting state
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
relates to
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
relates to
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
Normal![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
is duplicated by
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
is duplicated by
relates to
is duplicated by
relates to
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
is duplicated by
Can confirm in 1.20.2
Reply from [Mod] turbo:
Please only comment on new affected versions; don't comment if the version you are confirming in has already been added. This creates unnecessary spam. (delete entire comment after reading)
Can confirm in 1.20.1
Reply from [Mod] turbo:
Please only comment on new affected versions; don't comment if the version you are confirming in has already been added. This creates unnecessary spam. (delete entire comment after reading)
is duplicated by
The Bug:
Players can get stuck in their position and constantly jitter when attempting to swim through small spaces after having previously attacked an entity while swimming.
This is a direct product of MC-69459. Because the server thinks that the player is no longer sprinting after hitting an entity, the player cannot swim through small spaces causing them to constantly jitter.
Steps to Reproduce:
- Assemble the appropriate setup by using the commands provided below.
/fill ~1 ~ ~1 ~17 ~4 ~17 minecraft:glass
/fill ~2 ~ ~2 ~16 ~4 ~16 minecraft:water
/fill ~2 ~2 ~9 ~16 ~2 ~9 minecraft:stone
/summon minecraft:armor_stand ~9 ~2 ~5 {NoGravity:1b} - Enter the water and begin swimming while continuously holding down the sprint key.
- Attack the armor stand and then attempt to swim under the line of stone blocks.
- Take note as to whether or not players can get stuck in their position and constantly jitter when attempting to swim through small spaces after having previously attacked an entity while swimming.
Observed Behavior:
Players can get stuck in their position and constantly jitter.
Expected Behavior:
Players would not get stuck in their position and constantly jitter.
The bug
If you hit an entity while swimming underwater, the player will stop swimming for a brief moment (it changes the size of its hitbox and returns to the swimming one) and then get stuck in the middle of the water if they try to swim below a block (the player gets stuck when their large hitbox collides with a block, even if they are using a different size hitbox).
How to Reproduce:
- Go to an aquifer (flooded cave)
- Underwater, spawn an entity:
/summon minecraft:drowned ~ ~ ~ {NoAI:1b,NoGravity:1b,PersistenceRequired:1b}
- Swim holding W + Ctrl (don't release these keys)
- Hit the entity (you will see that it stops swimming for a moment)
- Try to reach the ceiling of the cave.
You will get stuck a block away from the ceiling.
If you stop swimming, it will work normally again.
You can also reproduce this in third person with the hitboxes turned on (F3 + b), and you will see the quick hitbox change that it does when hitting the entity. Watch Bug with hitboxes on.mp4
to understand this better.
Relates to MC-69459.
Possible side effects of fixing this mentioned in this comment.
The bug can also be triggered when exiting the water in certain circumstances (if there is one block of air between the roof and the water and a block next to where the player comes out) and can cause damage to the player when colliding with a block. (Damaged when exiting the water.mp4)
*Moved to MC-234665
**Now on MC-233582
Can confirm in 1.19.2. This behavior is the result of desynchronization between the client and the server. This ticket closely relates to MC-69459.
Hi there; thanks for the report. This ticket is a duplicate of MC-69459. Here's a little bit of context as to why this behavior is occurring.
Basically, when a player attacks an entity while sprinting, a desync occurs. Client-side the player continues to sprint, but server-side, the player stops sprinting and is instead registered as walking. Since walking doesn't cause food exhaustion, when the player hits an entity while sprinting, the server registers you as walking, therefore causing you to not lose hunger.
Thank you for your report!
We're tracking this issue in MC-69459, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
This is a direct product of MC-69459. I've updated this ticket accordingly to accurately reflect the problem here. Basically, because the server thinks that the player is no longer sprinting after hitting an entity, the player cannot swim through small spaces causing them to constantly jitter. Fixing MC-69459 would fix this issue (MC-128846).
This ticket also relates to MC-129568.
EDIT: Nevermind. This is a duplicate of MC-220390.
This is a direct product of MC-69459. Basically, because the server thinks that the player is no longer sprinting after hitting an entity, the player cannot swim through small spaces or under blocks causing them to constantly jitter. Fixing MC-69459 would very likely also fix this issue (MC-220390).
This ticket also relates to MC-129568.
Fixing MC-69459 messes with PvP, I suspect this is why it has not been fixed. I'm sure this swimming bug could be fixed without breaking the behavior for sprinting.
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
Thank you for your report!
We're actually already tracking this issue in MC-69459, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote or any additional information to the main ticket it would be appreciated.
Please be sure to use the search feature before creating a ticket to see if the issue has already been reported.
Quick Links:
📓 Bug Tracker Guidelines – 🛠 Community Support – 📧 Mojang Support – ✍️ Feedback and Suggestions – 💬 Mojira Discord
Duplicate of MC-69459.
Thank you for your report!
We're tracking this issue in MC-69459, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical issues) – 📧 Microsoft Support (Account issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
This is actually a duplicate of MC-69459 and is caused by the said desync.
I would like to reiterate that the fixing of MC-69459 to fix this bug would negatively effect PvP in a substantial way. The desync allows doing critical hits while sprinting by continuing to hold ctrl after connecting a sprint-knockback attack. This is a massive part of PvP and adds a lot of depth, removing the desync entirely would be a terrible change. The side effects of the desync, such as this bug, should really be the only things fixed.
I noticed this a while back and always complained about it. People told me that this is how it was supposed to me, but people would abuse it by constantly restarting their sprint to knock me back far. I made a video demonstrating it as well. https://www.youtube.com/watch?v=6sqF73mA33Y
Confirmed in 1.8. Also affects singleplayer.
Confirmed in 1.8.1 (also in SSP as above).
Also affects 1.8.2-pre1.
Is this still an issue in the current Minecraft Snapshot 15w47c or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Yes, still an issue in 1.9.2
Confirmed for 1.13.1.
Confirmed for 1.14.3-pre1.
confirmed for 1.15 and 1.15.1
Confirmed in 1.16.1.
I personally think this should be fixed while also retaining the "feature" it brought, basically making it so only the first hit in a "sprint hit chain" deals the sprinting knockback while all the ones after that only deal default knockback until you reset your sprint (un- and then resprinting). The reason I am recommending this fix is that sprint-resetting in order to continuously deal more knockback is a wide-spread PvP combat mechanic.
I agree with Jonas. Since this bug has been reopened, I think the client-server desync should be fixed WITHOUT deleting the sprint resetting feature. Sprint resetting such as W-tap, s-tap, sprint-blockhitting are very hard and useful mechanic in both 1.8, 1.9 and CT pvp, so it should be kept. It adds a bit of skill, and is very intuitive.
Can confirm in 1.19.1.
I would like to request ownership of this ticket as the current reporter has been inactive since 2016.
Can confirm in 1.19.2.
Would like to add that this bug also affects how hunger is consumed: see https://www.youtube.com/watch?v=NiOMVtrkV-M
as well as how swimming works, see MC-220390. Probably related to MC-220390 as well.
This is an important component in PvP, as doing it allows you to do critical hits while sprinting. This should not be fixed.
[~PotoledseaSea40], it's purely Mojang's decision on whether something is intentional or not. With this issue, critical hits while sprinting are only possible because of this bug, which is of course occurring due to a desync between the client and server. Besides, this ticket has already been assigned a Mojang Priority, therefore Mojang considers this to be a valid issue.
Jeb already asked about this during the development of the combat tests, ie: "should the sprint reset be kept for the combat tests?". And universally the answer was yes, because without this, sprint-knockback becomes overpowered and overcentralizing, and it removes crit chains.
I would like to reiterate that the fixing of this bug to fix MC-220390 would negatively effect PvP in a substantial way. The desync allows doing critical hits while sprinting by continuing to hold ctrl after connecting a sprint-knockback attack. This is a massive part of PvP and adds a lot of depth, removing the desync entirely would be a terrible change. The side effects of the desync, such as MC-220390, should really be the only things fixed. Alternatively, the ability to do critical hits while sprinting by continuing to hold ctrl after connecting a sprint-knockback attack should be coded in more intentionally. I cannot stress enough how important this is to PvP.
You do know that fixing a desync can fix it both ways, right? They can chose that the server side is correct, or that the client side is. Either way, it being desynced is straight up wrong.