Skip to content

feat(combat): enemy health bars, crosshair aiming + AutoAim world rule, ship-weapon enforcement - #695

Merged
marceld23 merged 2 commits into
mainfrom
feat/health-bars-and-aiming
Aug 3, 2026
Merged

feat(combat): enemy health bars, crosshair aiming + AutoAim world rule, ship-weapon enforcement#695
marceld23 merged 2 commits into
mainfrom
feat/health-bars-and-aiming

Conversation

@marceld23

Copy link
Copy Markdown
Owner

Summary

Combat gets real feedback and real aiming:

  • Enemy health bars (Floating health bars above enemies (planet + space, toggleable) #692) — every damageable entity (planet machines/bandits, creatures incl. titans, space drones/UFOs/cruisers/bandit ships) shows a floating green→amber→red bar (companions cyan) while in combat (~6 s after a hull drop) or under the crosshair/fire lock. Pooled WorldBar primitive on ScreenLabelLayer, shared policy in the new EnemyHealthBars helper, no protocol change. Client toggle under Settings → Comfort.
  • Crosshair aiming + AutoAim world rule (Manual weapon aiming with server-enforced AutoAim world rule (on foot + space) #693) — the entity under the crosshair always wins (analytic ray-vs-sphere + voxel terrain march); auto-aim otherwise acquires only in a ~±35° forward cone (no more behind-the-back kills), melee sweeps ~±60°, space tightens from ±75° to ~±30°. New world rule GameRules.AutoAim (default ON; live admin row, --auto-aim CLI): OFF = only a genuine crosshair/boresight hit lands, misses trace into the terrain. Crosshair tints hostile-red, hit marker on attributed hits. Intents carry the aim direction contractless-additively (zero = legacy client); the server validates angle, ranged line-of-sight and the space firing arc. Existing saves keep AutoAim ON automatically.
  • Ship-weapon enforcement (Ship weapons: server ignores cooldown & energy; client hardcodes range 45 #694)weapon_cooldown and weapon_energy are now enforced server-side (cooldown committed only when the shot fires; lazily regenerating reactor-fed energy pool), and the client reads range/cooldown from the fitted module instead of hardcoding 45/0.45 — laser_cannon_2 finally uses its range 70.

Testing

  • 6 new AimValidationTests (legacy zero-dir, cone reject, manual crosshair line, wall LOS block, space firing arc, server cooldown), CLI parse + world-rule live-edit coverage; fire-loop tests tick the cooldown.
  • Fast tier locally green (1375 server + 147 client); local Windows Unity player build green and hand-checked.

closes #692
closes #693
closes #694

🤖 Generated with Claude Code

marceld23 and others added 2 commits August 3, 2026 20:31
…e, ship-weapon enforcement

Health bars (#692): pooled WorldBar primitive on ScreenLabelLayer + shared
policy in EnemyHealthBars — every damageable entity (planet machines/bandits,
creatures, space hostiles) shows a green→amber→red bar (companions cyan) while
in combat (~6 s after a hull drop) or under the crosshair/fire lock. Lerped
fill, distance fades matching the nameplate conventions, id cleanup on despawn.
No protocol change (Hull/HullMax were already replicated). Client toggle
ClientSettings.ShowEnemyHealthBars + ui.settings.show_enemy_health (en/de).

Aiming (#693): on foot the crosshair entity (analytic ray-vs-sphere + voxel
terrain march; entity meshes carry no colliders) always wins; auto-aim
otherwise acquires only in a ~±35° forward cone (no more behind-the-back
kills), melee sweeps ~±60°. New world rule GameRules.AutoAim (default ON;
--auto-aim CLI, live admin row, SetWorldRulesIntent/ServerRules) — OFF means
only a genuine crosshair hit (on foot) or boresight line (space, replacing the
±75° soft lock with ~±30°/ray) lands; misses trace into the terrain. Crosshair
tints hostile-red, hit marker flashes on attributed hull drops. Intents carry
the aim direction contractless-additively (zero = legacy client) and the
server validates angle, ranged line-of-sight and the space firing arc with
generous anti-cheat tolerances. Old saves keep AutoAim ON via the missing-field
default — no rules lift needed.

Ship weapons (#694): weapon_cooldown and weapon_energy are now enforced
server-side (per-player cooldown committed only when the shot fires; lazily
regenerating reactor-fed energy pool), and the client reads range/cooldown
from the fitted module instead of hardcoding 45/0.45 — laser_cannon_2 finally
gets its range 70.

Tests: AimValidationTests (legacy zero-dir, cone reject, manual crosshair
line, wall LOS block, space arc, server cooldown), CLI parse + live-edit
coverage; fire-loop tests tick the cooldown. 1375+147 fast-tier green.

closes #692
closes #693
closes #694

Co-Authored-By: Claude Fable 5 <[email protected]>
…aram not capturable in local function

The dotnet test build didn't catch either (the shot-direction plumbing is
Unity-client-only code): Vector3f was fully qualified with the wrong namespace
in the two intent senders, and BestConeTarget's local Consider() captured the
out parameter (CS1628) — now tracked in a local and assigned on return.
Local Windows player build is green.

Co-Authored-By: Claude Fable 5 <[email protected]>
@marceld23
marceld23 merged commit 0948b8c into main Aug 3, 2026
13 checks passed
@marceld23
marceld23 deleted the feat/health-bars-and-aiming branch August 3, 2026 19:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant