hl2h/CONTEXT.md, branch master

Items: server ammo counts and frag-grenade type

2026-11-05T19:32:59Z

- local_ammo now prefers the authoritative server m_iAmmo array (header skip) and only falls back to the client netvar array. The client offset can be off by an element, which made "full" checks flicker as other ammo was spent. - Frag grenade pickups were falling through to a generic "Ammo" label with ammo_type=-1, so the usable filter never ran. w_grenade/w_frag/ items/grenade/frag_grenade are now "Frag grenade" and map to m_iAmmo[11] (sk_max_grenade, stock 5); AR2/SMG1 grenade variants map to m_iAmmo[8].

Items: keep health chargers visible, add charger diagnostics

2026-11-05T17:09:43Z

The health charger's candidate m_iJuice offset (0x3c8) read 0 on a full charger, so the empty-hide made health chargers disappear entirely. Restrict the hide to suit chargers (verified 0x47c) until the health offset is confirmed; health chargers stay visible. Classify with the server class name when the client class is generic, accept `healthcharger` in the health branch (maps use item_healthcharger / CNewWallHealth, not the func_healthcharger brush), and log up to eight `juice:` lines with the class and both candidate offsets/values.

Grenade trajectory: actual grenade state, full-length path, rounder rings

2026-11-04T22:46:58Z

- Prefer the local player's thrown frag over the pre-throw estimate: resolve CBaseGrenade::m_hThrower from the server datamap (client owner handles as fallback), then seed the prediction from the live origin/velocity. The real frag is a spinning VPhysics box with a random Y angular impulse, so bounce points remain approximate; the doc now says so. - Keep 512 path points sampled every other 20 ms step (up to 24 s) instead of 127 points / ~2.5 s, so the line reaches the landing instead of stopping in mid-air. - Radius rings use 36 segments; a segment whose near-plane-clipped endpoint the engine overlay refuses falls back to the local projection, and that projection now uses the configured camera FOV instead of a hardcoded 75 degrees (the wide-FOV ring no longer kinks/drops pieces).

Charger juice: resolve per-class offsets

2026-11-04T22:32:00Z

CWallHealth derives CBaseToggle and CNewRecharge derives CBaseAnimating, so m_iJuice is at different offsets (0x3c8 and 0x47c here). Collect every m_iJuice datamap match, derive the suit offset from m_iMaxJuice-20, and pick by the server class name. Also detect health brushes via wallhealth/recharge rather than the ESP label. Verified the offsets resolve distinctly on :99.

Add grenade trajectory, RPG armour priority, empty chargers, mega gravity gun

2026-11-04T22:26:53Z

- Projectiles gets a "Grenade trajectory" toggle. While a frag grenade is held, simulate the weapon_frag throw (1200 u/s forward + 120 z, player velocity, gravity 600) and trace each step with a new trace_solid_segment(); reflect on impact, stop on a slow upward-normal hit, and draw the path, landing cross and a 300-unit blast ring. Verified on :99 (arcs, bounces off the tunnel wall, lands). - With the RPG equipped, armoured NPCs (striders, gunships, dropships, hunter-choppers) sort before normal enemies during target acquisition. Added helicopter/chopper to the ARMORED model list. - Empty health/suit chargers are hidden: read m_iJuice from the server datamap (0 = depleted, -1 = unreadable/fail open). - The citadel supercharged gravity gun (d3_citadel_03, d3_citadel_04, d3_breen_01 via IVEngineClient::GetLevelName) is treated as a normal weapon, so the melee aimbot no longer restricts it to VULNERABLE NPCs.

Chams: working alpha via RenderView blend and a custom VMT

2026-11-04T21:09:14Z

Testing on :99 showed the material $alpha path is a dead end: UnlitGeneric takes translucency from the base texture/vertex alpha, and the debug materials have neither. Follow Amalgam: apply alpha with IVRenderView::SetBlend (VEngineRenderView014 slot 4) around the model draw, saving/restoring it. To have something translucent to blend, write a tiny UnlitGeneric VMT with $model 1 + $translucent 1 + a white base texture to //materials/hl2hake/translucent.vmt (plus a custom/ copy). It is written by a preload constructor so it exists before the material system scans its search paths, then loaded once with FindMaterial. Styles 0/3/4/6 use it when the colour alpha is below 255. Also: - Visible wireframe + through-wall: fill the visible silhouette first so the through-wall pass cannot show in the wireframe gaps, then draw a brightened contour. Style 6 is now "Solid + contour" (recolour + visible edges). - find_modules builds local snapshots and publishes them under a mutex; the setup thread and the server retry could reset the shared vectors live and crash at startup. Verified on :99: Solid + alpha 64 renders a see-through viewmodel, Solid + contour shows a blue fill with bright blue contours, Additive is a translucent coloured glow and Fullbright is a white additive glow.

Chams: real additive material, addref cached materials

2026-11-04T20:35:44Z

Testing on :99 showed ADDITIVE on debugtranslucentsinglecolor did nothing and alpha lost the colour, because that VMT has no $translucent and the engine bound an unreferenced material. Use debug/debugtranslucentmodelhulls (VMT has $additive 1 + $color) for Additive/Fullbright, and addref every preloaded material so the engine stops warning "bad reference count 0" and applies $color/ColorModulate. Verified: Solid is flat blue, Additive is a translucent coloured glow, Fullbright is a white additive glow, White is opaque white. Also drop the viewmodel additive base (the solid material is opaque, so it made an opaque blob) and never call FindMaterial inside DrawModelExecute. Document that the alpha control is stored but has no effect until a custom $translucent model VMT is added.

Chams: make Fullbright a white-hot additive glow

2026-11-04T18:39:27Z

Fullbright was additive with the chosen colour lifted only 25% toward white, which on a dark scene looked almost identical to Solid/Flat. Force white for the Fullbright colour so the additive pass reads as a distinctly brighter, white-hot glow; the faint translucent base still gives it a silhouette on bright backgrounds.

Chams: per-colour alpha and a softer viewmodel additive base

2026-11-04T18:36:24Z

- Colour picker gains an optional alpha bar (checkerboard preview, #RRGGBBAA readout); add_color_alpha is used for the chams colours. Chams colours are now r,g,b,a and chams_apply sets $alpha plus MATERIAL_VAR_TRANSLUCENT when alpha < 255. Config stores vis_a / inv_a / vm a. - The additive viewmodel base is now a faint translucent tint (alpha/8) instead of an opaque fill, so additive/Fullbright stay see-through and the viewmodel no longer becomes a solid blob. Fullbright whitening reduced to 25% so blue stays blue instead of turning lavender.

Chams: keep additive viewmodel visible on bright backgrounds

2026-11-04T18:17:12Z

Viewmodels are collated as RENDER_GROUP_VIEW_MODEL_OPAQUE, so an additive forced material can vanish against a bright sky/wall (additive adds nothing to an already-bright surface). Draw a dim opaque solid base before the additive viewmodel pass so the first-person model always has a visible silhouette; the additive layer still provides the glow.