bugfix(weapon): Fix missing Aurora Alpha second explosion on structures

[Okladnoj]

SupW_AuroraFuelBombWeapon has no MissileCallsOnDie in INI, so getDieOnDetonate() returns false and
MissileAIUpdate::detonate skips the attemptDamage call that runs the projectile's die modules. The
second explosion never happens when the target is a structure.

The fix belongs in the game data (MissileCallsOnDie = Yes), which does not live in this repository, so
the flag is forced for that one weapon in WeaponStore::newWeaponTemplate, behind
PRESERVE_MISSING_AURORA_SECOND_EXPLOSION. Retail builds keep the old behaviour either way.

I defaulted the toggle to 0 so the fix is active in non-retail builds — happy to flip it to 1 if the Game
Design Committee should decide first.

On a general engine fix instead: MissileCallsOnDie is opt-in and most weapons ship without it. Calling
attemptDamage for every detonating projectile would fire die modules across the whole arsenal — extra FX,
CreateObjectDie spawns shifting every following ObjectID, SlowDeathBehavior keeping projectiles alive.
That is long-standing behaviour a lot of content relies on, and no CI covers it: the retail replay job
builds with RETAIL_COMPATIBLE_CRC=1 and would not even compile the branch, while a cross-platform run
only proves both sides computed the same thing, not the right thing. Happy to open a separate issue for it.

This also matters for macOS/Windows parity: the client used for cross-platform determinism testing forces
the same flag, so without it the two builds desync on any replay containing an Aurora Alpha.

Todo:

• Replicate to Generals — N/A, Aurora Alpha and MissileCallsOnDie are Zero Hour only
• vc6 retail replay CI: 0 errors on 10 retail 1.04 replays
• Cross-platform replay run macOS/Windows: all compared frames match

[Skyaero42]

Considering this is a data issue, I think the fix belongs in Patch2 @Stubbjax rather than a hack in the code.

[xezon]

I agree with Skyaero. We do some hacks for UI, but not these kind of hacks for gameplay bugs. We will fix them in INI instead.

[githubawn]

The core issue is broader than just Patch2. Because the retail Aurora Alpha omitted MissileCallsOnDie = Yes, any custom mod weapon inspired by or copy-pasted from it over the last 20 years inherited the exact same bug once the deterministic math pr gets merged.

[xezon]

I think key is

This also matters for macOS/Windows parity: the client used for cross-platform determinism testing forces
the same flag, so without it the two builds desync on any replay containing an Aurora Alpha.

Need to understand why.

[xezon]

I do not understand what the root problem is from the given description. My impression right now is if MissileCallsOnDie is not called then something else happens and that causes cross play mismatch. Is that right? If yes, what is it and can we fix it?

[Okladnoj]

I do not understand what the root problem is from the given description. My impression right now is if MissileCallsOnDie is not called then something else happens and that causes cross play mismatch. Is that right? If yes, what is it and can we fix it?

That from your's repo
https://github.com/GeneralsOnlineDevelopmentTeam/GameClient/blob/fe65574f3aad4bc4a3a897bfc205db79cd6397bd/GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Weapon.cpp#L1696

[xezon]

That is Generals Online Repo.

[Okladnoj]

That is Generals Online Repo.

After all, our ultimate goal is to unite GOD-Team and TSH. If we are talking about determinism in this broader context, shouldn’t we be targeting the GO services? We’ll have to take this Aurora implementation and do something with it anyway. It would be better to make everything a little more synchronized now, ahead of the future merge. This hack will also serve as a reminder of where the set of INI files still needs to be improved.

[xezon]

Can you explain what the cross play bug with MissileCallsOnDie is, if anything?

[githubawn]

GO allows more hacks compared to TSH considering one has a live service to run and the other has 20 years of backwards compatibility to consider. (I actually have a test port of "TSH on GO" running locally right now that only includes the networking changes, zero gameplay changes).

Instead of looking at this as a data/INI issue, I want to ask: is there a truly fundamental fix we could apply to this in-engine that doesn't involve hardcoding exceptions or altering how the data structure is read?"