fix(alarm): Disable radar alarms for USA cargo planes

[githubawn]

This PR does a hardcoded check for Cargo Planes so they do not spam a player in late matches.
This is part of the solution for #2452

Included a PRESERVE_CARGO_PLANE_ATTACK_WARNINGS if check.
Game Design Committee can choose if this needs to be the default. It slightly nerfs USA factions, as they don't get incidental notifications on where Anti-Air units are placed.

But this usually depends on the map on where the Cargo Planes follows the route, which in my opinion makes this too random to be considered a legitimate strategic feature.

While hardcoding for a specific unit might be considered a hack, it's the only way to not inadvertently break possible mods by not altering an entire unit category.

[greptile-apps]

Greptile Summary

This PR suppresses spurious radar "under attack" notifications for the USA AmericaJetCargoPlane unit by adding a hardcoded template-name guard inside Object::attemptDamage. A new PRESERVE_CARGO_PLANE_ATTACK_WARNINGS macro in GameDefines.h allows the behavior to be toggled.

• GameDefines.h: Adds PRESERVE_CARGO_PLANE_ATTACK_WARNINGS defaulting to (0) (fix active), inserted in alphabetical order alongside other PRESERVE_* flags; no committee-approval comment is present, unlike all other (0)-default siblings.
• Generals/ and GeneralsMD/ Object.cpp: Both files add an identical #if !PRESERVE_CARGO_PLANE_ATTACK_WARNINGS block that skips TheRadar->tryUnderAttackEvent when the damaged object's template name is "AmericaJetCargoPlane", placed after the existing guards (m_radarData, isLocallyControlled).

Confidence Score: 5/5

Safe to merge; the change is narrowly scoped to suppressing one radar notification for a single unit type and does not affect any other game logic.

The new guard fires only after all existing filters pass (damage dealt, not penalty/healing, radar data present, locally controlled) and adds a well-isolated template-name check. The only open question is whether the (0) default needs formal Game Design Committee sign-off before landing, which is a process concern rather than a code defect.

Core/GameEngine/Include/Common/GameDefines.h — the new macro is missing the approval comment that every other (0)-default PRESERVE macro carries.

Important Files Changed

Filename	Overview
Core/GameEngine/Include/Common/GameDefines.h	Adds PRESERVE_CARGO_PLANE_ATTACK_WARNINGS defaulting to (0); missing the approval comment that all other (0)-default PRESERVE macros carry.
Generals/Code/GameEngine/Source/GameLogic/Object/Object.cpp	Guards tryUnderAttackEvent behind a hardcoded template-name check for "AmericaJetCargoPlane"; logic is correct and well-scoped behind existing guards (m_radarData, isLocallyControlled).
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Object.cpp	Mirrors the Generals change; Zero Hour version already has the getControllingPlayer() null guard so the new code slots in cleanly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Object::attemptDamage called] --> B{actualDamageDealt > 0\nNot PENALTY or HEALING\nm_radarData != null\nisLocallyControlled}
    B -- No --> Z[Skip radar event]
    B -- Yes --> C{PRESERVE_CARGO_PLANE_ATTACK_WARNINGS == 0?}
    C -- Yes --> D{getTemplate name ==\n'AmericaJetCargoPlane'?}
    D -- Yes --> Z
    D -- No --> E[TheRadar->tryUnderAttackEvent]
    C -- No --> E

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Object::attemptDamage called] --> B{actualDamageDealt > 0\nNot PENALTY or HEALING\nm_radarData != null\nisLocallyControlled}
    B -- No --> Z[Skip radar event]
    B -- Yes --> C{PRESERVE_CARGO_PLANE_ATTACK_WARNINGS == 0?}
    C -- Yes --> D{getTemplate name ==\n'AmericaJetCargoPlane'?}
    D -- Yes --> Z
    D -- No --> E[TheRadar->tryUnderAttackEvent]
    C -- No --> E

Loading

_{Reviews (5): Last reviewed commit: "style(alarm): De-indent preprocessor dir..." | Re-trigger Greptile}

[WWB2-account]

From my perspective (which is one from modding), I think this fix is not exactly what's needed. Hardcoding it seems the wrong way to go about it. Mods can simply make the SDZ cargo plane untargettable if they want to. It's very unlikely your opponent intercepts the plane before it drops the cash anyway.

If the committee deems it absolutely necessary to have targettable SDZ planes (for the sake of distracting AA), I think a better idea is to make a system that can be applied to any object that suppresses radar alarms, like a new KindOf, then apply it to the Cargo Plane. Yes, that would be a lot of work for a single object. Yes, it would require modded to update a single object, but you've also given them an entirely new tool in their toolbox.

[Skyaero42]

Agree with @WWB2-account

People are trying to come up with a solution (I think this is the third PR that is trying to 'fix' this?) without first consulting / discussing what the preferable outcome should be: When (in the broadest sense) should an alarm be (re)fired.

[xezon]

This is a big hack indeed. It totally falls apart when the Object template name is changed.