tehAon’s Sound Radar – See What You Cannot Hear

**Redesign.** v0.1.0 was audio-event driven, and playtesting showed that cannot work. The numbers say
why: `EntityAlive` picks its next idle vocalisation from `RandomRange(soundAlertTicks / 2,
soundAlertTicks)` with `soundAlertTicks = 25 * 20 = 500` ticks — **one noise every 12–25 seconds**. A
2.5s marker driven off that is on screen roughly a seventh of the time a zombie is walking at you.
That is a rumour, not a threat display, and no amount of tuning fixes an event that fires three times
a minute.
- **Continuous threat layer.** Hostiles within range are now read from entity state every tick and
tracked continuously: direction, distance, what they are, and whether they have noticed you
(`GetAttackTargetLocal`, never `GetAttackTarget` — the latter is server-only and reads null forever
on a dedicated client, which would make every hostile look harmless).
- **Proximity emphasis.** Markers grow, brighten and pulse as things get close. A uniform ring made
the zombie at 3 m look identical to the one at 50, which is the opposite of the triage you need.
- **Damage direction.** Get hit and a slab on the ring marks which side it came from. This could not
come from the audio layer at all: your hurt sound plays on your own entity at your own position, so
there is no direction in it to read. It is taken from the damage event instead. Damage with no
attacker (falling, radiation) draws bars above and below rather than inventing a bearing.
- **Base watch.** Something chewing a wall gets its own marker. Singleplayer and hosting only, and
the startup log says which case you are in rather than silently doing nothing on a dedi.
- **Vertical cut** on the threat layer, so a horde two floors down does not fill the screen with
arrows for things that cannot reach you.
- Sound events became an **annotation** on the threat layer: a hostile that just made a noise gets a
`!`, instead of a second arrow stacked on the same bearing. Sounds with no entity behind them
(explosions, gunfire, traps)…

- **Readable arrows.** Playtest: "hard to tell what direction an arrow is pointing sometimes". The
cause was structural, not cosmetic — the marker was the glyph `▲`, and an equilateral triangle has
**three-fold rotational symmetry**: turn it 120° and it is identical to where it started, so 45°
and 225° render as the same blob. Half the compass was ambiguous by construction.
Markers are now rasterised shapes instead of font glyphs, and the default (`arrow`) has a **tail**.
Asymmetry along the pointing axis is what makes a rotation readable — no rotation of an arrow
resembles any other. Verified at 18/26/44 px across eight bearings with `tools/shapecheck.py`,
which renders the same shape maths outside the game.
Dropping the font glyph also removes a quiet portability risk: `▲` came from whatever font IMGUI
resolved, and on a machine lacking it the marker would have drawn as a box or nothing at all.
- `arrowShape` config: `arrow` (default) · `chevron`, lighter on a crowded ring · `needle`, the most
precise bearing read · `triangle`, the old shape for anyone who preferred it.
- Markers now draw slightly taller than wide, since the length along the pointing axis is what the
eye actually reads the angle from.

The page was still serving 0.2.1, so this carries everything since — most of it about making the overlay readable on a monitor better than 1080p.
**0.4.0 — 2026-08-01**
**The HUD was drawn in raw pixels, so it shrank on every monitor better than 1080p — and captions
were placed by bearing alone, so any two hostiles in the same direction printed their names on the
same pixels.** Two separate bugs behind one report ("still hard to read, and everything overlaps").
**Everything now scales with your resolution.** IMGUI does no DPI or resolution scaling of its own,
and every size in the config was a raw device-pixel count tuned at 1080p. So the whole overlay was
drawn at the same *pixel* size on every display — three-quarter apparent size at 1440p, half at 4K —
sitting next to a vanilla HUD that scaled properly.
| | 1080p | 1440p | 4K |
| --- | --- | --- | --- |
| caption, was | 13 px · 1.20% of screen height | 13 px · **0.90%** | 13 px · **0.60%** |
| caption, now | 16 px · 1.48% | 21 px · 1.48% | 32 px · 1.48% |
| ring radius, was | 150 px · 13.9% | 150 px · **10.4%** | 150 px · **6.9%** |
| ring radius, now | 150 px · 13.9% | 200 px · 13.9% | 300 px · 13.9% |
- **Caption size is a setting now** (`fontSize`, default 16). It was hard-coded to 13 with no way to
change it at all.
- **`hudScale`** multiplies everything again on top, for taste or for eyesight. It is also the honest
way to ask for *smaller* rather than fighting each number.
- It only ever scales **up**. A 1280x720 window is often a small window on a large monitor, and
shrinking an accessibility overlay to match a low pixel count punishes the setup least able to
afford it.
**Markers in the same direction now group into one with a count.** Seven zombies down the same
street were seven arrows fighting for the same pixels; they are now one marker reading
`Radiated Screamer x7`. The group is drawn at the bearing of its **worst** member, never the average
of the group — you turn toward this arrow, and an average p…

[b]The dots on downed bodies can be turned off in play.[/b] Asked for directly — [i]"some people don't
want to see those."[/i] Fair: a dot sitting on a shape you have already dealt with reads as a warning
to some players, and "is that one still alive" is a question they would rather answer by hitting it
again.
The setting was already there — inViewDots="none" has worked since v0.6.0 — but the only way to
reach it was to quit the game, find soundradar.local.xml, and know the attribute name and the
word. That is not a setting anybody has, it is a setting somebody could have found. So:
• [b]Alt+F6[/b] mutes the dot layer and brings it back. Two states, not a three-way cycle through
ground → all → none: a player pressing a key because the screen is too busy must never land
on [b]more[/b] dots than they started with on the way to quiet. Unmuting returns whatever you were
on, not the default. dotsKey="" if you would rather not have the binding.
• [b]/sr dots [none|ground|all][/b] does the same from chat, and with no word at all it is the same
flip the key does. off / on / hide / show are accepted, because that is what people type
at a toggle and refusing them to insist on none is pedantry aimed at somebody already annoyed.
Both write the live setting rather than a flag of their own, so /sr status cannot disagree with
the screen. Both are for the session: the change says so every time, and prints the line to paste
into soundradar.local.xml to keep it. Alt+ because Ctrl+F6 and Shift+F6 are already spoken
for in this family, and it joins the startup conflict check with the rest of them.
Nothing about what the dots mean changed, and ground is still the default.
[b]Fix: a noise in view and a body in view were the same mark.[/b] Straight off the playtest — [i]"I
didn't realize when they attack blocks it shows a dot, that gets slightly confusing with the 'all'
setting."[/i] Correct, and it was worse than a surprise: they were genuinely the same shape.
A zombie hitting a block r…

- **Claims game 3.2.0.** `GAME_VERSIONS` widens from `V3.0.0-V3.1` to `V3.0.0-V3.2.0`.
Verified in game on a real V3.2.0 b10 client, not inferred: see `VERIFIED` for what was
actually exercised. No behaviour changed — this release is the claim and nothing else.

**The key-conflict check has never once been able to report a conflict.** It said
"no conflicts with vanilla" on every install since it was added, including where a key
genuinely collides — this mod's own keys (toggle, captions, log and dots) were never really tested.
- **What was wrong.** The check asked the game which action owns a key via `BindingUsed`,
which returns the bound `PlayerAction` or null. It is not a bool — but `PlayerAction`
inherits an implicit bool conversion from InControl's `OneAxisInputControl`, so
`if (set.BindingUsed(source))` compiled and quietly asked something else: *is that vanilla
action being held down right now*. A key that was taken answered false unless you happened
to be pressing it at that instant; a key that was free dereferenced null and threw. Both
ways out meant "no conflict", and the summary line then said so out loud.
- **It also could not tell you when it had failed.** The counter of successful probes was
incremented before the call that throws, so exceptions counted as successes. Now a probe
counts only once a lookup has actually returned, and if none did, the log says conflicts are
UNCHECKED rather than claiming they are absent.
- **And it ran too early to work.** The check sat in a run-once block, but the game's input
platform is not up at mod init and not reliably up on the first frame in a world. It now
retries each update until the bindings can really be read.
- Nothing else changed: no key was rebound, and the mod behaves exactly as before. What
changes is that a genuine collision is now reported, naming the vanilla action and the set
it lives in, with `soundradar.local.xml` to fix it in.