Tickrate transition impact on projectile trajectory and movement precision

Direct Answer

1. The Source Engine does not automatically rescale physics when the tickrate changes; a projectile’s position is updated once per tick using the current tick delta, so moving from 64 Hz to 128 Hz doubles the sampling frequency and can alter the exact trajectory.

2. When the server runs at a higher tickrate than the client’s local prediction rate, the client still predicts at its own rate (usually 64 Hz) and then interpolates between the received server states. This yields smoother visual motion but does not change the underlying hit‑registration logic.

Confirmed Facts

• The server tickrate is set with sv_tickrate and is honoured by all physics, movement, and lag‑compensation modules.
• Projectile simulation occurs once per tick; the new position is position += velocity * (1 / tickrate).
• Client prediction uses a fixed 64‑Hz rate for most Source titles; if the server runs at 128 Hz, the client predicts at 64 Hz and interpolates between the received states.
• Hit‑detection tolerance (e.g., sv_maxunlag, sv_clienttrace) is applied per tick, so a higher tickrate reduces the chance of a projectile “skipping” a target between updates.

Likely Explanation (not guaranteed)

Because the engine does not perform cross‑tickrate scaling, the same input sequence will produce slightly different spatial results when the tickrate changes. This is most noticeable for high‑velocity projectiles or rapid movement, where the per‑tick displacement changes. Players may observe a shift in hit registration or recoil behaviour when moving between servers of different tickrates.

Practical Steps for Your Server

1. Check the current tickrate: open the server console and run sv_tickrate.
2. If you rely on precise projectile timing (e.g., sniper rifles), consider scaling the projectile speed or hit‑box tolerance in the weapon script (weapons.txt or scripts/) to compensate for the tickrate change.
3. Test hit registration: fire a projectile at a stationary target on both 64 Hz and 128 Hz servers, record hit/miss counts, and compare.
4. Verify interpolation behaviour: on a client, enable cl_interp_ratio and cl_interp to see how the interpolation buffer changes with higher server tickrates.
5. Document any noticeable differences and adjust server settings or client configurations accordingly.

Missing Diagnostic Detail?

If you notice inconsistent hit registration after the tickrate change, the next data point that could clarify the issue is the client’s cl_interp_ratio value. Knowing whether the client is set to the default 1.0 or a higher ratio will help determine how much interpolation is applied and whether it is contributing to the perceived discrepancy.