Dispatched via CrewActionDispatch entry 4: a queued ATTACK order fires. The actor attacks whatever hostile shares his room — the actor's room byte (+1) is compared with each hostile's:

• 1. The actor stands in the alien's room ($737F) → CALL CrewHitsAlien — message #3 "nets the ALIEN" or #4 "hits the ALIEN".
• 2. Else, if the alien is loose (AlienActiveFlag) and the actor stands in the ANDROID's room (record via AlienTargetPtr) → CALL CrewHitsAndroid — message #31 "nets {target}" or #32 "hits the Android".
• 3. Neither hostile is here (it moved away before the countdown expired): the attack fizzles silently.

The Android role: LongGameInit randomly picks one of crew slots {1, 2, 4, 6} (Dallas / Kane / Ash / Parker) and stores it in AlienTargetID. That crew member is dormant at first — they appear and behave like a normal crew member.

UpdateAndroid turns them hostile the first frame the alien is loose and the slot is still in its template state (the "first encounter"), stamping them into action state 7 and giving them targets via NearestCrewA/B (see 37876).

After activation the Android wounds nearby crew through CrewAction7_Handler; CrewHitsAndroid here is the PLAYER-RESPONSE branch, dispatched when other crew engage the Android in combat state 4. (The Short Game hard-wires AlienTargetID = 9 and never re-points AlienTargetPtr, so branch 2 is inert there.)

After dispatch, CALL 44924 parks IX+3 (action state) and returns.