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. On bake it samples that region at GridSpacing, runs a clearance trace at each candidate point, and keeps the survivors.
  • 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).

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.

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.