Hitbox False Positives From Combat Packet History

What caused the hitbox false positives?

Per FairPlay engineering notes dated 2026-10-19, some attacks were judged against the wrong attacker position. Prior rotations were dropped too early, yaw and position came from separate lookups, and reach re-sampled movement after the attack arrived. The reported false positive during rapid up and down aiming was not reproduced on a deployed server. The fix keeps one attack-time snapshot and only allows corrections that pass more attacks.

The notes describe the earlier false fails as a missing-compensation symptom rather than proof that a block intersection was wrong.

Why did the attacker position disagree?

• Two clocks. Prior-rotation eligibility was measured from the movement packet, but the later check measured from the attack. A rotation that fell in the gap between the two clocks was dropped before the check saw it. The fix keeps the existing age and tick-distance limits, so what counts as a prior rotation is no looser than before.
• Non-atomic lookup. The yaw and pitch came from one history lookup, while the feet position came from a separate time resolver. Under bursts of movement packets, the resolver could return nothing even when the exact movement was still in history.
• Two bases. Occlusion used the frozen attack snapshot. Reach rebuilt its attacker pose from movement that arrived after the attack, so the two checks could compute different positions for the same swing.

How does the fix avoid stricter validation?

The fix only adds passes. Reach still evaluates its legacy state first, and a legacy pass stays a pass. Only a legacy fail triggers a second evaluation against the frozen attack pose. If that second evaluation confirms a genuine pass, the final result becomes a pass. Otherwise the original fail stands.

The reach distance limit and target boxes were not raised. Occlusion takes position and rotation from the same movement event, and never mixes a position from one packet with a yaw from another. Unknown or future events do not produce a clear.

What does the regression coverage check?

The regression set covers boundary timing on both sides of the prior-rotation window, a missing resolver neighbor where the exact movement still exists in history, and a resolver that returns a different time than the rotation event. In that last case, the notes require using the rotation event's own position.

Other cases check that a movement packet arriving after the attack does not change the frozen candidate, and that a legacy clear remains a clear. The tests use ordered movement history and real evaluator functions. They do not replay raw packets, and the notes say so directly.

How does this compare with GrimAC's approach?

Per the FairPlay notes' reading of GrimAC's public source, Grim's reach check separates a fast packet-time gate from a later look-aware evaluation, uses client-compensated target boxes, and reasons about packet order. FairPlay adopted the data ownership and ordering principles. It did not adopt an unbounded rewind, expanded hitboxes, or copied code.

This is an architectural difference, not a ranking. Both designs are meant to pass honest hits and fail confirmed violations. The same trade-off applies to any combat check: a rewind is an estimate of where a target was, so it should be trusted to pass a hit, not to convict a player.

What evidence is still missing?

• A raw replay of the serverbound movement and attack sequence. The notes say the regression tests are not a substitute for it.
• A Maven test run with surefire reports. The notes say the inspection environment lacked the dependencies to run it, so the new tests are reviewed rather than passing in a recorded run. Treat the fix as unverified until that run is recorded.
• Opt-in, bounded runtime captures of the attack time, nearby movement timing, pose count, ray contacts, and reach distances from the debug output.
• Do not include full packet payloads or personal data in a report. The notes ask for compact fields only.