feat(object): Implement KINDOF_NO_ATTACK_WARNING to suppress alarm events on object attacks

[githubawn]

This PR introduces the KINDOF_NO_ATTACK_WARNING flag. Assigning this KindOf to a unit prevents it from triggering EVA or Radar notifications for the player.

[greptile-apps]

Greptile Summary

This PR adds a new KINDOF_NO_ATTACK_WARNING flag that suppresses the radar/EVA "under attack" notification for any unit tagged with it, implemented symmetrically in both the base Generals/ and GeneralsMD/ (Zero Hour) trees.

• KindOf.h / KindOf.cpp (both trees): KINDOF_NO_ATTACK_WARNING is inserted correctly before KINDOF_COUNT, and its string name "NO_ATTACK_WARNING" is appended to s_bitNameList; the existing static_assert on array size will catch any mismatches at compile time.
• Object.cpp (both trees): A single !isKindOf(KINDOF_NO_ATTACK_WARNING) guard is added as the final condition before TheRadar->tryUnderAttackEvent(this), so actual damage still applies but the radar/EVA alarm is silenced for flagged units.

Confidence Score: 5/5

Safe to merge — the change is minimal, self-contained, and validated by the existing static_assert on the KindOf name array.

All six changed files receive symmetrical, correctly ordered edits: the enum value lands before KINDOF_COUNT, the string name lands before the nullptr sentinel (compile-time size check guards this), and the condition guard in Object.cpp suppresses only the notification while leaving damage intact. No pre-existing invariants are broken.

Files Needing Attention: No files require special attention.

Important Files Changed

Filename	Overview
Generals/Code/GameEngine/Include/Common/KindOf.h	Adds KINDOF_NO_ATTACK_WARNING enum value before KINDOF_COUNT with a Doxygen comment; placement and style are consistent with the surrounding block.
Generals/Code/GameEngine/Source/Common/System/KindOf.cpp	Appends "NO_ATTACK_WARNING" to s_bitNameList before the nullptr sentinel; compile-time static_assert will validate array size parity.
Generals/Code/GameEngine/Source/GameLogic/Object/Object.cpp	Adds !isKindOf(KINDOF_NO_ATTACK_WARNING) as final guard before tryUnderAttackEvent; damage application is unaffected, only the notification is suppressed.
GeneralsMD/Code/GameEngine/Include/Common/KindOf.h	Mirrors the Generals/ header change symmetrically for Zero Hour.
GeneralsMD/Code/GameEngine/Source/Common/System/KindOf.cpp	Mirrors the Generals/ KindOf.cpp change symmetrically for Zero Hour.
GeneralsMD/Code/GameEngine/Source/GameLogic/Object/Object.cpp	Mirrors the Generals/ Object.cpp guard change for Zero Hour; this version already has an additional getControllingPlayer() null-guard that the Generals/ version lacks (pre-existing difference).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Object::attemptDamage called] --> B[body->attemptDamage - apply actual damage]
    B --> C{actualDamageDealt > 0?}
    C -- No --> Z[Return]
    C -- Yes --> D{damageType != PENALTY and != HEALING?}
    D -- No --> Z
    D -- Yes --> E{Not friendly fire?}
    E -- No --> Z
    E -- Yes --> F{m_radarData != nullptr?}
    F -- No --> Z
    F -- Yes --> G{isLocallyControlled?}
    G -- No --> Z
    G -- Yes --> H{isKindOf KINDOF_NO_ATTACK_WARNING?}
    H -- Yes: NEW CHECK --> Z
    H -- No --> I[TheRadar->tryUnderAttackEvent - EVA + Radar alarm fires]

Loading

_{Reviews (9): Last reviewed commit: "update comment" | 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.

[xezon]

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.

I agree with this approach for this problem.

Vote for close.

[Skyaero42]

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.

I agree with this approach for this problem.

Vote for close.

Agree

[githubawn]

I can rework this with the new KindOf approach.

[githubawn]

Reworked PR

[Skyaero42]

a) this requires changes to the ini, which won't be distributed in our retail release, hence problem still persists.
b) this solution only offers an on/off option, not a reduced option. For example a spectre will still trigger high amounts of alerts.

I stick by my original comment: a solution cannot be formulated if the desired outcome is not clear.

[githubawn]

@Skyaero42 Agree that this wasn't the fix for alarm spamming. That's why I rewrote the entire PR into a feature that modders can use if they want to create even more stealthy units.