bugfix: Only detonate Bunker Busters if the missile reaches its destination

[Stubbjax]

Closes #632 from the patch repository

This change fixes an issue where a Bunker Buster missile will trigger its detonation damage/effect on the target even if it's destroyed before reaching it. The detonation is now only triggered if the missile is destroyed by reaching its destination.

Before

The bunker buster immediately detonates on the target when zapped by the Avenger's PDL

YES_BUST.mp4

BAD_BUST.mp4

After

The bunker buster does not detonate when zapped by the Avenger's PDL

NO_BUST.mp4

[greptile-apps]

Greptile Summary

This PR fixes a bug where the Bunker Buster missile's detonation effect (bustTheBunker) was triggered when the missile was destroyed by any means, including being zapped by the Avenger's Point Defense Laser. The fix adds an early return guard in BunkerBusterBehavior::onDie() that checks for OBJECT_STATUS_MISSILE_KILLING_SELF — a status flag only set by MissileAIUpdate::detonate() when the missile reaches its destination — ensuring the bunker-busting effect only occurs on a legitimate detonation.

• The guard is wrapped in #if !RETAIL_COMPATIBLE_CRC to maintain CRC compatibility with retail clients when needed
• The same OBJECT_STATUS_MISSILE_KILLING_SELF flag is already used elsewhere in this file (line 149 in update()) for crash-through FX, so the pattern is consistent
• The fix depends on the ordering of operations in MissileAIUpdate: the flag must be set in detonate() before onDie is invoked via doKillSelfState() calling obj->kill(). This holds as long as the bunker buster's weapon INI does not use DieOnDetonate = Yes on its detonation weapon template

Confidence Score: 4/5

• This PR is a well-scoped bugfix that correctly guards the bunker busting effect behind the proper missile status check, with appropriate retail CRC compatibility wrapping.
• The fix is logically sound and uses a pre-existing status flag already used elsewhere in the same file. The #if !RETAIL_COMPATIBLE_CRC guard follows project conventions. The only minor concern is the implicit dependency on the ordering of operations in MissileAIUpdate::detonate() — specifically that OBJECT_STATUS_MISSILE_KILLING_SELF is set before onDie is invoked — which relies on the bunker buster's INI configuration not using DieOnDetonate = Yes. However, the PR author has tested this and the fix matches the established pattern at line 149.
• No files require special attention beyond confirming the INI weapon configuration.

Important Files Changed

Filename

Overview

GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Behavior/BunkerBusterBehavior.cpp

Adds an early return guard in onDie() to skip bustTheBunker() when the missile doesn't have OBJECT_STATUS_MISSILE_KILLING_SELF set, which correctly prevents detonation when the missile is destroyed by external sources (e.g., PDL zap). The fix relies on the ordering of OBJECT_STATUS_MISSILE_KILLING_SELF being set in MissileAIUpdate::detonate() before onDie is invoked, which requires the bunker buster's INI to use DetonateCallsKill = Yes with DieOnDetonate = No.

Sequence Diagram

sequenceDiagram
    participant Missile as Bunker Buster Missile
    participant MissileAI as MissileAIUpdate
    participant Body as ActiveBody
    participant BBB as BunkerBusterBehavior

    Note over Missile: Normal detonation flow
    Missile->>MissileAI: Reaches target (collision)
    MissileAI->>MissileAI: detonate()
    MissileAI->>MissileAI: Set MISSILE_KILLING_SELF
    MissileAI->>MissileAI: switchToState(KILL_SELF)
    MissileAI->>MissileAI: doKillSelfState()
    MissileAI->>Missile: obj->kill()
    Missile->>Body: attemptDamage()
    Body->>BBB: onDie()
    BBB->>BBB: testStatus(MISSILE_KILLING_SELF) = true
    BBB->>BBB: bustTheBunker() ✓

    Note over Missile: PDL zap flow (with fix)
    Missile->>Body: External damage (PDL zap)
    Body->>BBB: onDie()
    BBB->>BBB: testStatus(MISSILE_KILLING_SELF) = false
    BBB-->>BBB: return early (no detonation) ✓

Loading

_{Last reviewed commit: 6b08d93}

[tintinhamans]

While this might be technically correct - it is a nerf to an already rarely used upgrade. Wonder if this should be labeled controversial.

[Stubbjax]

While this might be technically correct - it is a nerf to an already rarely used upgrade. Wonder if this should be labeled controversial.

If we are too generous with the application of the controversial label then it will lose its potency. Do you believe this fix is likely to result in a notable impact to game balance or user experience?