re: surviving is not winning -- Stage 02 is an escort
The second 240 s flight ended on GAME OVER with our hull untouched at 1500/1500. Nothing shot us down; the ACROPOLIS was sunk while the pilot pursued an attacker two kilometres away. "Nearest hostile fighter" is the wrong objective function for this stage. The fix is available with what is already solved: the protected ship's hull is readable with the same anchor as ours (position+0x154, maximum = its own definition HP), so target priority can be "closing on the asset" and the escort can be scored live. Also records that a frozen log tail is what mission-end looks like from outside the emulator, not a wedge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,13 +1,15 @@
|
||||
# Memory-driven autopilot — build log and current state
|
||||
|
||||
**Status: 🟢 IT FLIES, KILLS AND SURVIVES — it has not yet finished a mission.**
|
||||
**Status: 🟢 IT FLIES, KILLS AND SURVIVES — but it loses the mission anyway.**
|
||||
Updated 2026-07-30. `pilot.py` flew Stage 02 for **300 s with the hull untouched
|
||||
at 1500/1500** and scored the first confirmed autopilot kill (`YOU KILLED
|
||||
WARPLANES 0001` on the HUD, screenshots `shots/pilot1-*.png`); the scene's
|
||||
hostile count fell from 134 to 111 over the run. The day before, every run was
|
||||
dead inside 35 s. What is still missing is the *end* of a mission: the objective
|
||||
counter (`REMAINING OB`) rises as new waves spawn, and nothing yet tracks which
|
||||
targets actually close it out.
|
||||
targets actually close it out — and the second run proved the point the hard
|
||||
way: `GAME OVER` with the hull at 1500/1500, because Stage 02 is an **escort**
|
||||
and the ACROPOLIS was sunk while the pilot chased fighters two kilometres away.
|
||||
|
||||
## 2026-07-30 — the numbers survival needs
|
||||
|
||||
@@ -200,6 +202,30 @@ statements about `0x820af030`, which is *not* the live entity —
|
||||
(6 Hz) and re-check orthonormality on every read — blocks found by a scan get
|
||||
overwritten between the scan and the read.
|
||||
|
||||
## The second run lost the mission **without being hit** (2026-07-30)
|
||||
|
||||
A second 240 s flight, with the two fixes above, ended on the `GAME OVER`
|
||||
screen — while the hull read **1500/1500 on the last live tick**. Nothing shot
|
||||
us down. The other defeat condition fired: *the ACROPOLIS is sunk*. The HUD had
|
||||
been showing a red `WARNING` banner for a while, and the pilot spent the whole
|
||||
run pursuing an `e010_ADAN_Attacker_S` two kilometres away.
|
||||
|
||||
So surviving is necessary and not sufficient, and "nearest hostile fighter" is
|
||||
the wrong objective function for this stage. **The mission is an escort.** What
|
||||
follows:
|
||||
|
||||
* **Prioritise hostiles by their distance to the protected asset, not to us.**
|
||||
The attackers worth killing are the ones closing on the ACROPOLIS.
|
||||
* **The protected asset's health is readable with the same anchor as ours** —
|
||||
hull at `position + 0x154`, its maximum being its own definition's `HP`. That
|
||||
gives a live "are we winning" signal for the escort, and it should drive the
|
||||
target choice directly.
|
||||
* A frozen tail in the log (identical position, speed and target for the last
|
||||
five seconds) is what mission-end looks like from the outside, **not** an
|
||||
emulator wedge. Worth knowing before diagnosing the wrong thing.
|
||||
* Practical: do **not** pipe a long run's log through `tail` — that discards
|
||||
everything but the end, and the interesting part of this run is gone.
|
||||
|
||||
## After survival, the blocker is lethality (2026-07-30)
|
||||
|
||||
The 300 s run took **no damage at all** and killed **one** warplane, spending
|
||||
|
||||
BIN
docs/re/captures/autopilot-escort-warning-stage02.png
Normal file
BIN
docs/re/captures/autopilot-escort-warning-stage02.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.6 MiB |
Reference in New Issue
Block a user