Skip to content

SetFocus / SetFocalPoint / ClearFocus

At a glance

Lives in: Blueprint API / AI - Target: an AIController - SetFocus tracks: an Actor whose focus point can move - SetFocalPoint stores: one fixed world-space location - ClearFocus removes: the Blueprint Gameplay-priority focus, allowing a lower-priority focus such as path following to take over - Returns: no success value - Official docs: SetFocus, SetFocalPoint, and ClearFocus

AI focus tells an AIController where it should look. The controller uses the winning focus request to update its Control Rotation. That is only the first half of visible turning: the possessed Pawn and its movement settings still decide whether the body follows that rotation.

These nodes do not sense a target, pathfind to it, or prove line of sight. They record and clear orientation intent.

The one-minute version

  • Use SetFocus when the target is an Actor that can move. The AIController retains that Actor reference and reevaluates its focus point over time.
  • Use SetFocalPoint when the target is a fixed world location. The stored point does not follow an Actor that later moves.
  • ClearFocus removes the Gameplay-priority focus used by these Blueprint calls. It does not necessarily leave the AI with no orientation request: path following or another lower-priority system may immediately become the winner.
  • (0, 0, 0) is a real world location, not a magic "clear" value. Call ClearFocus to release focus.
  • Focus requests have priorities. The usual order is Gameplay above Move, with Default below both. A higher-priority target masks a lower one without deleting it.
  • SetFocus does not rotate the Pawn instantly in the same call. The AIController updates Control Rotation, and Pawn/Character settings consume it over later updates.
  • For a Character, decide whether the body should face controller rotation, controller-desired rotation, or movement direction. Conflicting settings make focus look broken or produce twitching.
  • AIControllers exist on the server in networked games. Run authoritative AI focus logic there; clients normally observe replicated Pawn rotation or a separate replicated aim/presentation value.
  • A Behavior Tree branch that claims focus should also release it on every exit path, including aborts. The built-in Default Focus service is often the cleanest branch-scoped owner.

The three node contracts

Node Stored request Best fit Common surprise
SetFocus Actor reference Keep looking at a moving player, enemy, or interactable The Actor can become invalid; this node does not test visibility
SetFocalPoint World-space Vector Look at a known position, sound location, or tactical point It stays fixed even if the source Actor moves
ClearFocus Removes the Gameplay slot End an attack/interaction focus A lower-priority Move or Default focus can reappear

The Blueprint calls write the AIController's Gameplay focus priority. In conceptual terms:

pseudocode - not engine source

SetFocus(TargetActor):
    FocusStack.Gameplay = TargetActor

SetFocalPoint(WorldPoint):
    FocusStack.Gameplay = WorldPoint

ClearFocus():
    FocusStack.Gameplay = empty

each controller update:
    WinningFocus = highest-priority valid focus
    ControlRotation = look from controlled Pawn toward WinningFocus
    allow the controlled Pawn to respond to that ControlRotation

There is no Boolean result. Validate the AIController and target before the call, then inspect focus, Control Rotation, and Pawn settings separately when the visible result is wrong.

Actor focus vs fixed focal point

SetFocus: follow an Actor

SetFocus stores the target Actor. As the target moves, the AIController asks for that Actor's current focal location again, so the desired look direction can keep changing without calling SetFocus every Tick.

AI Perception reports PlayerCharacter
-> SetFocus(PlayerCharacter)

PlayerCharacter moves left
-> stored focus Actor remains the same
-> controller's resolved focal point moves left
-> Control Rotation can follow

The default actor focal point is based on that Actor's world position. Native AIController subclasses can override GetFocalPointOnActor when a project needs another point, such as eye or torso height.

Set the focus again when the target reference changes, not merely because the same target moved.

If the Actor becomes invalid, it can no longer contribute a valid focus location. A lower-priority request may then become effective. That is still not a complete gameplay cleanup policy: clear the focus when the action that owned it ends, and clear or replace the related target state too.

SetFocalPoint: keep one world location

SetFocalPoint stores the Vector supplied at the time of the call:

Last Heard Location = (4200, -800, 120)
-> SetFocalPoint(Last Heard Location)
-> AI keeps looking at that world point

This is useful when there is deliberately no live Actor reference:

  • a noise location from perception;
  • the center of a door or console;
  • the last known target position;
  • a cover edge or scripted cinematic mark;
  • a point calculated by EQS.

If that point came from an Actor and the Actor moves later, the focal point does not follow. Call SetFocus instead when follow behavior is the contract.

World origin is valid:

SetFocalPoint((0, 0, 0))

means "look toward world origin." It does not clear the request. Unreal uses a separate internal invalid-location sentinel; Blueprint users should express release with ClearFocus.

Focus is a priority stack

An AIController can receive orientation requests from several systems. Focus priorities keep temporary gameplay intent from being overwritten by ordinary movement steering.

The common ordering is:

higher priority

Gameplay   SetFocus / SetFocalPoint Blueprint calls
Move       path following and Move To direction
Default    low-priority ambient/Behavior Tree default focus

lower priority

Only the highest valid request determines the focal point at a given update. Lower requests remain underneath it.

Example:

1. AI Move To starts
   Move focus = next path direction
   AI faces along the route

2. attack starts
   SetFocus(Player)
   Gameplay focus = Player
   Gameplay wins, so AI can travel while looking at Player

3. attack ends
   ClearFocus()
   Gameplay slot is empty
   existing Move focus becomes visible again
   AI turns back along the path

That final turn is expected, not evidence that ClearFocus failed.

Repeatedly calling SetFocus from several systems does not create a useful "most recent call wins" ownership model. Requests at the same priority can replace one another, while higher priorities still mask lower ones. Give focus a clear gameplay owner:

  • combat state owns Gameplay focus;
  • path following owns Move focus;
  • ambient Behavior Tree service owns Default focus.

When native code needs more layers, it can use explicit priority values. Keep custom priorities documented; an unexplained high-priority request can mask Blueprint focus for the rest of the controller's lifetime.

What ClearFocus actually clears

The Blueprint node clears the Gameplay-priority slot used by the Blueprint setters. It does not:

  • erase every focus priority;
  • stop an active Move To;
  • cancel a Behavior Tree;
  • clear a target Blackboard key;
  • disable AI Perception;
  • restore a hand-authored Actor rotation;
  • guarantee the Pawn stops turning immediately.

If path following remains active, its Move focus can take over. If a Default Focus Behavior Tree service is still relevant, that service can continue providing a lower-priority target.

For a clean state transition:

Exit Attack state
-> ClearFocus
-> clear/replace AttackTarget Blackboard key as the design requires
-> stop or replace attack logic
-> optionally start/resume a movement request

Clearing the Blackboard key alone does not promise that a focus previously set by an unrelated custom task was released. Likewise, clearing focus does not clear the Blackboard.

From focus to visible body rotation

This is the debugging chain:

valid focus request
-> AIController resolves a world focal point
-> AIController updates Control Rotation
-> controlled Pawn receives that desired rotation
-> Pawn / Character Movement settings decide visible Actor rotation
-> mesh animation may add a separate aim/look offset

Check the chain in that order.

Control Rotation is not automatically Actor Rotation

Control Rotation belongs to the Controller. The Pawn decides how to use it. A Pawn subclass can implement its own FaceRotation behavior. Character adds movement-orientation settings that make several common designs possible.

Important Character choices include:

  • Use Controller Rotation Yaw on the Pawn/Character: lets controller yaw directly drive the Character's facing through the Pawn rotation path.
  • Use Controller Desired Rotation on Character Movement: rotates toward controller desired rotation using Character Movement's Rotation Rate.
  • Orient Rotation to Movement on Character Movement: rotates toward acceleration/movement direction instead.
  • Rotation Rate: limits how quickly Character Movement turns when it owns rotation.

Do not enable every strategy and hope one wins. Orient Rotation to Movement and controller-desired facing express competing owners.

Common configuration: face where the AI walks

For a simple patrol enemy:

Use Controller Rotation Yaw       = false
Use Controller Desired Rotation   = false
Orient Rotation to Movement       = true

The Character faces its movement direction. Focus can still change controller aim state, but it may not rotate the body visibly because movement orientation owns body yaw.

Common configuration: strafe while watching a target

For an enemy that moves around a target while facing it:

Use Controller Rotation Yaw       = false
Use Controller Desired Rotation   = true
Orient Rotation to Movement       = false
Rotation Rate                     = tuned for desired turn speed

SetFocus(TargetActor) during combat

Character Movement then turns toward the controller's desired yaw while movement can travel in another direction. Project-specific movement modes and root motion can still alter this result.

Some projects instead use direct controller yaw on the Pawn. Choose that deliberately when its immediate Pawn-facing semantics fit better than Character Movement's rotation-rate path.

Mesh aim is another layer

Even when the capsule/Actor faces correctly, a weapon or head may not point at the target. Conversely, an Aim Offset can make the upper body look correct while the capsule faces elsewhere.

Mesh presentation commonly needs:

  • a local yaw/pitch difference between aim rotation and Actor rotation;
  • clamped and smoothed aim variables;
  • an Aim Offset or layered animation pose;
  • socket alignment and the actual weapon trace direction.

SetFocus supplies controller intent; it does not configure an Animation Blueprint or guarantee the muzzle trace matches the pose. See Aim Offsets and look/aim variables.

Behavior Tree ownership

Focus should normally live for exactly as long as the Behavior Tree branch or gameplay state that requested it.

Default Focus service

The built-in Default Focus service reads a selected Blackboard entry and maintains low-priority focus while its branch is relevant. It releases its contribution when it stops being relevant.

This is a good fit for:

Combat selector branch
|-- Service: Default Focus (TargetActor key)
|-- Move/strafe task
`-- attack task

Because it uses Default priority, a Gameplay focus request can temporarily override it. When the gameplay request clears, the service's target can become effective again.

Custom tasks and services

If a custom task calls SetFocus, it owns the matching ClearFocus. Account for every exit:

  • normal success;
  • normal failure;
  • decorator-driven abort;
  • target invalidation;
  • tree shutdown or controller cleanup.

An event-driven setup is usually enough:

target acquired or branch entered -> SetFocus once
target replaced                   -> SetFocus(new target)
branch exited or target lost      -> ClearFocus

A service that calls SetFocus every Tick for the same Actor adds noise but does not make Actor focus track better; the controller already reevaluates a stored Actor target.

Use the built-in Rotate to Face BBEntry task when the behavior should wait until the Pawn has turned toward one Blackboard Actor or Vector before the tree continues. That is a turn-to-completion task, not a permanent replacement for focus ownership during a long combat branch.

Focus is not perception, line of sight, or movement

SetFocus(Target) accepts orientation intent. It does not ask whether:

  • AI Perception currently senses the target;
  • a wall blocks line of sight;
  • the target is hostile;
  • the target is inside an attack cone;
  • a navigation path reaches it;
  • the weapon can hit it.

A typical decision flow is:

AI Perception update
-> validate sensed actor and team
-> write Blackboard target
-> Behavior Tree selects chase/attack branch
-> branch owns SetFocus or Default Focus
-> separate Move To owns navigation
-> separate trace/range/angle test validates attack

Do not use "the AI is focused on it" as proof that firing is valid. Focus can continue toward an occluded Actor until gameplay clears or replaces it.

Likewise, SetFocalPoint does not move the Pawn to that point. Pair it with an AI movement request when both travel and look direction are wanted.

Failure and diagnosis

The nodes return no success flag, so debug the layers explicitly.

Nothing turns

  1. Confirm the target is an AIController. Calling from an AIController Blueprint commonly uses self; calling from a Pawn requires Get Controller and a valid AIController cast.
  2. Confirm possession. The AIController needs a controlled Pawn.
  3. Validate the focus Actor. None, pending-destruction, or destroyed targets cannot supply a useful live location.
  4. Print the controller's focal point and Control Rotation. If they change, the focus layer is working.
  5. Inspect body rotation settings. Decide between controller rotation, controller-desired rotation, and movement orientation.
  6. Check Rotation Rate. A zero or unsuitable rate can make a Character-Movement-owned turn appear frozen or extremely slow.
  7. Check higher-priority native focus. A project system may be masking the Blueprint Gameplay slot.
  8. Check motion owners. Root motion, custom movement, animation, or another Tick-driven rotation write can overwrite the visible result.
  9. Check the machine. A client normally has no AIController to run this logic on.

The AI turns back after ClearFocus

Inspect active Move To/path following and Default Focus services. A lower-priority request becoming visible is the expected priority behavior.

The AI tracks an old target

Find the system that owns Gameplay focus. Verify it clears on abort as well as success, and that another task/service is not immediately setting the old reference again. Clear or update related Blackboard state separately.

The AI jitters between directions

Look for competing owners:

  • two gameplay systems setting focus at the same priority;
  • a service setting one target while a task sets another;
  • Orient Rotation to Movement competing with controller-desired rotation;
  • Blueprint Set Actor Rotation running alongside Character Movement;
  • replicated correction fighting client-local rotation;
  • an animation layer presenting a different aim than the capsule.

Give one system ownership for each layer instead of adding more repeated rotation writes.

Multiplayer

AIControllers are authority-side gameplay objects in networked play. Ordinary remote clients do not have the server's AIController instance, focus stack, or Behavior Tree.

The usual flow is:

server:
    perception / Behavior Tree
    -> SetFocus
    -> update AI Control Rotation
    -> move/rotate authoritative Pawn

clients:
    receive supported replicated Pawn movement/rotation
    -> render Character and animation

SetFocus is not an RPC and does not replicate the target Actor or focal point by itself. Calling it on a client cannot steer the absent authoritative AIController.

If clients need more than body rotation for presentation—such as head aim, turret pitch, gaze target, or a telegraph—replicate the minimal gameplay or presentation state explicitly:

  • replicated aim yaw/pitch;
  • replicated target reference when visibility rules permit it;
  • replicated world aim point;
  • replicated attack state from which clients derive animation.

Do not replicate Control Rotation or focal point every Tick by reflex. Choose the smallest stable state, respect actor relevancy, and let clients smooth presentation where appropriate. Server traces and damage must still use authoritative aim/gameplay state.

Practical patterns

Track a perceived target during combat

server AIController
-> On Target Perception Updated
-> if successfully sensed and target is valid/hostile:
       Blackboard.TargetActor = Actor
       SetFocus(Actor) when combat state claims Gameplay focus
   else if Actor is current combat target:
       ClearFocus
       clear or replace Blackboard.TargetActor

If the Behavior Tree's Default Focus service owns the target, update the Blackboard key and let the service manage its lower-priority focus instead of also writing Gameplay focus.

Look at a last-known position

target lost
-> LastKnownLocation = perception stimulus location
-> SetFocalPoint(LastKnownLocation)
-> start investigate movement/state
-> on investigation complete or abort:
       ClearFocus

Do not feed an Actor's current location once and expect the point to follow that Actor.

Native equivalent

The C++ twin, for the curious (our own example code):

void AExampleAIController::BeginCombatFocus(AActor* TargetActor)
{
    if (!IsValid(TargetActor) || GetPawn() == nullptr)
    {
        ClearFocus(EAIFocusPriority::Gameplay);
        return;
    }

    SetFocus(TargetActor, EAIFocusPriority::Gameplay);
}

void AExampleAIController::EndCombatFocus()
{
    ClearFocus(EAIFocusPriority::Gameplay);
}

Native code can choose an explicit priority. Blueprint's three nodes expose the ordinary Gameplay-priority path.

What these nodes do not do

They do not:

  • acquire or validate an enemy;
  • run AI Perception or test line of sight;
  • move the Pawn or start pathfinding;
  • wait until the Pawn finishes turning;
  • guarantee an instant visible Actor rotation;
  • configure Pawn or Character Movement rotation settings;
  • configure Aim Offset, head look, turret, or weapon animation;
  • clear Blackboard keys or stop a Behavior Tree;
  • remove every lower-priority focus request;
  • replicate the focus target, focal point, or AIController to clients;
  • prove an attack trace will hit the focused Actor.

Nearby lookalikes and follow-ups

Go deeper

For implementation archaeology, start with:

  • Engine/Source/Runtime/AIModule/Classes/AIController.h - focus priorities, Actor/point setters, focal-point access, and update declarations;
  • Engine/Source/Runtime/AIModule/Private/AIController.cpp - priority resolution and UpdateControlRotation;
  • Engine/Source/Runtime/AIModule/Private/BehaviorTree/Services/BTService_DefaultFocus.cpp - service activation, Blackboard tracking, and cleanup;
  • Engine/Source/Runtime/AIModule/Private/BehaviorTree/Tasks/BTTask_RotateToFaceBBEntry.cpp - task setup and turn completion.

Source files move across engine versions. Search for the class or function name when a path differs in your checkout.