3f6efadf9e
Shell_TCAF_DeltaSaber_*_P: Velocity 8000, LifeTime 0.5 s, MaximumRange 4000 (self-consistent: 8000 x 0.5 = 4000), all confirmed. Two things were wrong: lead computed flight time as d / OUR speed (400-2000 u/s, so every shot was led 4-16x too far), and FIRE_RANGE was 5000 — past where the shells expire. Both fixed. But the HUD's own kill counters read 0000/0000 at the end of EVERY run including the nearest-fighter baseline, so the pilot kills nothing in any configuration and 'fraction of frames firing' was never measuring lethality. No improvement is claimed. One clean negative result kept: gating on the target's angular half-size alone (2.7 deg at 2584 units) is far tighter than the steering loop can hold the nose — firing collapsed to 1 frame in 2639. Angular size is a floor on the firing cone, never a cap. Next: the HUD carries a live ammo count, so holding fire and watching it settles 'we never shoot' vs 'we shoot and miss' in a single run.
164 lines
8.5 KiB
Markdown
164 lines
8.5 KiB
Markdown
# Escort / mission state from guest RAM — every entity's hull
|
||
|
||
**Status:** ✅ CONFIRMED (2026-07-30). Capture: `tools/re-capture/mission_state.py`,
|
||
session `tools/re-capture/escort_session.sh`, Stage 02 from save slot 01, 240 s of
|
||
flight, 240 samples at 1 Hz → [`captures/mission-state-stage02.jsonl`](captures/mission-state-stage02.jsonl).
|
||
Screenshot evidence: [`captures/escort-stage02-hud.png`](captures/escort-stage02-hud.png).
|
||
|
||
## The question
|
||
|
||
`own_state.py` found the **player's** hull by anchoring on a solved definition
|
||
field — an undamaged craft carries its definition's `HP` (+0x054), so the live
|
||
counter is the copy of that number that falls. Result: `hull = position + 0x154`
|
||
([autopilot](autopilot-memory-driven.md)).
|
||
|
||
Stage 02 is an **escort**, and it is lost when the ACROPOLIS sinks, not when the
|
||
player dies: a 240 s run hit `GAME OVER` with our own hull at 1500/1500. Scoring
|
||
that objective needs *someone else's* hull. So: is `+0x154` a property of the
|
||
**entity class**, or of the player object?
|
||
|
||
## Finding — it is class-wide
|
||
|
||
At the first sample of the run, before this session's fighting had touched them,
|
||
`pos+0x154` equals the entity's own definition `HP` across **seven classes and
|
||
five distinct HP values**:
|
||
|
||
| Class | radius | definition `HP` | `pos+0x154` at t=0 |
|
||
|---|---|---|---|
|
||
| `UN_e007_ADAN_Turret` | 22 | 100 | 100.0 (all 60 instances) |
|
||
| `UN_e010_ADAN_Attacker_S` | 100 | 500 | 500.0 (all 19) |
|
||
| `UN_f106_TCAF_Destroyer` | 2000 | 10000 | 10000.0 |
|
||
| `UN_e106_ADAN_Destroyer` | 2100 | 10000 | 10000.0 |
|
||
| `UN_f105_TCAF_Cruiser` | 3800 | 30000 | 30000.0 |
|
||
| `UN_e105_ADAN_Cruiser` | 3800 | 30000 | 30000.0 |
|
||
| **`UN_f101_TCAF_Acropolis`** | 1400 | **25000** | **25000.0** |
|
||
|
||
Measured directly by `mission_state.py scan` at the start of three separate runs:
|
||
**146/150, 147/150 and 147/150 entities** hold exactly their definition's `HP` at
|
||
`pos+0x154`. The handful that do not sit *slightly below* it (9800/10000,
|
||
29933.3/30000, 9725/10000, …) — the battle is already in progress when the player
|
||
launches, so those ships have already been shot at. **Nothing read above its `HP`,
|
||
and nothing read an unrelated number**, which is what a coincidental offset would
|
||
produce.
|
||
|
||
The value behaves like a live counter, not a copy of the definition:
|
||
|
||
- it **falls under fire** — 780 distinct damage events were logged across the run;
|
||
- it **goes negative at death** and the entity then disappears from the heap
|
||
(`UN_f106_TCAF_Destroyer` → `-30.0` of 10000, another → `-0.0`, a third GONE);
|
||
- the drops match what the HUD draws — the screenshot shows the ACROPOLIS and the
|
||
destroyer *CHARON* each with their own health bar, CHARON's already red.
|
||
|
||
So **`hull = position + 0x154` for every entity**, and the escort objective is
|
||
directly scoreable: read the protected ship's hull, normalise by its definition's
|
||
`HP`, done. No new anchor, no value scan.
|
||
|
||
## The escort asset, measured
|
||
|
||
`UN_f101_TCAF_Acropolis`, one instance, `HP` 25000, collision radius 1400.
|
||
|
||
Its hull over the 240 s run (pilot chasing the nearest hostile fighter, the
|
||
current `pilot.py` behaviour):
|
||
|
||
```
|
||
t= 0..150s 25000.0 untouched
|
||
t= 180.1s 24779.5
|
||
t= 210.1s 24149.5
|
||
t= 239.1s 23038.2 -1961.8 total, ≈ -600 HP/min once it starts
|
||
```
|
||
|
||
**⚠️ Onset is NOT a fixed schedule — corrected by a later run.** From this run alone
|
||
it looked like the asset is safe for the first ~170 s. A second run put the first
|
||
damage at **t = 70 s**, and its hostile population *grew* (134 → 166 ADAN) where this
|
||
one's shrank (147 → 118). So the stage is not replaying identically, and "the asset
|
||
is untouched early" is a property of one run, not of Stage 02. What survives the
|
||
second run is the weaker, still useful claim: **the loss is slow** — a few hundred to
|
||
~1400 HP/min against 25000, so tens of minutes to sink. The earlier `GAME OVER`
|
||
therefore was not a fast loss; it was an undefended one.
|
||
|
||
## Also captured
|
||
|
||
- Hostile population fell 147 → 118 over the run (the pilot fired on 435 of 1913
|
||
engage frames; most of the remainder it was manoeuvring with the target outside
|
||
the 9° firing cone).
|
||
- Two friendly destroyers were lost while the pilot was elsewhere.
|
||
- The HUD's `REMAINING OB` read **012** at t≈240 s while 118 ADAN entities were
|
||
alive, so that counter is **objectives, not hostiles** — its RAM address is still
|
||
unknown (❔ open).
|
||
|
||
## Escort-weighted targeting — implemented, and what it did NOT fix
|
||
|
||
`pilot.py` gained a **DEFEND** mode (2026-07-30): while the asset is losing hull,
|
||
target the hostiles pressing *it* — ranked by distance to the asset minus credit for
|
||
closing on it — instead of the ones nearest to us. Trigger and ranking both read the
|
||
live hull, so nothing is inferred.
|
||
|
||
It works mechanically: DEFEND engaged **1.9 s after the asset's first hit** in one run
|
||
(t=167.0), and held for 54 % of a 330 s run. **But it did not measurably save the
|
||
asset.** Over the window the two policies share, they are the same to within noise:
|
||
|
||
| t (s) | nearest-fighter | escort-weighted |
|
||
|---|---|---|
|
||
| 120 | 25000.0 | 24910.0 |
|
||
| 180 | 24779.5 | 24460.0 |
|
||
| 239 | 23038.2 | 23218.0 |
|
||
|
||
Two honest reasons it cannot yet be scored better than "no worse":
|
||
|
||
1. **The runs are not comparable past that window** — different spawn timing and, in
|
||
the escort-weighted run, a hostile population that *grew* 134 → 166 while the
|
||
baseline's fell 147 → 118.
|
||
2. **Lethality is the real bottleneck, not target choice.** The guns are on for only
|
||
**12 % of combat frames** (320 of 2630); the rest of the time the target is outside
|
||
the 9° firing cone while the loop manoeuvres. Choosing a better target does little
|
||
when most passes do not shoot.
|
||
|
||
**One bug found and fixed by the first escort run** (worth keeping as a pattern): the
|
||
new mode flies *at* the asset, which sits inside the friendly formation, and the run
|
||
ended `hull 1500 -> DEAD` in a single tick at 2026 units/s, 0.6 s from a friendly
|
||
destroyer the avoidance expected to clear by 365 units — against a hull of radius
|
||
2000. Keep-out had been applied only to hostile turrets. Every entity above
|
||
`BIG_RADIUS` now gets a physical keep-out of **its own radius + 800**, with braking
|
||
inside it, whatever its faction; the next run survived its full 330 s untouched.
|
||
|
||
## Ballistics from the disc data — and the measurement that invalidates the metric
|
||
|
||
The solved `Shell` records give the player's guns exactly
|
||
(`Shell_TCAF_DeltaSaber_{NoseGun,Gun,Beam}_P`, all ✅ CONFIRMED):
|
||
**`Velocity` 8000**, **`LifeTime` 0.5 s**, **`MaximumRange` 4000** — self-consistent,
|
||
since 8000 × 0.5 = 4000 — plus shell `Radius` 20–30 and `Power` 15/30/40.
|
||
|
||
Two things in `pilot.py` were plainly wrong against those numbers, and both are fixed:
|
||
|
||
- **Lead used our own speed as the shell speed.** Flight time was `d / max(our_speed,
|
||
300)`, i.e. 400–2000 u/s instead of 8000 — every shot led **4–16× too far ahead**.
|
||
- **`FIRE_RANGE` was 5000**, past the range at which the shells expire.
|
||
|
||
**But the outcome metric says none of this has been shown to help.** The HUD's own
|
||
counters — `YOU KILLED: WARSHIPS` / `WARPLANES` — read **0000 / 0000 at the end of
|
||
every run**, including the nearest-fighter baseline. The pilot is not killing
|
||
anything in any configuration, so "fraction of frames with the guns on" (12 % → 5 % →
|
||
1 frame in 2639 as the firing gate was varied) was never measuring lethality. The
|
||
corrections above are right on the physics and fix demonstrably wrong code; **they are
|
||
not evidence of improvement**, and none is claimed.
|
||
|
||
The firing gate itself produced one clean result worth keeping: gating on the target's
|
||
angular half-size **alone** (2.7° at 2584 units for a fighter) is far tighter than the
|
||
steering loop can hold the nose, and firing collapsed to 1 frame in 2639. Angular size
|
||
belongs in the gate as a **floor** that opens it up close, never as a cap.
|
||
|
||
**Open (next):** find out why nothing dies. The cheap decisive test is whether the
|
||
`RB` command discharges the gun at all — the HUD carries a live ammo count
|
||
(`MAIN MPM 00300`, which the weapon RE matched to `LoadingCount`), so holding fire and
|
||
watching that number settles "we never shoot" vs "we shoot and miss" in one run.
|
||
|
||
## Reimplementation notes
|
||
|
||
- Defeat conditions for an escort stage are readable as: protected-asset
|
||
`hull ≤ 0`, or player `hull ≤ 0`.
|
||
- Every unit's effective HP is the definition's `HP`, confirmed live for 7 classes —
|
||
the same field the [unit struct](structures/unit-struct-runtime.md) already solves
|
||
statically, so disc data and runtime agree.
|
||
- Entity removal on death is observable (the object leaves the heap), which gives a
|
||
clean lifetime signal for anything modelling spawn/despawn.
|