From f2a18e555cb2d62a1b94429d4d767e2d66cdd2fd Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 20:06:10 +0000
Subject: [PATCH] re: "follow the name pointer" is structurally dead for pak
 strings

Locating DeltaSaber at mission time works: 53 occurrences, all in the heap
(0xBC66..-0xBC6C..), none in the XEX image -- DeltaSaber_T.xpr, _Special,
_NoseGun, _Missile, _TwinGun.

But searching all of guest memory for a big-endian pointer to those addresses
returns ZERO references for every one tried.  That is the format, not a search
bug: those strings live in the mission pak's IDXD string pool, and this corpus
decoded that container long ago -- records reference names by OFFSET into the
pool, never by absolute pointer.  So there are no pointers to find, and "find the
name, follow what points at it" cannot work on pak data by construction.

This also narrows what the string counts proved.  The title-vs-mission control
stands (DeltaSaber 0 -> 81), so mission-specific DATA is loaded, which is more
than "the tables load at boot".  But these are asset-table strings, not live
entity objects, so they do not show entities have been spawned.  Honest split:
the mission's pak data is loaded; whether entity objects exist is still
unmeasured, because both probes tried -- gworld's vtable constants and
name-pointer following -- are respectively stale and structurally inapplicable.

Remaining routes, untried: derive the entity vtable from CODE via sylpheed.db's
vptr_writes table, which exists for exactly this; or find the entity list from
the mission update function rather than from data.
---
 docs/re/mission-freeze-signin-dialog.md | 34 +++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/docs/re/mission-freeze-signin-dialog.md b/docs/re/mission-freeze-signin-dialog.md
index d6f37f4b..51d1fd65 100644
--- a/docs/re/mission-freeze-signin-dialog.md
+++ b/docs/re/mission-freeze-signin-dialog.md
@@ -253,3 +253,37 @@ attachment names living in the **XEX image** (`0x820A…`), not runtime definiti
 records — so the route in is a name that only exists at mission time.
 **`DeltaSaber` is exactly that name**: find its occurrences in the heap, find what
 points at them, and read the vtable pointer of the referencing object.
+
+## 🔴 The "follow the name pointer" route is structurally dead for pak strings
+
+Locating `DeltaSaber` at mission time works: **53 occurrences, every one in the
+heap** (`0xBC66…`–`0xBC6C…`), none in the XEX image —
+`DeltaSaber_T.xpr`, `_Special`, `_NoseGun`, `_Missile`, `_TwinGun`.
+
+But searching all of guest memory for a 32-bit big-endian pointer to those
+addresses returns **0 references** for every one tried.
+
+That is not a search bug, it is the format. Those strings live in the mission
+pak's **IDXD string pool**, and this corpus decoded that container long ago:
+records reference names by **offset into the pool**, never by absolute pointer
+([`structures/idxd-container.md`](structures/idxd-container.md)). So there are no
+pointers to find, and "find the name, follow what points at it" cannot work on
+pak data by construction.
+
+## 🟡 Which narrows what the string counts actually proved
+
+The title-vs-mission control stands — `DeltaSaber` really is 0 at the title and 81
+after take-off, so **mission-specific data is loaded**, which is more than "the
+unit tables load at boot". But these are **asset-table strings**, not live entity
+objects, so they do **not** show that entities have been *spawned*. The honest
+statement is:
+
+* ✅ the mission's pak data is loaded;
+* ❔ whether entity objects exist is still unmeasured, because the only two
+  probes tried — `gworld`'s vtable constants, and name-pointer following — are
+  respectively stale and structurally inapplicable.
+
+❔ Remaining routes, none tried: derive the entity vtable from the **code** (find
+the constructor that writes a vtable pointer, via `sylpheed.db`'s `vptr_writes`
+table, which exists precisely for this); or find the entity list from the mission
+update function rather than from data.