…m change [WIP]

When the Overlord moves, containReactToTransformChange() triggers
redeployOccupants() which repositions riders via bone queries. On POSIX,
W3D bone queries (getMultiLogicalBonePosition) return wrong world coords,
placing the Propaganda Tower at an incorrect position for that frame.

If PropagandaTowerBehavior::update() runs in that same frame, doScan()
uses the wrong position and finds no allies in range. It clears
m_insideList, stopping healing for up to scanDelayInFrames frames (~3s).

Fix: override containReactToTransformChange() to immediately correct
the portable's position after the base-class bone-based placement.
Also refactor position sync into syncPortablePosition() private method
shared by update() and containReactToTransformChange().

GeneralsX @BugFix copilot 19/04/2026 Propaganda Tower scan uses wrong position after Overlord move

…s from exiting [WIP]

When DISABLED_HELD was cleared on Gatling/Propaganda Tower portables,
their locomotors became active. TransportAIUpdate::privateAttackPosition
forwards attack commands to all passengers including portables. With an
active locomotor, portables receiving an aiAttackPosition on empty ground
would try to move to the target, exit the Overlord's contain list, and
disappear permanently.

HelixContain explicitly keeps DISABLED_HELD on its portables and they
still fire and function correctly. The upstream code (TheSuperHackers)
never clears DISABLED_HELD for portables either.

The real fix for portables not working on POSIX was the position sync
introduced in the previous commit (containReactToTransformChange /
syncPortablePosition). The clearDisabled was unnecessary and harmful.

GeneralsX @BugFix copilot 19/04/2026 Overlord portables disappear on force-attack-position

…verlord [WIP]

On Windows/VC6, DISABLED_HELD caused getCurLocomotor() to return null
in TransportContain::isSpecificRiderFreeToExit(), which naturally blocked
portables (Gatling, Propaganda Tower) from ever exiting their container.

On POSIX the locomotor pointer remains valid even when the object is HELD,
so portables could pass the exit check and leave the Overlord when receiving
aiForceAttackObject or aiAttackPosition commands (e.g., Ctrl+force-attack).

Fix: override isSpecificRiderFreeToExit() in OverlordContain to return FALSE
for any KINDOF_PORTABLE_STRUCTURE. Portables are permanent upgrades — they
must never leave the Overlord under any circumstances while it is alive.

GeneralsX @BugFix copilot 19/04/2026 Portables exit Overlord on force-attack

AIExitInstantlyState::onEnter() calls exitObjectViaDoor(obj, DOOR_1)
directly without checking reserveDoorForExit, completely bypassing the
isSpecificRiderFreeToExit guard added in the previous commit.

The Gatling Cannon disappears on force-attack to empty terrain because:
  1. AI enters AI_ATTACK_POSITION state
  2. AttackStateMachine uses ContinueState for CHASE_TARGET (portable can't move)
  3. ContinueState exits with FAILURE -> EXIT_MACHINE_WITH_FAILURE
  4. AI_EXIT_INSTANTLY is triggered
  5. AIExitInstantlyState::onEnter() calls exitObjectViaDoor(DOOR_1) directly

The Propaganda Tower never hits this path since it has no weapons and
never enters attack states.

Override exitObjectViaDoor in OverlordContain to unconditionally reject
exit requests for KINDOF_PORTABLE_STRUCTURE, covering both the normal
(AIExitState via reserveDoorForExit) and instant-exit paths.

Instrumentation added during investigation of issue #95 (Gatling
force-attack exit bug). Silenced via early return in
logOverlordPortableEvent() to avoid log noise in production.

To re-enable: remove the 'return;' at the top of
logOverlordPortableEvent() in OverlordContain.cpp (GeneralsMD).
Search for GX_OVERLORD_TRACE to locate all call sites.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>