Resolves#4445
## Description:
Changes HoverHighlightController.ts to check for naval units if the
mouse is not currently hovering over land. It then highlights the owner
of the closest naval unit within 50px of the mouse.
The activation radius feels a little to large right now, but it is
consistent with the PlayerInfoOverlay functionality. Some input would be
appreciated
It is also currently disabled by default, not sure if this should be the
case.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
## Please put your Discord username so you can be contacted if a bug or
regression is found:
unne27
https://github.com/user-attachments/assets/7b8262e5-a097-44c8-b2ae-1ac336466623
<img width="534" height="901" alt="image"
src="https://github.com/user-attachments/assets/50e9e126-08a6-4a24-9c26-cd4099a2603e"
/>
---------
Co-authored-by: unne27 <>
## Problem
In the nuke trajectory preview, the SAM-intercept **"X"** marker was
drawn over **teammates'** SAMs — implying their SAM would shoot down
your missile. It shouldn't: like allies, a teammate's SAM never engages
your nuke. The bug only affected teammates; allies already worked.
## Cause
The preview built its threat set from `myPlayer.allies()` only — formal
alliances — and never considered teammates. That diverged from the sim
([`SAMLauncherExecution.ts`](src/core/execution/SAMLauncherExecution.ts#L118-L134)),
which skips any nuke whose owner it's `isFriendly()` with (**same team
OR allied**).
## Fix
`samThreatensNukePreview` now takes a teammate set and excludes
teammates **unconditionally**.
The subtlety: allies keep the existing *betrayal* exception — a strike
close enough to break the alliance makes that ally's SAM engage at
launch (`listNukeBreakAlliance`, the same function the sim uses).
Teammates get **no** such exception, because a strike can break an
alliance but never a team relationship. So even a player who is both a
teammate *and* a betrayed ally is correctly left off the threat set.
## Notes
- The sim has an "aftergame fun" exception where teammate SAMs *do*
target teammate nukes once there's a winner. The preview only appears
while aiming a buildable mid-game (no winner yet), so that case doesn't
apply here.
## Tests
Updated `samThreatensNukePreview` unit tests for the new signature and
added coverage for: teammate excluded, and teammate stays excluded even
when listed as betrayed. All 11 tests pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Summary
Fixes#4226 (Release Blocker, V32 regression).
The WebGL nuke trajectory preview built its SAM threat set by
unconditionally excluding own + allied SAMs
(`BuildPreviewController.updateNukeTrajectoryPreview`). But when the
strike targets allied territory, the alliance breaks at launch —
`NukeExecution.maybeBreakAlliances()` — so the betrayed ally's SAMs
**do** engage the nuke. The preview therefore showed a fully white
trajectory with no intercept X over an allied SAM, even though the bomb
would be shot down (V31 previewed this correctly).
## Fix
- Compute the would-be-betrayed player set with
`listNukeBreakAlliance()` — the exact function the sim uses at launch,
so preview and sim can't drift.
- Keep an allied SAM in the threat set iff its owner is in that set
(extracted as pure `samThreatensNukePreview()`).
- Other (non-betrayed) allies' SAMs remain excluded, matching sim
behavior where only alliances over the blast threshold break.
Both missing artifacts in the issue (red post-intercept segment and X
marker) come from `tSamIntercept` staying at 1.0 because no SAM was
supplied, so this one change restores both.
Cost note: this adds one `circleSearch` per throttled ghost update
(50ms) when the player has allies — same order as the existing
`wouldNukeBreakAlliance` call for the red warning circle.
## Testing
- Unit tests for the new threat-set predicate (4 cases) in
`tests/client/controllers/BuildPreviewController.test.ts`
- `tsc --noEmit`, ESLint, Prettier clean
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
BuildPreviewController and WarshipSelectionController now take the WebGL
view in their constructor and call view.updateGhostPreview /
view.setSelectedUnits themselves instead of emitting bus events that
ClientGameRunner forwarded. Splits the old mountWebGLDebugRenderer in
two — createWebGLView builds the view up front so the renderer can wire
controllers to it, mountWebGLDebugRenderer does the per-frame plumbing
after the transformHandler exists. GhostPreviewUpdatedEvent had no
remaining consumers and is removed.
UILayer → WarshipSelectionController and StructureIconsLayer →
BuildPreviewController. These are the two real Controller implementations
(state + click handling, no rendering) — the new names + location reflect
what they actually do now that all rendering lives in WebGL passes.
