re: WITHDRAW "the absence is structural" -- capital ships do have +0x130 blocks

My enumeration sourced entities from moving(), which requires a position to CHANGE
between two samples.  A capital ship holding station changes by exactly zero, so it
can never appear -- which is also why lo=0 and the whole-map scan did not help, and
why parked ArrowHead wingmen were missing.  The filter was the problem, not the
range, and not the game.

navigator.py already does it right and says so in its header: search for the
DEFINITION POINTER and take position = hit - 0x130, "which finds every entity
whether it is moving or not".  The existing mission_state.py scan on Stage 02
returns 149 entities with hull(+0x154) == definition HP for 129 of them:

  UN_f101_TCAF_Acropolis  (+5000, +0, +0)  hull=25000.0  HP=25000.0  frac=1.000
  UN_e105_ADAN_Cruiser                     hull=30000.0  HP=30000.0
  UN_e106_ADAN_Destroyer                   hull= 9150.0  HP=10000.0  (under fire)

So "an autopilot that must protect the Acropolis cannot locate it through the
+0x130 method at all" is withdrawn outright -- it can, and INDEX.md had already
recorded the Acropolis falling 25000 -> 23038 over 240s.

What survives: the two enumerations are still different structures in different
regions (0/116 vtable instances lie in the +0x130 region).  What does not survive
is any claim that the +0x130 model covers only four types.
This commit is contained in:
Sylpheed RE agent
2026-08-26 23:20:48 +00:00
parent 549134c415
commit d2c81249cd

View File

@@ -40,6 +40,46 @@ no runtime roster is reproducible across runs unless the stage is verified first
| `UN_f101_TCAF_Acropolis` / `bf001_SchlosBase` / `f201_Tanker` | 1 each | **0** |
| **total** | **116** | **30** |
> # ❌ CORRECTED 2026-08-26 — "the absence is structural" is WRONG
>
> Everything below about capital ships being absent from the `+0x130` method is
> an artifact of **how I sourced the entities**, not a property of the game.
>
> I enumerated by taking `moving()` triples and testing `+0x130`. `moving()`
> requires a position to **change between two samples**. A capital ship holding
> station changes by *exactly* zero — which is why dropping the floor to `lo=0`
> did not help either, and why parked `ArrowHead` wingmen were missing too. The
> whole-map scan failed for the same reason: the filter, not the range.
>
> `navigator.py` already does it correctly, and says so in its header — it
> searches for the **definition pointer** and takes `position = hit - 0x130`,
> *"which finds every entity whether it is moving or not"*. Running the existing
> `mission_state.py scan` on Stage 02 finds **149 entities**, capital ships
> included:
>
> ```
> UN_f101_TCAF_Acropolis ( +5000, +0, +0) hull= 25000.0 HP= 25000.0 frac=1.000
> UN_e105_ADAN_Cruiser ( -29500, +500, +3219) hull= 30000.0 HP= 30000.0 frac=1.000
> UN_e106_ADAN_Destroyer ( -25500, -1000, +7041) hull= 9150.0 HP= 10000.0 frac=0.915
> UN_f106_TCAF_Destroyer ( +1504, -498, -1937) hull= 9579.2 HP= 10000.0 frac=0.958
> UN_f001_..._Player ( -6676, +882, +1004) hull= 1500.0 HP= 1500.0 frac=1.000
> ```
>
> `hull(+0x154) == definition HP` for **129 of 149**, the rest already damaged.
>
> ❌ So this specific claim is withdrawn outright: *"an autopilot that must
> protect the Acropolis cannot locate it through the `+0x130` method at all."*
> It can. The Acropolis is right there at `(+5000, 0, 0)` with its hull readable
> and falling. `INDEX.md` had already recorded this — ACROPOLIS 25000 → 23038
> over 240 s — which makes this the eighth time this session that the corpus
> held the answer before I measured.
>
> What survives from below: the two enumerations really are **different
> structures** in different regions (0/116 vtable instances lie in the `+0x130`
> region), and the vtable scan is still the one that sees stations and scenery.
> What does **not** survive is any claim that the `+0x130` model is limited to
> four types.
## ✅ The absence is structural, not a filter artifact
The obvious explanations were tested and **both fail**: