fix(pathfinder): Remove invalid retail compatible compilation conditional

[Mauller]

This PR fixes a non retail build issue with Generals.

the KindOf enumerations changed btween Generals and Zero Hour, where some were removed and many more added.

The kinf of airfield enumeration was removed and new "Faction Structure" types were added. in it's place KINDOF_FS_AIRFIELD was introduced that deprecated KINDOF_AIRFIELD.

I am sure these are data dependent but didn't want to touch them at the moment. I already have an issue about these.

Therefore it was incorrect to also include the retail compatible pathfinding conditional with the block covering these KindOf checks.

[greptile-apps]

Greptile Summary

This PR removes an erroneous && RETAIL_COMPATIBLE_PATHFINDING guard from a single preprocessor conditional in AIPathfind.cpp, fixing a compile/logic error that caused non-retail-compatible Generals builds to incorrectly reference the Zero Hour symbol KINDOF_FS_AIRFIELD instead of the Generals symbol KINDOF_AIRFIELD.

• Root cause: The block at line 8697 previously compiled as #if RTS_GENERALS && RETAIL_COMPATIBLE_PATHFINDING, meaning only Generals builds with retail-compatible pathfinding enabled would use KINDOF_AIRFIELD; all other Generals builds fell through to the #else branch and tried to use KINDOF_FS_AIRFIELD, which does not exist in Generals.
• Fix: Changing the condition to #if RTS_GENERALS ensures every Generals build uses the correct KINDOF_AIRFIELD, while every Zero Hour build continues to use KINDOF_FS_AIRFIELD.
• The change is minimal, targeted, and consistent with how other KindOf differences are handled elsewhere in the file (many blocks already use a plain #if RTS_GENERALS / #else pattern for enum divergences between the two games).
• No behavioural change is introduced for retail-compatible Generals builds or any Zero Hour build.

Confidence Score: 5/5

• This PR is safe to merge — it is a one-line targeted fix that corrects a preprocessor guard with no risk to existing retail-compatible or Zero Hour builds.
• The change is a single-token removal (&& RETAIL_COMPATIBLE_PATHFINDING) in a preprocessor directive. The before/after semantics are clear: retail-compatible Generals builds are unaffected (they satisfied both conditions before and now satisfy the simplified one), while non-retail-compatible Generals builds are fixed to use the correct KINDOF_AIRFIELD enum. Zero Hour builds are completely unaffected. No new logic, no new allocations, no side effects.
• No files require special attention.

Important Files Changed

Filename	Overview
Core/GameEngine/Source/GameLogic/AI/AIPathfind.cpp	Single-line preprocessor fix: removes the erroneous && RETAIL_COMPATIBLE_PATHFINDING conjunction so that the Generals-era KINDOF_AIRFIELD symbol is correctly selected for ALL Generals builds, not only the retail-compatible variant.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["findClosestPath()"] --> B{goalCell on same obstacle as ignoreCell?}
    B -- No --> C[skip airfield check]
    B -- Yes --> D[findObjectByID goalCell obstacle]
    D --> E{newObstacle != nullptr?}
    E -- No --> C
    E -- Yes --> F{Compile-time: RTS_GENERALS?}
    F -- Yes\nGenerals build --> G["isKindOf(KINDOF_AIRFIELD)\n(Generals enum)"]
    F -- No\nZero Hour build --> H["isKindOf(KINDOF_FS_AIRFIELD)\n(Zero Hour enum)"]
    G -- true --> I[set goalOnObstacle = true]
    H -- true --> I
    G -- false --> J{ignoreObstacleID == obstacleID?}
    H -- false --> J
    J -- Yes --> I
    J -- No --> K[goalOnObstacle remains false]

    style F fill:#f0ad4e,color:#000
    style G fill:#5bc0de,color:#000
    style H fill:#5bc0de,color:#000

Loading

_{Last reviewed commit: "fix(pathfinder): Rem..."}

[xezon]

Perhaps write it like so:

#if RTS_GENERALS
  constexpr const KindOfType airfield = KINDOF_AIRFIELD;
#else
  constexpr const KindOfType airfield = KINDOF_FS_AIRFIELD;
#endif
  if (newObstacle != nullptr && newObstacle->isKindOf(airfield))

[Mauller]

i don't think it's needed for this change, we might be able to tweak it later when the KindOf types are checked over.
But i think some of this is baked into data, but it would need investigating further.