context: mech+0x190 IDENTIFIED = the owning BTPlayer (Mech::GetPlayerLink)

The valve/Myomers 'gates' (FUN_004ac9c8 / FUN_004ad7d4) read the owning BTPlayer's
+0x274 / +0x260 (mech+0x190 = the player, bound by FUN_0049f624). So there's no new
subsystem to build -- the wiring is 2 gate accessors -> GetPlayerLink() named members.
Open: the true semantics of player+0x260/0x274 (scoring names showKills/roleClassIndex
may not match the gate use) + the FUN_004ad7d4 HeatModelActive-vs-OwnerAdvancedDamage
label conflict + these are likely MODE flags authentically-off in the basic mission.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

context/open-questions.md

@@ -34,14 +34,23 @@ authentic path scoped.
   DIFFERENT object at **`mech+0x190`** (both `FUN_004ac9c8` the valve guard `→+0x274` and `FUN_004ad7d4`
   the Myomers gate `→+0x260` deref `owner+0x190`, which ≠ the 0x434 messmgr cache). The earlier
   "0xBD3 gates 4 things" note was wrong.
-- **⭐ `mech+0x190` gate object (UNIDENTIFIED — the REAL keystone for the gauge-adjacent routes)** — a
-  per-mech status/damage-state object read by the valve `MoveValve` guard (`owner+0x190→+0x274`) AND the
-  Myomers `OwnerAdvancedDamage` gate (`owner+0x190→+0x260`). No decompiled writer found for `mech+0x190`
-  yet (likely a base-ctor registration or an offset not yet traced). Identifying + reconstructing it is
-  what actually unblocks the condenser valve CONTROL route, the Myomers advanced-damage coupling, and
-  (via its message queue) plausibly the MessageBoard/control-mode routes. What resolves it: trace the
-  `mech+0x190` writer (grep other parts / disas the mech ctor + base ctors) → identify the class →
-  reconstruct + wire.
+- **✅ `mech+0x190` IDENTIFIED (2026-07): it is the owning `BTPlayer`** (`Mech::GetPlayerLink()`,
+  `MECH_OWNING_PLAYER`; ENTITY.h:430). Set by `FUN_0049f624` (the mech↔player bind: `mech+0x190 = player`
+  AND `player->playerVehicle(+0x1fc) = mech`), which resolves the player from the mission player registry
+  (`app+0x2c+0x54`, `FUN_0041fd18`) by the pilot key. The valve/Myomers "gates" read the owning player's
+  fields at `player+0x260` and `player+0x274` (the reconstruction maps this block as `showDamageReceived@0x25c
+  / showKills@0x260 / showDamageInflicted@0x264 / roleClassIndex@0x274` in btplayer.hpp — from the SCORING
+  work, so the names may NOT match the gate semantics; the true meaning + the WRITER of `player+0x260/0x274`
+  are not yet pinned — part_013.c:4553-4660 is the TorsoSimulation, a different object, not the setter). So
+  there is NO new subsystem to build. **The wiring (small):** point `MechSubsystem::IsDamaged()` (`FUN_004ac9c8`, valve
+  guard) at `GetPlayerLink()->`(0x274) and `Myomers::OwnerAdvancedDamage()` (`FUN_004ad7d4`) at
+  `GetPlayerLink()->`(0x260) — via NAMED members (databinding trap: our BTPlayer layout ≠ binary; do NOT
+  raw-read `player+0x260`). ⚠ Resolve first: (a) a naming conflict — `FUN_004ad7d4` is labeled BOTH
+  `HeatModelActive` (heat.hpp) AND `OwnerAdvancedDamage` (myomers.cpp); re-verify which body is which; (b)
+  the true semantic of `player+0x260/0x274` vs the scoring-derived `showKills`/`roleClassIndex` names. NOTE:
+  these are MODE flags — in the basic test mission the inert Myomers / dormant valve is likely AUTHENTIC
+  (advanced damage off); wiring makes them RESPOND when a mission enables the mode, not necessarily change
+  the basic-mission behavior. The MessageBoard feed is separate (StatusMessagePool, below).
 - **StatusMessagePool (NULL stub, btstubs.cpp:62)** — the per-player status-message queue.
   BTPlayer+0x1dc is never populated → MessageBoard is empty (authentic for bring-up). What
   resolves it: wire the pool + decode `AddStatusMessage @0042e580` + the `Player__StatusMessage`