hud.cpp: byte-ground the HudSimulation constants -- all five were stand-ins under guessed names
Found chasing the Thor "no range finder" report: _DAT_004b7ec4 was documented
as two incompatible things -- the 0.75 LOCK damage threshold (mech4.cpp:6325)
and a "heat threshold for HUD page visibility" valued 0.0f (hud.cpp:59).
The .rdata settles it (reference/decomp/section_dump.txt):
4b7ec0 8be55dc3 0000403f 0000803f 0000c842
4b7ed0 00000000
_DAT_004b7ec4 = 0.75f _DAT_004b7ec8 = 1.0f
_DAT_004b7ecc = 100.0f _DAT_004b7ed0 = 0.0f _DAT_004b7f90 = 0.0f
mech4.cpp was right on both thresholds. hud.cpp's whole tuning block was
wrong -- every entry a 0.0f/500.0f stand-in, and three of five names named the
wrong mechanism:
* ec4/ec8 are the fire-control LOCK limits (own HUD host zone < 0.75 damage,
targeted zone < 1.0), NOT heat/page-visibility. A shot-up cockpit drops to
"target held, no lock"; a dead zone cannot be re-locked.
* ed0 is the shared ZERO -- the right-hand side of the range-slide Abs()
idiom (`dt * 500.0 <= 0.0` picks the sign) and of an `== 0.0f` test at
@0x28C. The 500 m/s slide rate is an IMMEDIATE (0x43fa0000). The old
"MaxTorsoSlew = 500.0f" read that backwards.
* f90 (FlickerFloor 0.0f) was the only correct entry. Its decay RATE is the
object's own @0x298, not a constant -- the step-6 banner said "up to
MaxTorsoSlew (500/sec)" and is corrected too (hud.cpp:229 already had it
right, so the file disagreed with itself).
All four wrong constants were DEAD (zero code uses; MaxTorsoSlew appeared only
in a comment), so this changes no behaviour -- it stops the next reader
trusting them. Renamed to what they are: LockOwnZoneDamageLimit,
LockTargetZoneDamageLimit, RangeBias, HudZero. Builds clean.
GAP FOUND, filed not fixed: HudSimulation subtracts _DAT_004b7ecc (100.0f)
from RangeToTarget@0x1EC every frame while the timed flag @0x22C is set
(timer @0x21C accumulates to @0x1D8, then both clear). Our targeting step
does the 500 m/s slide but never this bias, so the authentic timed -100 m
range offset is missing. What sets @0x22C is unidentified. -> open-questions.
KB swept: no context/ or docs/ file repeated the wrong constants (gauges-hud's
0-1200 ladder / 500 m/s / pegs-at-1200 claims are all correct); the error was
confined to hud.cpp. gauges-hud.md gains the byte-grounded table + the gap.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC
This commit is contained in:
co-authored by
Claude Opus 5
parent
7b003243ae
commit
832bec0966
@@ -557,6 +557,23 @@ and every instrument is now live [T2]:**
|
||||
transcription color bug caught by a period reference screenshot, 2026-07-09; same for the
|
||||
bottom bowtie carets @4569-4570); pegs at 1200 with no target; the DISPLAYED range slides at
|
||||
**500 m/s** toward the true pick range (HudSimulation :5652 [T1]).
|
||||
**The HudSimulation tuning constants, read off .rdata 2026-08-08 [T1]** (`section_dump.txt`
|
||||
rows ` 4b7ec0 8be55dc3 0000403f 0000803f 0000c842` / ` 4b7ed0 00000000`) —
|
||||
`_DAT_004b7ec4` = **0.75f**, `_DAT_004b7ec8` = **1.0f**, `_DAT_004b7ecc` = **100.0f**,
|
||||
`_DAT_004b7ed0` = **0.0f**, `_DAT_004b7f90` = **0.0f**. ec4/ec8 are the fire-control **LOCK**
|
||||
limits (own HUD host zone < 0.75 damage, targeted zone < 1.0 — so a shot-up cockpit drops to
|
||||
"target held, no lock", and a dead zone can't be re-locked); ed0 is the shared **zero** in the
|
||||
range-slide `Abs()` idiom (the 500 is an immediate `0x43fa0000`, NOT a global). `hud.cpp` had
|
||||
carried all five as 0.0f/500.0f stand-ins under guessed names ("SegmentTempLimit … heat
|
||||
threshold for HUD page visibility" was neither heat nor page visibility) — corrected in place,
|
||||
with the live lock/slide implementation staying in mech4.cpp's targeting step, which had both
|
||||
thresholds right all along.
|
||||
**GAP — the 100 m RANGE BIAS is NOT reconstructed [T1 read, unimplemented]:** HudSimulation
|
||||
subtracts `_DAT_004b7ecc` (100.0f) from `RangeToTarget@0x1EC` **every frame while the timed
|
||||
flag @0x22C is set**, accumulating @0x21C by `time_slice` until it reaches @0x1D8, then clearing
|
||||
both. The port's targeting step (mech4.cpp) does the slide but never the bias, so whatever
|
||||
in-game state sets @0x22C currently produces no range offset. Trigger for @0x22C not yet
|
||||
identified — see [[open-questions]].
|
||||
**VERDICT (Gitea #4, 2026-07-20): the "range slides in/out crazily while walking" report is
|
||||
AUTHENTIC behavior, not a bug [T2 measured].** Per-frame `BT_RANGE_LOG` traces (mech4.cpp, with
|
||||
an independent Möller-Trumbore cross-check `BTGroundRayHitExact` in btvisgnd.cpp) on scripted
|
||||
|
||||
@@ -954,6 +954,18 @@ register. ⚠ The audit also flags the damage-economy item as SELF-CONTRADICTOR
|
||||
deterministically leave ~0 at [ebp-0xc]; or replicant-player reroute delivery differs). Port
|
||||
deviates safely (award=0). Curiosity, not a blocker.
|
||||
|
||||
## HUD range-bias @0x22C — read but NOT reconstructed (2026-08-08) [T1 read, unimplemented]
|
||||
`HudSimulation` subtracts `_DAT_004b7ecc` = **100.0f** from `RangeToTarget@0x1EC` on **every frame
|
||||
that the flag @0x22C is non-zero**, while accumulating a timer @0x21C by `time_slice` until it
|
||||
reaches the limit @0x1D8, at which point BOTH the timer and the flag are cleared. So the authentic
|
||||
HUD has a timed **−100 m range offset** state that our targeting step (mech4.cpp — which does
|
||||
reconstruct the 500 m/s slide correctly) never applies.
|
||||
**Open:** what SETS @0x22C. Candidates not yet checked — a targeting-computer damage/jam effect, an
|
||||
ECM/spoof, or a weapon-lock transient. Found while correcting hud.cpp's stand-in constant block
|
||||
(the values are now byte-grounded: ec4 0.75 / ec8 1.0 / ecc 100.0 / ed0 0.0 / f90 0.0). Details:
|
||||
[[gauges-hud]] §Right ladder. Worth resolving before trusting any field report about the range
|
||||
readout being wrong — it is a real behavioural gap, not a cosmetic one.
|
||||
|
||||
## Rendering follow-ups (non-blocking)
|
||||
- ~~Per-pilot mech PAINT (color/badge/patch)~~ — **DONE 2026-07-17, verified live** (crimson MadCat +
|
||||
yellow VGL emblems + hip hazard stripes). Mechanics + the vehicletable color/badge/patch name
|
||||
|
||||
Reference in New Issue
Block a user