[ccoventry]

Release note: New: with cl_xhair_style 0 and cl_dynamic_xhair 1, a POV demo's red crosshair now opens while the player runs and closes when he stops, as it did when he played.

Follows #1187 (#308). No issue to close.

Why a POV demo's crosshair never moved

Checked in client.dll (both installs, byte-identical), not taken from #1187. The gap function client+0x2cfb0 has three inputs:

input	read from	in a POV demo
weapon	the HUD's current weapon (client+0x223b0), set by the CurWeapon message	recorded: works
deployed	g_iUser3 == 2 (client+0xe88dc) or the sandbag flag (client+0xea46c), both written at client+0x311bc / +0x311d9 from the player's entity state	recorded: works
speed	the length of the vector at client+0x1080f8	stale: its only writer in .text is client+0x12656, inside HUD_WeaponsPostThink (client+0x12360), which copies the predicted player's velocity in. Prediction does not run in demo playback, so it stays at whatever it was (zero in a fresh game)

So only the speed term was missing, which is what #1187 saw (5 px over the whole rush).

What changes

• Commit 1, move only: the red crosshair's gap call (client+0x2cda9), the scans that find it and the hook that answers it move out of spectator_crosshair_gap.rs into a new crosshair_gap.rs, so a second answer can share them. The spectator's table, arithmetic and speed stay in spectator_crosshair_gap.rs (ready() reads the table before spectator_crosshair routes the red draw, as the scan did before). No behaviour change; git diff --color-moved shows it.
• Commit 2, the feature: pov_crosshair_gap.rs. While a POV demo plays (pov_demo_playing: playing back and not an HLTV demo), crosshair_gap points the gap call at its hook; in the demo's own view (g_iUser1 0) the hook puts the view's velocity into client+0x1080f8 for one call of the game's own gap function and puts the old value back after it. The velocity is ref_params_s.simvel as the engine hands it to V_CalcRefdef for the main view (now pub in engine.rs), kept in three atomics; the hook reads atomics only. Everything else is the game's code: cl_dynamic_xhair, the fixed 4 px for grenades and rockets, the weapon table, the 3D speed, the 3 px a frame easing and the x87 precision.
• ds_debug_status gets a POV demo red crosshair: gap N px, the recorder at N u/s line while a POV demo plays.
• tools/verify_spectator_crosshair_offsets.py reads both Rust files and gains check 12: VELOCITY_AT is the vector the spread function pushes for its length call, exactly one writer stores its x, y, z (client+0x12656), and every other use only pushes it. All checks pass on PRE and POST.
• Docs: docs/goldsrc_crosshair.md §2 (the POV paragraph rewritten), docs/dodstudio_commands.md ("Stock settings the hook extends": cl_dynamic_xhair), lib.rs module list.

Decisions

• No new cvar. The player's choice is the stock cl_dynamic_xhair, which the game's function still reads (0 keeps the fixed 4 px, measured).
• The game's own function, not a second copy of HLTV first-person view draws POV's red crosshair, its gap following the watched player (#308) #1187's. In POV the client has the weapon and the deploy state itself; only the velocity is missing, so the hook supplies that one input and runs the original. HLTV first-person view draws POV's red crosshair, its gap following the watched player (#308) #1187's code is reused where it applies (the call site, the scans, the hook); its arithmetic stays the spectator's, where the inputs really do differ.
• The velocity is the recorded simvel, the predicted velocity the recorder's crosshair read live (and the one his view bob moves with). Measured in wsod25_grp2_h1_warchyld (PRE, a temporary log in a probe build, not committed): on 1,290 of the 1,371 frames whose simorg sat exactly on a recorded frame's, simvel was that frame's recorded value to 0.02 u/s; the other frames are between recorded ones, where the engine interpolates. 3D, as the game's: a fall widens it too (the HLTV side stays horizontal, HLTV first-person view draws POV's red crosshair, its gap following the watched player (#308) #1187).
• The slot is put back after the call, so the two other readers of client+0x1080f8 see what they saw before, and the change is confined to the crosshair.
• Only while a POV demo plays is the call redirected; live play keeps the game's bytes, and HLTV demos go through HLTV first-person view draws POV's red crosshair, its gap following the watched player (#308) #1187's path unchanged.
• A POV recorder who is dead and watching a teammate gets the game's spectator dot, which never asks for a gap: unchanged.
• Writes to the call go through patch::write_code_bytes; the two users' wishes are two atomics, so spectator_crosshair turning its side off in a POV demo no longer fights the POV side.

Test done

In-game, Brain account, game_probe.py (game behind, game_lock), this branch's release DLL (local\test-povxhair\dodstudio_goldsrc_hooks.dll) against a dev build of 1369693 (local\test-povxhair\dev-13696938\), cl_xhair_style 0, cl_dynamic_xhair 1, clips recorded by HLAE at 5 fps (a frame is 0.2 s of demo time), each frame scanned for the right arm's distance from the centre (±1 px; a 4 px gap reads 4-5).

• PRE, wsod25_grp2_h1_warchyld (K43) from 13:27:35 on the viewdemo bar, 389 frames: dev 4-6 px on every frame; this branch 5 at rest, 25-26 running (157 frames), easing 3 px a frame between, 4 on a stick grenade. cl_dynamic_xhair 0: 4-5 px in both builds.
• POST, same demo through the ../ path, 370 frames: the same (dev 4-6; this branch 5 / 25-26 / grenade 4; cl_dynamic_xhair 0 4-5).
• Same moment, HLTV (wsod25_grp2_h1_hltv from 13:26:00, in-eye on warchyld, ds_spec_match_pov 1), POV vs HLTV frame by frame (frames matched by picture, the crosshair left out): this branch within 3 px of HLTV on 213 of 252 frames (PRE) and 232 of 265 (POST); dev on 111 of 252 and 113 of 263. The misses are the ease-in/ease-out frames a few frames apart and the frames HLTV's Spectator crosshair follows POV's rules (weapon switch, airborne, sprint, prone transitions, snipers, melee, undeployed MG, reload) #310 rule hides that the POV demo shows (pre-existing).
• HLTV, this branch vs dev: the same gaps (rest 4-5, running 25-26) on both builds: the move changed nothing there.
• Three other recorders and matches, both installs: ktps8w11sf-gorilla_gskill_m2_armory_h2 (Gorilla, BAR) from 5:15:00: 7-8 at rest, 27-28 running; ktps8w10qf-element_soul_m1_saints_h2 (element, Garand and a K98) from 8:14:00: 25 running with the Garand, 34 with the K98, 4 on a grenade; ktps8w5-db_thunder_thunder2_h2 (deeebeee, MP40) from 7:56:00: 27-28 running. All as the weapon table says.
• Review images and video (POV before | POV after | HLTV, stopwatch in demo seconds): local\review-images\povxhair\ (pre_pov_before_after_hltv.mp4, _0.25x, post_*, *_running_*.png, *_resting_*.png, *_grenade_*.png, per-frame gaps in *_gaps.tsv).
• The runs above used the build of 75fcc9f; the last commit only adds the hook-log lines when the call is redirected and put back. Re-run with the head's DLL on PRE, the same warchyld moment: the log line appeared, ds_debug_status printed the POV demo red crosshair: line, and the gaps were the same (5 rest, 25-26 running, 4 on the grenade).
• cargo test -p goldsrc-hooks --target i686-pc-windows-msvc: 1110 passed. Clippy clean on i686 and host (1.98.1), fmt clean. Commit 1 alone also builds, passes the tests (1108) and the offsets check.
• Not tested: a deployed bipod or MG in a POV demo (the stretches recorded had none; the deploy term is the game's own and unchanged), a rocket.

Needs a look

• The easing is the game's 3 px a frame, so how fast the arms open depends on the frame rate: in these 5 fps clips it takes about 7 frames (1.4 s); at a 60-300 fps capture it is a fraction of that, as live. The HLTV side behaves the same.
• Open PRs touching the same files: Hook DLL: drop the plain-command fallback that never ran (follows #1208) #1230 (commands/poll.rs, engine.rs), R&D: show the overview map in POV demos (part of #897) #906 and R&D: a restyled health readout drawn by the hook (part of #849) #882 (engine.rs, lib.rs). Small, separate hunks; whichever merges second may need a trivial rebase.

🤖 Generated with Claude Code