In other words: the routine fires exactly ONCE per game for the Android, the first frame the alien is active and the slot is still in its as-issued template state (LongGameCrewInit, 41444, gives +0 = +7 = 0 for every slot). That single firing is the "encounter". When all guards pass: 1. IX = alien_target record; stamp (IX+0) = 80 (activation marker and timer that also blocks future re-entry into this branch). 2. Cache AlienTargetID into CrewIndex (33700) for downstream message enqueues. 3. CALL 37876 — scan crew records 1..7 for slots sharing the Android's (IX+1) sprite-class and write up to two slot indices into NearestCrewA / NearestCrewB (the Android's "kin" — its attack pool). 4. If at least one of NearestCrewA/B is alive: enqueue message #30 "{actor} is attacking {target}" with actor = AlienTargetID (the Android's name, e.g. "Ash is attacking Lambert"), put the alien_target into action state 7 with timer 40, then return. 5. If neither kin is reachable, fall through to 36717 (wander) and reset the Android to action state 1. Once the Android is in state 7, subsequent ResetCrewTimers frames dispatch it through CrewAction7_Handler (40757) which decrements the wound counter on its NearestCrewA/B kin and can collapse them via 39400 (msg #21 "{actor} has collapsed"). This routine is NOT the alien's own attack: the alien kills crew that end up in its room (slot 0 record byte +1) — see CrewHitsAlien (37584) and the kill primitive at 37733. Used by the routine at 36457.

CrewHitsAndroid — combat-resolution dialogue when the current actor engages the Android (called from CrewAction4_Handler at 37542). Fires from action state 4 (combat) when the actor's (IX+1) sprite-class byte matches the alien-target slot's (IX+1). Because (IX+1) is not unique in LongGameCrewInit (41444), this fires for the whole class that contains the Android (see CrewAction4_Handler header) — multiple crew members can trigger this routine, not only the Android itself. The Android is the slot picked by LongGameInit (42276) from LongGameTargetTable (41390) and stored in AlienTargetID (33703), record pointer cached at AlienTargetPtr (33701). It starts dormant and is activated by UpdateAlien (40826) on first encounter with the alien (the first frame AlienActiveFlag is set while the slot's +0/+7 are still template-zero), entering action state 7 and wounding its sprite-class kin via CrewAction7_Handler (40757). This routine is the **player-response leg**: when the Android (or another crew in its sprite class) is engaged in combat state 4, log the dialogue and apply the per-corridor-cell outcome. Guards: pixel coords IX+4 >= 2 and IX+6 >= 2 (actor placed on screen). Then 31823 locates the actor's corridor scan position into (31248): (31248) == 17 → silent: JP to 41229 (post-combat fade-out) (31248) >= 20 → silent: JP to 41229 (sentinel cells) (31248) == 16 → "net" outcome: write $FF to alien-target slot byte +0 (locks the Android out for the rest of this engagement), then enqueue message #31 "{actor} nets {target}" with actor = CrewIndex (33700) — the crew slot currently being dispatched — and target high byte from (33702). JP to 41229. else → "hit" outcome at 40999: enqueue message #32 "{actor} hits the Android" with actor = CrewIndex. Then run the per-(31248) follow-up: - decrement alien-target's byte +4 (wound counter); if it underflows past 2, stamp byte +7 = 2 (lockout sentinel that prevents UpdateAlien re-commandeering on subsequent frames, see UpdateAlien's byte-+7 gate at 40841) and enqueue message #21 "{Android} has collapsed" - if (31248) ∈ {6, 7}: enqueue message #5 "{actor}'s Tracker is broken" - if (31248) < 12: decrement the slot's entry in ItemCharges (33746) and enqueue message #6 if it expires - other (31248) values branch into the corridor-display rebuild at 41109 / 41195 (clears the Android's class entries from the corridor display and respawns the room) Caveat on the actor name: when (33700) is itself the Android's slot (the dispatch ran for the Android slot), the message reads "{Android} hits the Android" — apparent self-reference. With the class-not-ID matching above, the message ALSO fires for non-Android slots in the same class, e.g. "Lambert hits the Android" if AlienTargetID = 4 (Ash). The semantics here are best confirmed with an emulator run rather than further static reading. This routine is the parallel of 37584 (CrewHitsAlien) — identical control flow but referring to the Android slot (33701) and emitting messages #31 / #32 instead of #3 / #4.

"{actor} hits the Android" branch (CrewHitsAndroid continued).