Enemy AI System Analysis

Key mechanism. bEngaged is sticky — it locks to true when entering 100 m and is released only when distance exceeds 350 m (prevents enemies from flipping state at the boundary repeatedly). bWantsAttack is written by EnemyTargetService (Random < 0.35 and cooldown done), which solves the classic problem "a persistently running pursue MoveTo starves the attack branch." EnemyCombatActionTask must clear bWantsAttack=false immediately at the top, otherwise the cooldown gate becomes a formality.

1. Level navigation system was originally disabled (enable_navigation_system=False + NullNavSysConfig) — the old 100×100 m NavMeshBoundsVolume never took effect. This task enabled it and added a large volume.
2. AutoPossessPlayer=Player0 inherited by the character Blueprint would let the PIE player controller seize the Pawn. The child Blueprint must set AutoPossessPlayer=Disabled, otherwise the AI could not be controlled by the AIC.
3. OnPossess must run RunBehaviorTree before writing the blackboard: writing before the tree starts means the blackboard is not yet assembled, and the write is silently lost (read back as FLT_MAX at runtime).
4. The persistently running pursue MoveTo starves the attack branch to its left on the same layer (a behavior tree does not rescan already-activated branches) → introduce the bWantsAttack blackboard key + the Abort=LowerPriority decorator preempt; and the BTTask must clear the key at execution start, otherwise the cooldown gate becomes the only throttle, causing an attack-rate spike and the roll to fail.
5. CharacterMovement DefaultLandMovementMode=MOVE_Flying in TransformBase (hovering-form default on the inheriting class) — when AI holds it directly, it spawns as Flying and never lands; plus the Launch after the flight action has no gravity brake → hovering at 44 m "invisible". Fix: the AI child Blueprint forces SetMovementMode(Walking) in BeginPlay (verified in PIE 105 s: C++ does not push it back).
6. Two problems in the teleport action: 1. ProjectPointToNavigation returns a zero vector on failure; the success bool branch must be taken (failure → Finish(false)); 2. when the player Pawn is out of bounds and destroyed, GetPlayerPawn=None, and reading the location returns a zero vector → projection onto the origin is judged "success" → teleported to (0,0,0). The position source must be validated.
7. The BTTask synchronous FinishExecute starves ReceiveTickAI: the attack branch originally "finishes as soon as execution is done" → Tick never runs → the 0.4 s hit decision becomes dead code. Task-style actions must rely on ActionDuration counting up to the limit before finishing.
8. The damage pipeline built into the character Blueprint only recognizes DroneTarget (the BeginOverlap of EF_BP_BezierBullet with OtherActor==DroneTarget) — the original character attack target is the drone, so no damage can be dealt to the player pawn. AI damage must be called by the AI itself (current plan: only GetPlayerPawn(0), distance ≤ 6000, naturally satisfying "damage only the character, never EnemyBlueprint").
9. Rate-limit failure root cause: the bullet spawn source never writes the cooldown variable (probe measured the value frozen for 26 s) → the entry gate became a formality → 21 shots/s crashed the GPU. Fix: call SetAttackCooldowns after spawn (now 4~7 s). Troubleshooting method: add temporary Print probes to measure the count per link; do not rely on speculation.
10. Attack and exit VFX not shown during Light Flight: 1. the attack intent is written on the same frame right after Exit in the arrival chain, so the attack runs before the 0.1+0.4 s transition; 2. when the player is 12~18 m away, arrival falls inside the enter transition window (0.4 s), and Exit is blocked by the C++ guard (SKIPPED in logs is hard proof) → stuck in Light Flight state. Fix: wait for the exit phase (poll + retry + timeout fallback) + double safety at the CombatAction entry.