the #73 pick dig, part 1: mech+0x36c is an embedded engine Reticle -- the writer is still at large

Chasing the un-decompiled targeting pick (the residual of #73). The hunt for
"who writes mech+0x37c/0x388/0x38c" kept coming back empty for a structural
reason now understood: those three fields are the tail of an embedded ENGINE
Reticle struct at mech+0x36c (RETICLE.h lays out position/state/pickPointingOn/
rayIntersection/targetEntity/targetDamageZone/elementMask, landing exactly on
0x37c/0x388/0x38c). Writers carry &mech->reticle and use small reticle-relative
offsets, invisible to any mech-relative displacement scan.

T0 corroboration, ENTITY3.h:131: "For BattleTech, damage zones are only valid
via reticle based weapons."

Ruled out as the writer: the engine Reticle itself (passive container -- ctor
and resource parse only); HudSimulation @0x4b7830 (holds &owner->reticle in esi
for its whole body but only READS the pick -- range caret, designator
transform -- and slews reticlePosition via the @0x4b7ed4 ease); the 0x482xxx
sites (mission-table target bookkeeping, address-of computations); the gyro
coefficient reads at 0x4b2c24/5c/6e (that class's own +0x370..0x38c table).

Still dark, with the candidates mapped: the un-exported 0x4a1674-0x4a2d48
stretch (reticle-touching at 0x4a16a5 in the Make-time init, 0x4a1f93, and a
state+pickPointing+base trio at 0x4a294a-61 near entry 0x4a2971), the two
unidentified Mech vtable overrides +0x18/@0x4a122c and +0x1c/@0x4a0c2c (both
big switch functions), and a few lone sites. One of these computes the
authentic pick; recovering it answers whether the pod tested the aim ray
against the mech's cylinder (as the damage table's geometry suggests) or a box
like the port's stand-in.

Recorded in combat-damage.md \xc2\xa7Targeting so the next session starts from the map
instead of the empty scans.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/combat-damage.md

@@ -69,6 +69,23 @@ player-only logic on `this == application->GetViewpointEntity()` (else a spawned
 player input). [T1]
 
 ## Targeting (mech offsets, [[decomp-reference]] §3)
+**STRUCTURAL DISCOVERY (2026-07-29, the #73 pick dig): the target block is an embedded engine
+`Reticle` at `mech+0x36c`** [T0 layout-verified]. `engine/MUNGA/RETICLE.h` lays out exactly:
+`reticlePosition@0x36c` (Vector2D), `reticleState@0x374`, `pickPointingOn@0x378`,
+**`rayIntersection@0x37c`**, **`targetEntity@0x388`**, **`targetDamageZone@0x38c`**,
+`reticleElementMask@0x390`. This is why every "who writes 0x388" scan came back empty — writers
+carry `&mech->reticle` (an `lea [mech+0x36c]`) and use small reticle-relative offsets.
+`ENTITY3.h:131` states the model in T0 words: *"For BattleTech, damage zones are only valid via
+reticle based weapons."* The engine `Reticle` is a **passive container** (ctor + resource parse
+only — no pick math); `HudSimulation @0x4b7830` opens with `lea esi,[owner+0x36c]` and READS the
+pick (range caret from `rayIntersection`, the designator transform) and slews `reticlePosition`
+via `@0x4b7ed4`, but does not write the pick either. **The pick WRITER is BT code, still
+unlocated** [T4 candidates]: the un-exported stretch `0x4a1674-0x4a2d48` (touches the reticle at
+`0x4a16a5` — the Mech::Make-called init — and `0x4a1f93`, `0x4a294a/54/61` state+pickPointing+base
+together near entry `0x4a2971`, which is called from `0x494483`), the two unidentified Mech vtable
+overrides `+0x18=0x4a122c` / `+0x1c=0x4a0c2c` (both big switch functions), and lone sites
+`0x4877a4` (byte read via the mission entity table `0x5015c8`), `0x4b0097`, `0x45fb14-24`.
+Recovering it settles #73's residual box-vs-cylinder question with binary truth.
 `mech+0x37c` = target world Point3D; `mech+0x388` = target `Entity*` (the `HasActiveTarget()` gate);
 `mech+0x38c` = targeted sub-zone (−1=whole). Weapons cache hasTarget/targetPoint/muzzlePoint,
 refreshed each frame. [T1]