Improving Hit Registration on Your Server

August 13, 2025 Daemon666 8 min read 9 преглеждания

"Hitreg feels off" is the most common complaint on a busy CS 1.6 server, and unlike aim it is often genuinely fixable from the server side. GoldSrc uses server-side lag compensation: when a client fires, the server rewinds every other player to where they were on the shooter's screen at the moment of the shot, then tests the bullet against those rewound positions. Get the inputs to that system right and shots land; get them wrong and players empty a magazine into a body for no damage. There is no magic cvar — it is a chain, and every link matters.

1. Confirm lag compensation is on

The rewind system is controlled by a family of cvars. The defaults are usually correct, but verify them:

sv_unlag 1
sv_maxunlag 0.5
sv_unlagpush 0
sv_unlagsamples 1

sv_unlag 1 enables compensation — turning it off is almost always wrong on a public server. sv_maxunlag 0.5 caps how far back (in seconds) the server will rewind, which bounds abuse from very high-latency clients. Leave sv_unlagpush at 0 unless you are chasing a specific edge case; nudging it changes how positions are interpolated and usually makes things worse, not better.

2. Run a stable, high server fps

Lag compensation rewinds to stored position snapshots, and the resolution of those snapshots depends on how often the server ticks. A server juddering between 100 and 400 fps stores irregular history, so the rewind lands between real positions and the hit test misses the edge of a model. A rock-solid ~1000 fps gives dense, evenly spaced history and dramatically tighter registration. This is why a stable 1000 fps matters for hitreg specifically, not just for feel. Confirm it with the fps measurement guide and the console:

stats

3. Kill choke and loss first

Compensation cannot rewind to a snapshot the client never received. If clients are choking or losing packets, their view of enemy positions is stale, the server rewinds to the wrong place, and hits vanish. Eliminate choke with a correct sv_maxupdaterate configuration and watch loss on net_graph. Clean netcode is a precondition for good hitreg, not a separate concern.

4. Get client rates and interpolation right

The server rewinds to the position the shooter saw, and what the shooter saw is set by their interpolation. Advise players toward consistent values:

cl_updaterate 100
cl_cmdrate 100
rate 25000
ex_interp 0.01

An ex_interp that fights the update rate (too high with a high updaterate) makes the client render enemies further in the past than the server expects to rewind, spreading hits. Pair a 100 updaterate with a small interp. The full table is in best client rates.

5. Prefer ReHLDS for consistency

The reverse-engineered ReHLDS engine holds a steadier frame time under load than stock HLDS, and steadier frame time means more uniform lag-compensation history. It is not a hitreg cheat — it will not make a missed shot hit — but it removes a class of jitter-induced misses that plague loaded HLDS servers. The ReHLDS performance cvars let you tune the timing further.

Common errors

  • Hits fine 1v1, bad on full server — server fps collapses under load, so the position history degrades. Fix fps and CPU headroom first.
  • High-ping players seem to "eat" bullets or trade unfairlysv_maxunlag is too high, letting the server rewind very far. Cap it at 0.5.
  • Shots register late / feel delayed — client interpolation too high for the update rate. Lower ex_interp toward 0.01.
  • Everyone's hitreg is bad regardless of ping — choke or loss on the server. Clean the netcode before touching unlag.
  • Disabling sv_unlag to "fix" it — this makes high-ping players need to lead targets and feels far worse for the majority. Leave it on.

Verification

Read the unlag cvars back and confirm fps under load:

sv_unlag
sv_maxunlag
stats

Then test with a partner: have them strafe at a wall corner while you shoot; damage numbers should track their model tightly with net_graph 3 showing zero choke and zero loss on both ends. If registration is tight in that controlled test but poor on a full server, the culprit is fps or CPU under load — work through fps drops with players. Set expectations honestly with your community: good server config removes bad hitreg, it does not turn misses into hits, and no server on earth can compensate for a player's own 150 ms connection to the box. What you can guarantee is that the server never adds error of its own.

Сътрудници: Daemon666 ✦
Сподели: