Why did my projectile pass straight through an enemy?

Most often tunneling: the projectile body moved far enough in one physics step to skip over a thin collider, so no hit check ever ran inside the target. Capture the trajectory samples, step size, and target bounds to see the jump, then switch to continuous collision or smaller steps.

How do I reproduce a shot when spread is randomized?

Store the rolled spread offset or the random seed that produced it on each shot. Randomized patterns are unrepeatable otherwise, so without the recorded roll your test fires a different pattern every time and the reported miss can never be recreated.

Why do shots hit on my screen but miss on the server?

Travel time plus latency widens the gap between the client-rendered target position and the authoritative position used for registration. Capture both positions, the resolved hit point, and round-trip latency so the desync is a measurable value you can tune lag compensation against.

Bug Reporting for Games With Ranged Combat

Quick answer: Ranged bugs are about a projectile's life: where it spawned, the aim and spread that launched it, how it traveled, and where hit registration ran. Capture the firing parameters, the trajectory samples, the collider it reported, and the target position at impact so a shot that missed or passed through can be reconstructed instead of guessed at.

Ranged combat adds travel time and physics to the aiming problem. A bullet or arrow is spawned at an origin, given a velocity shaped by spread and recoil, and then it lives across several frames before something decides whether it hit. Between launch and impact the target moves, the world streams, and any number of edge cases can swallow the shot. When a player reports a projectile that passed through an enemy or vanished, they are describing one trajectory among thousands. This post is about capturing the projectile and registration state that makes that one shot reproducible.

A projectile has a life, and bugs hide in it

Unlike a melee swing, a ranged shot exists over time. It spawns with an origin, direction, and speed; it may be a physics body, a stepped raycast, or a hitscan resolved instantly. Along the way it can be affected by gravity, drag, penetration rules, and damage falloff. Each of these stages is a place a bug can hide. A projectile that tunnels through a thin target between collision checks, or one whose origin is offset from the camera so it clips a wall the player never saw, both read to the player as simply not working.

The trouble is that the projectile is gone the moment it resolves, and your logs rarely capture its path. A player can tell you the arrow went through the dragon, but not the sub-steps the physics took or the frame the collision check ran. Reproducing it by re-aiming is hopeless because you cannot recreate the exact origin, spread roll, and target motion. The trajectory itself, sampled and saved, is the evidence you are missing.

Firing parameters and the spread roll

Start by capturing the launch state. Record the projectile's origin, the aim direction after smoothing and aim assist, the spread or recoil offset actually applied that shot, and the initial velocity. Spread is usually randomized, so a single shot is unrepeatable unless you store the rolled offset or the seed that produced it. Without that, a player's missed shot with a shotgun or a bursty rifle can never be reproduced, because your next test will roll a different pattern entirely.

Also capture the weapon configuration in effect: fire mode, current recoil accumulation, any charge level, and the penetration and falloff settings. Many ranged complaints are really tuning surprises, a shot that did reduced damage at range, or that failed to penetrate a surface it looked like it should. With the falloff curve value and penetration result recorded, you can immediately tell whether the system behaved as designed or genuinely misfired, instead of relitigating it by feel.

Hit registration and tunneling

The most reported ranged bug is the shot that should have connected but did not. For physics projectiles, the prime suspect is tunneling: the body moved far enough in one step that it skipped over a thin collider. Catching this requires the trajectory samples, the step size, and the target's bounds, so you can see the projectile jump from in front of the target to behind it without a check in between. The fix, continuous collision or smaller steps, is obvious once the gap is visible and invisible until then.

Networked shooters add the registration layer on top. The client may show a clean hit while the server adjudicates against a different position, exactly as in pure aiming bugs but now with travel time multiplying the divergence. Capture the client target position, the authoritative position at the resolved time, the projectile's resolved hit point, and latency. When those sit together you can measure the desync directly and tune your lag compensation, rather than fielding endless reports about shots that hit on screen and missed on the scoreboard.

Replaying a shot from captured state

Given the origin, direction, spread offset, velocity, and weapon settings, you can respawn the exact projectile in a test scene and watch it fly. Feed in the recorded target positions over time and you reproduce the encounter frame for frame. If the projectile tunnels again, you have the bug isolated and a fix to verify against. If it connects cleanly, the captured state usually reveals what differed, often a frame-rate-dependent step size or a collision layer that was set wrong only in the live build.

These saved shots are durable regression fixtures. Projectile behavior is sensitive to physics timestep, collision layers, and step counts, all of which drift as a project grows. Re-running real reported trajectories after each change tells you instantly if you reintroduced tunneling or shifted a falloff threshold. It is far cheaper to catch a registration regression against a saved shot than to wait for players to notice their bullets stopped landing.

Setting it up with Bugnet

Bugnet's report button captures game state automatically, so a ranged report carries the projectile's whole life. When a player reports a shot that passed through a target, you attach the origin, aim direction, spread offset, velocity, weapon settings, trajectory samples, the collider the hit test reported, and the target position at impact as custom fields. The player describes the moment in a sentence while Bugnet preserves the numbers that let you respawn and replay the projectile, instead of trusting a recollection of something that crossed the screen in a fraction of a second.

Because Bugnet groups duplicate reports into one issue with an occurrence count, a tunneling bug that affects many players appears as a single high-count issue you can prioritize, not a scattered mess. Filter by custom fields like weapon, range bucket, or latency to find the pattern, and any crash during a firefight arrives with a stack trace and device context. The firing parameters, the trajectories, the duplicates, and the crashes all live in one dashboard you can sort by how many players a given bug actually hit.

Designing ranged combat to be debuggable

The practical move is to make every projectile self-documenting. Keep a short buffer of recent shots with their launch parameters and sampled paths so a player reporting a moment ago can attach the exact trajectory. Store the spread seed or rolled offset rather than hoping randomness repeats. Capture both client and authoritative positions in networked play. None of this is visible to players, but all of it is what turns a vague report into a replayable shot.

When you can replay any reported shot, ranged balance and ranged bugs stop blurring together. You answer questions about damage, penetration, and registration with recorded numbers instead of opinions, and you catch tunneling and desync regressions before they ship. Build the capture while your weapons are still evolving, and your ranged combat will improve on evidence rather than on the loudest complaint in your community channel.

Ranged bugs hide in a projectile's life. Capture the launch parameters, the sampled path, and the registration result and any lost shot becomes a shot you can replay.