The vanilla code behind the jump-reset

#01The one idea

Two layers, two questions. The movement code explains why a sprint-jump cancels knockback. The netcode explains when you have to do it.

When you are hit, LivingEntity.knockback sets your new horizontal velocity to oldVelocity / 2 − knockback. It blends, it does not replace. So velocity you already carry toward the attacker is halved and then subtracted from the knockback that pushes you away. A sprint-jump injects a burst of velocity in your look direction — straight at the enemy — so when the blend folds it in, most of the horizontal knockback cancels and you keep your ground. That is the mechanism, and it is entirely in vanilla movement code.

But in multiplayer the hit is resolved on the server, and the result is shipped back to you as a velocity packet that overwrites your local motion. That single fact — overwrite, not blend, applied after a network delay — is why you can jump on time or late but never early: anything you do before the packet lands is discarded by the overwrite, and anything after it survives. The timing window you feel is the shape of that round trip.

#02What the report says

The bug as Mojang records it.

Verbatim: "While sprinting forward, when you press your jump key at the same time when you get attacked, you will take reduced/no horizontal knockback depending on how accurately you time it." Both halves are load-bearing in the code below: it requires sprinting forward (the forward velocity does the cancelling) and it is timing- and ping-dependent (the jump must align with how the hit is registered and sent back).

#03Root cause: knockback blends, it never overwrites

The single line the whole exploit rests on, in LivingEntity.knockback.

// net/minecraft/world/entity/LivingEntity.java  —  knockback$v1_17_0 (1.17 → 26.x)
public void knockback(double strength, double x, double z) {
   strength *= 1.0 - this.getAttributeValue(Attributes.KNOCKBACK_RESISTANCE);
   if (!(strength <= 0.0)) {
      this.needsSync = true;                             // mark velocity dirty → server will sync it
      Vec3 dm = this.getDeltaMovement();                 // your CURRENT velocity
      Vec3 kb = new Vec3(x, 0.0, z).normalize().scale(strength);
      this.setDeltaMovement(
          dm.x / 2.0 - kb.x,                              // horizontal: HALVE old, then subtract knockback
          this.onGround() ? Math.min(0.4, dm.y / 2.0 + strength) : dm.y,
          dm.z / 2.0 - kb.z);                             // same on Z
   }
}

The horizontal result is not −kb; it is dm/2 − kb. Your pre-hit velocity is a first-class input to the knockback you receive. If dm.x points toward the attacker (the negative of the knockback direction), it cancels into kb.x and the magnitude collapses. The faster you are already moving into the hit, the less knockback you take. Note the needsSync = true: this same call flags your velocity dirty, which is what later sends it across the wire in §6.

#04The lever: a sprint-jump injects velocity toward the attacker

Jumping is not only vertical. While sprinting it adds a horizontal burst in your look direction — and in a duel you are looking straight at the enemy.

// LivingEntity.java  —  jumpFromGround()
public void jumpFromGround() {
   float jumpPower = this.getJumpPower();                 // 0.42 at baseline
   if (!(jumpPower <= 1.0E-5F)) {
      Vec3 v = this.getDeltaMovement();
      this.setDeltaMovement(v.x, Math.max(jumpPower, v.y), v.z);
      if (this.isSprinting()) {
         float yaw = this.getYRot() * 0.017453292F;       // degrees → radians
         this.addDeltaMovement(new Vec3(-Mth.sin(yaw) * 0.2, 0.0, Mth.cos(yaw) * 0.2));
      }                                                    // +0.2 in the facing direction
   }
}

The sprint clause adds 0.2 of horizontal speed pointed where you face. Stack it on normal sprint momentum (~0.28/tick) and, on the jump tick, dm toward the attacker peaks near 0.48. Feed that into dm/2 − kb and the subtraction nearly zeroes out. The jump also sets v.y to the jump power, so the vertical survives — hence "you popped up but barely moved back."

#05The local tick: a tight window with no network

In singleplayer there is no packet. The hit and your jump are resolved in the same tick, and the in-tick order is the whole story — which is why the window here is only a tick or two.

For the blend to cancel, your forward velocity has to be present in dm at the instant knockback() runs. With everything local and same-tick, that alignment is narrow — the one-or-two-tick window players describe offline. Multiplayer is where it widens, and where the asymmetry appears.

#06Across the wire: the hit comes back as an overwrite

In PvP the hit is resolved on the server and pushed to you as a velocity packet. How that packet is applied is the hinge of the entire timing model.

Your movement is client-authoritative: every tick your client simulates your player (§5) and reports the resulting position to the server, which trusts it within anti-cheat limits. Knockback is the exception — it originates server-side. The server runs knockback() on its copy of you, the needsSync flag from §3 marks your motion dirty, and the entity tracker sends you a ClientboundSetEntityMotionPacket. When it arrives, your client applies it:

// net/minecraft/world/entity/Entity.java  —  lerpMotion(), invoked by the SetEntityMotion packet
public void lerpMotion(double x, double y, double z) {
   this.setDeltaMovement(x, y, z);   // a hard SET — your current velocity is DISCARDED, not blended
}

That is the crux. The server's blend already happened with the server's view of your velocity; what reaches your client is an absolute value that replaces your local motion wholesale. So there are two distinct moments — the server resolving the hit, and your client overwriting — separated by your latency:

#07Why you can be late but never early

The overwrite plus client authority produce a one-sided window: velocity created before the packet is erased, velocity created after it survives.

The window has a width for two compounding reasons. First, latency shifts the clock: the packet may not reach you until several ticks after the server's hit tick, so "late on the server's clock" is "on time on yours" — more ping, wider window. Second, the knockback decays slowly: airborne friction is ~0.91/tick, so the backward velocity persists for several ticks during which re-adding forward still meaningfully cuts displacement. Past roughly that span the knockback has already moved you and re-jumping stops mattering. A reported ~6-tick ceiling reads as the ping window plus those few still-cancellable ticks.

#08The arithmetic

Plugging illustrative numbers into dm.x/2 − kb.x with a base knockback of 0.4. Positive = toward attacker, negative = pushed back.

Magnitudes are illustrative (base strength 0.4; sprint speed and the +0.2 boost approximate). The trend is the point: the larger your forward velocity when the blend runs, the smaller the surviving knockback.

#091.8.9 vs 1.17+: same root, one modern detail

The blend is ancient, which is why jump-resetting predates the report by a decade.

// 1.8.9  net/minecraft/entity/EntityLivingBase.java  —  knockBack()
this.motionX /= 2.0; this.motionY /= 2.0; this.motionZ /= 2.0;   // same halving
this.motionX -= var3 / var7 * 0.4;                               // same subtract
this.motionY += 0.4;                                            // vertical pop is UNCONDITIONAL
this.motionZ -= var5 / var7 * 0.4;
if (this.motionY > 0.4) this.motionY = 0.4;

1.8.9 halves-and-subtracts exactly like modern, so the horizontal reset works identically. The only difference is vertical: 1.8.9 always adds the 0.4 pop, whereas modern gates it on onGround (this.onGround() ? Math.min(0.4, dm.y/2 + strength) : dm.y). So since 1.17 a hit taken while airborne also skips the upward launch. That is a secondary sweetener; the shared, load-bearing cause across every affected version is the horizontal blend.

#10Where a fix would live, and why it is still open

The behavior is two vanilla methods plus the netcode that connects them.

Resolving MC-259487 means changing LivingEntity.knockback (stop blending the victim's own velocity into horizontal knockback, or clamp it), jumpFromGround (don't inject horizontal velocity that can oppose a simultaneous hit), or how knockback is reconciled between server and client (the overwrite is what hands players the late window). All three are core systems Mojang owns. The ticket sits at Open / Community Consensus because the behavior is load-bearing competitive tech: any of those changes alters how every PvP hit feels, so it is a balance decision as much as a code one.

#Where to look

Sources: Mojira MC-259487 (description + comments, bugs.mojang.com API) · decompiled Minecraft — LivingEntity.java & Entity.java (modern, mojmap), EntityLivingBase.java (1.8.9, MCP) · Minecraft Wiki, Knockback (mechanic). Server packet timing reasoned from architecture; velocity magnitudes illustrative.