Skip to main content

How It Works

A short tour of the architecture so the tuning and troubleshooting pages make sense.

The pieces​

  • BP_DroneNavVolume — defines a region of airspace (position/rotate the actor; the box is its root). On bake it samples that region at its own GridSpacing, runs a clearance trace at each candidate point, and keeps the survivors. Density is per volume, so you can mix dense and sparse regions.
  • BP_DroneNavManager — the single graph owner. It pulls every volume's node positions into one array, links neighbours into a graph, runs A* path queries, and bakes/loads the graph.
  • BP_DronePathFollowerComponent — lives on the drone. Requests a path, then walks it with inertia, local obstacle avoidance, and smoothing.
  • BP_AIDrone + BP_AIDroneController + BT_AIDrone — the body and the brain. The controller runs the behavior tree; the drone executes movement and facing through the BPI_ControllableDrone interface.

The graph is fully data-based — nodes are struct entries in an array, not actors — so it scales to dense 3D grids.

Build / bake flow​

Volumes generate candidate nodes → the manager aggregates and links them → the result is baked into a data asset → at runtime the manager loads the baked graph (no generation spike).

Each node carries the connection reach derived from its source volume's GridSpacing, and two nodes link when they're within the larger of their two reaches (and the path between them is clear). That's what lets a dense volume and a sparse volume abut and stitch into one continuous graph — no global setting to keep in sync, and the √3 connectivity floor is enforced automatically per volume.

Runtime path request​

The brain asks the body to move; the body asks the manager for a path; the manager snaps the start/goal onto the nearest graph nodes, runs A*, simplifies and smooths the result, and hands back a list of points the follower flies through.

Patrol is the exception

The Patrol state flies the assigned spline directly and skips this path request — the nav graph isn't consulted (local avoidance still runs as a safety net). See Patrol.

The brain (behavior tree)​

BT_AIDrone is a priority selector:

  1. Chase — target is visible: move to a hover spot near it at chase speed.
  2. Search — target just lost: commit to the last-known location and look for it (see below).
  3. Patrol — no target: follow the assigned patrol spline (see Patrol).
  4. Idle — fallback.

The brain only ever commands the body through the BPI_ControllableDrone interface (move, set focus, set speed mode, follow waypoints, stop), so the drone stays "dumb" and reusable.

Who the drone targets (friend or foe)​

The controller acquires a target only when two conditions hold:

  1. CanSpotEnemies? is true — a master switch on the controller. Turn it off and the drone ignores everything and just patrols (used by the example map's "Toggle Targeting" button).
  2. The sensed actor is an enemy — meaning it is a Character (or subclass) and does not carry the controller's FriendlyTag (a Name, default Team A).

So the rule is "hunt un-tagged Characters." Mark your player, allied NPCs, or anything else that should be spared by giving it the FriendlyTag; non-Character actors (props, pickups, other drones) are never hostile, so the level's scenery needs no tags. Because AIPerception is edge-triggered, changing a tag or the switch on something already in view triggers a re-sense so the change takes effect immediately.

Search: losing and looking for the target​

When the drone loses line of sight to its chase target it doesn't just teleport back to patrol — it investigates:

  1. It flies to the last-known location (snapped to a clearance-safe nav node so it never parks inside a wall).
  2. On arrival it hovers and sweeps its facing left and right, scanning the area to try to reacquire the target.
  3. If it sees the target again, it drops straight back into Chase.
  4. If it doesn't, it gives up after MemoryDuration seconds and returns to Patrol at the nearest point on its route.

This whole behaviour is owned by the Search state and tuned with a handful of variables (MemoryDuration, plus the scan's ScanYawRange / ScanYawSpeed / ScanLookDistance), each documented in its in-editor tooltip.

tip

Next: the Blueprint Reference lists each blueprint's key properties, and Tuning covers the few settings that actually matter.