Skip to content

Add Controller Yaw/Pitch Input / Set Control Rotation

At a glance

Add-node target: Pawn · Set-node target: Controller · Returns: execution only — no value and no success Boolean · Incremental input can quietly do nothing when: the Pawn has no Controller, its Controller is not a local PlayerController, or look input is ignored · Absolute assignment: changes the targeted Controller copy immediately and does not obey the look-input gate · Official pages: Add Controller Yaw Input, Add Controller Pitch Input, and Set Control Rotation

These nodes write the Controller's aim/view orientation. They do not all write it the same way: the Add nodes submit this frame's local-player look input, while Set Control Rotation replaces the complete rotation with one absolute value.

The one-minute version

  • Add Controller Yaw Input and Add Controller Pitch Input start from a Pawn, find that Pawn's Controller, require it to be a local PlayerController, and add to the PlayerController's pending rotation input.
  • The PlayerController consumes that pending input during its rotation update. Its camera manager can clamp the view, then the Controller's Control Rotation is updated. The Add nodes are therefore input requests, not absolute setters.
  • Set Control Rotation targets a Controller directly and assigns the whole Rotator now. It can target a player or artificial intelligence (AI) Controller and does not require that Controller to possess a Pawn.
  • A valid unpossessed Pawn, a Pawn controlled by AI, or a remote Pawn copy can run an Add node and get no visible result. The node has no failure pin.
  • Set Ignore Look Input blocks the incremental PlayerController input path. It does not block Set Control Rotation.
  • With Enhanced Input, the Action value has already passed through its mapping modifiers. Mouse delta normally represents motion this frame; stick input normally represents a held rate and needs one Delta Seconds multiplication.
  • The old PlayerController InputYawScale and InputPitchScale still describe the Add-node contract, but UE 5.8 marks them deprecated and only applies them when legacy input scales are enabled. Prefer Enhanced Input Scalar modifiers for current projects.
  • Control Rotation is not Pawn Actor Rotation, Base Aim Rotation, final camera rotation, or mesh facing. Project settings decide which systems follow it.
  • In multiplayer, local look input belongs on the owning client. None of these calls is an RPC that automatically updates every machine.

The relationship the node names hide

flowchart LR
    Action[Enhanced Input IA_Look] --> PawnAdd[Pawn Add Controller Yaw/Pitch Input]
    PawnAdd -->|local PlayerController only| Pending[PlayerController RotationInput]
    Gate[Ignore Look Input] --> Pending
    Pending --> Update[PlayerController UpdateRotation]
    Update --> Control[Controller Control Rotation]
    Absolute[Set Control Rotation] --> Control
    Control --> Aim[Pawn Base Aim policy]
    Control --> Camera[Optional spring-arm/camera follow]
    Control --> Body[Optional Pawn body follow]

The last three arrows are policies, not guaranteed side effects. A spring arm may use Pawn Control Rotation while a Character still turns toward movement. That is a normal third-person setup.

What the Add nodes actually do

Both Add nodes use the Controller attached to their Pawn target. They accept a single float and submit it only when that Controller is a local PlayerController:

pseudocode — not engine source

Pawn.AddControllerYawInput(Value):
    if Pawn.Controller is a local PlayerController:
        PlayerController.AddYawInput(Value)

Pawn.AddControllerPitchInput(Value):
    if Pawn.Controller is a local PlayerController:
        PlayerController.AddPitchInput(Value)

PlayerController.AddYaw/PitchInput(Value):
    if look input is not ignored:
        apply the active PlayerController input-scale policy
        accumulate Value in this frame's RotationInput

later in PlayerController.UpdateRotation(DeltaSeconds):
    combine current Control Rotation with accumulated RotationInput
    let PlayerCameraManager process and limit the view rotation
    SetControlRotation(processed rotation)
    offer the new rotation to the possessed Pawn's facing policy

Three consequences matter:

  1. Possession is part of the path. The Add node does not search for a PlayerController. It uses the Controller already assigned to that Pawn.
  2. Locality is part of the path. A server-side PlayerController for a remote network player is not that machine's local PlayerController, so the Pawn Add node does not impersonate the remote player's hardware input.
  3. The input is accumulated. Reading Control Rotation immediately after the Add node in the same graph can still show the pre-update value. Read it after the PlayerController rotation update when same-frame ordering matters.

Val = 0 simply adds no rotation. Positive/negative yaw normally turn in opposite horizontal directions; pitch sign depends on the project's mapping and inversion policy.

What Set Control Rotation actually does

Set Control Rotation does not start from a Pawn. Its Target pin is the exact Controller whose stored rotation should be replaced:

pseudocode — not engine source

Controller.SetControlRotation(NewRotation):
    Controller.ControlRotation = NewRotation

    if the Controller has a root component using absolute rotation:
        rotate that root component to match

For the usual Pawn graph, make the relationship explicit:

Pawn
-> Get Controller
-> Is Valid
-> Set Control Rotation(complete desired Rotator)

This is an immediate absolute assignment. It does not:

  • add onto the current value unless you do that math first;
  • require a local PlayerController;
  • consult Set Ignore Look Input;
  • run the normal PlayerCameraManager pitch-limit pass for this call;
  • guarantee that a Pawn body or camera follows; or
  • send the new value to other machines as an RPC.

It can therefore be correct for a spawn-facing reset, an AI controller, a lock-on snap, or a deliberate camera recenter. It is usually the wrong node for raw mouse/stick input because it bypasses the input accumulator and can fight the next normal PlayerController update.

Enhanced Input values, sensitivity, and Delta Seconds

The Add nodes receive a float; they do not know whether it came from a mouse, stick, touch surface, or scripted graph. Decide what that float means before it reaches the node.

Source Typical Action value meaning Common conversion before Add
Mouse X/Y Device movement accumulated for this frame Apply mouse sensitivity; normally do not multiply by Delta Seconds again.
Gamepad stick Held deflection, usually -1..1 after dead zone/curve Multiply by degrees-per-second and Delta Seconds once.
Enhanced Input value with Scale By Delta Time Modifier already made the value time-scaled Do not multiply by Delta Seconds a second time.
Scripted recenter / target rotation An absolute desired orientation Use Set Control Rotation or an interpolation toward it, not a fake input rate.

A clean setup either uses separate mouse/stick Actions or gives each mapping the modifiers that turn its device value into the intended degrees for this frame. Then the event graph remains simple:

IA_Look (Axis2D, Triggered)
-> Break Vector2D
-> Add Controller Yaw Input(X shaped for this frame)
-> Add Controller Pitch Input(Y shaped/inverted for this frame)

If a stick turns twice as far at 30 frames per second as at 120, Delta Seconds is probably missing. If a mouse becomes unusually slow at high frame rate, mouse delta may have been multiplied by Delta Seconds unnecessarily. If both feel wrong, check whether a mapping modifier and the Blueprint graph both applied sensitivity or time scaling.

The legacy PlayerController scales

Epic's Blueprint pages state that yaw/pitch input is multiplied by InputYawScale / InputPitchScale. In UE 5.8 those PlayerController properties are deprecated. UInputSettings::bEnableLegacyInputScales controls whether the old scales participate; their own deprecation message routes current Enhanced Input projects to a Scalar modifier instead.

Do not unknowingly stack:

Enhanced Input Scalar sensitivity
× Blueprint sensitivity multiply
× enabled legacy PlayerController scale

That produces a real result, but makes sensitivity difficult to reason about and can apply inversion twice. Choose one owned sensitivity path.

Pitch limits and Rotator normalization

In the normal local-player path, APlayerController::UpdateRotation gives the PlayerCameraManager a chance to process view rotation. The base camera manager uses view limits such as ViewPitchMin and ViewPitchMax, so accumulated pitch input normally cannot keep flipping the camera over.

Set Control Rotation is lower-level. Do not rely on that setter call to apply your camera manager's pitch policy. For an absolute assignment:

  1. build a finite Rotator;
  2. normalize/wrap yaw according to the project's policy;
  3. clamp pitch deliberately when this is a player view; and
  4. decide what to do with roll (usually zero for a first character).

Angles outside a familiar display range can still represent equivalent orientations, but unbounded values make comparisons and interpolation harder. Use normalized angle math when calculating the shortest turn.

Control Rotation is not body, aim, or camera rotation

Rotation Owner / policy Why it can differ
Control Rotation Controller Input or AI intent. These nodes write this value.
Actor Rotation Pawn root/body Character Movement or Pawn flags decide physical facing.
Base Aim Rotation Pawn virtual aim policy Can use controller/view state and replicated remote pitch.
Camera rotation PlayerCameraManager / active camera path Camera lag, view targets, shakes, and custom camera code can modify the final view.
Mesh/bone rotation Skeletal Mesh / Animation Blueprint Aim offsets, root motion, and imported orientation can change presentation.

For an orbiting adventure camera, the spring arm can follow Control Rotation while the Character uses Orient Rotation to Movement. For a strafe shooter, the Character can use Use Controller Rotation Yaw so its body follows aim. Changing look input does not choose between those designs.

Multiplayer: which machine should write it?

PlayerControllers exist on the server and on their owning client, but a client does not receive usable PlayerControllers for other players. The safe beginner split is:

Machine / copy Expected use
Owning client Read local Enhanced Input and call Add Controller Yaw/Pitch Input on its locally controlled Pawn.
Server Receive the owning player's normal movement/view updates and validate gameplay that depends on aim; set server AI Controller rotation/focus.
Other client Animate a remote Pawn from Pawn/replicated aim state, not by finding that player's Controller.

Set Control Rotation only mutates the Controller object on the machine where the call runs. The ordinary player movement/view path communicates the pieces Unreal needs for networked Pawn simulation, but an arbitrary setter is not a multicast. If a mechanic needs an exact public aim target or facing state, make the server own that gameplay value and replicate an explicit compact presentation value as needed.

Do not send raw mouse deltas to the server merely to replay these Add nodes. Send the gameplay request the server must validate, and use the project's movement/aim representation for authoritative results.

When they fail (and what failure does)

Situation Add Yaw/Pitch result Set Control Rotation result
Target reference is None Blueprint reports an invalid-reference runtime error; the call is skipped. Same for a None Controller target.
Valid Pawn has no Controller Quiet no-op; execution continues. Not applicable until you obtain a Controller target.
Pawn has an AIController Quiet no-op because it is not a local PlayerController. A valid AIController can be assigned an absolute Control Rotation.
Pawn has a non-local PlayerController on this machine Quiet no-op. The targeted Controller copy is changed locally; no automatic cross-machine call occurs.
Look input is ignored PlayerController does not accumulate the Add request. Setter still assigns because it is not input.
Value is zero No incremental change. A zero Rotator is a real absolute orientation and is assigned.
Camera/body does not move Control Rotation may still have changed; follow/facing settings own the visible result. Same.
Setter is immediately "undone" Not applicable. The next input/camera/AI update may overwrite the absolute value.

All three nodes have only execution output. A completed white execution wire means the Blueprint call returned, not that a local controller accepted input, that a camera moved, or that another machine received anything.

The pattern everyone actually uses

For player look:

Owning Pawn / PlayerController receives IA_Look
-> Action mappings apply dead zone, curve, inversion, and sensitivity
-> mouse path supplies per-frame delta
-> stick path supplies rate × Delta Seconds
-> Add Controller Yaw Input
-> Add Controller Pitch Input

Spring Arm: Use Pawn Control Rotation = true
Character facing flags: chosen independently for orbit or strafe behavior

For an absolute recenter:

Get Controller
-> Is Valid
-> read current Control Rotation
-> interpolate toward a normalized/clamped desired rotation
-> Set Control Rotation
-> stop when within a small angular tolerance

Keep ordinary local input disabled or deliberately blended while an absolute recenter owns rotation; otherwise two writers fight every frame.

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

void AHeroCharacter::Look(const FVector2D LookDelta)
{
    AddControllerYawInput(LookDelta.X);
    AddControllerPitchInput(LookDelta.Y);
}

void AHeroCharacter::FaceView(const FRotator DesiredControlRotation)
{
    if (AController* CurrentController = GetController())
    {
        CurrentController->SetControlRotation(DesiredControlRotation);
    }
}

Lookalikes — which one do I want?

Node / setting Use when Key difference
Add Controller Yaw/Pitch Input Local player device input should turn view/aim incrementally. Pawn target; local PlayerController and ignore-look gate matter.
PlayerController Add Yaw/Pitch Input You already hold the correct local PlayerController. Same accumulator without starting from a Pawn.
Set Control Rotation A Controller needs one complete absolute aim/view rotation. Immediate setter; bypasses the input gate and is not automatically camera-limited.
Get Control Rotation You need a snapshot of Controller intent. Read-only; does not turn anything.
Set Actor Rotation The Pawn/Actor body root itself should be placed at an orientation. Changes Actor transform, not Controller aim.
Find Look at Rotation You have start/target points and need the Rotator between them. Calculates a value; does not assign it.
Set Ignore Look Input Incremental local look requests should be temporarily blocked. Stacked Controller gate; does not protect against absolute setters.
AI Set Focus / Set Focal Point AI should track an Actor or position over time. Higher-level AI aim ownership than repeatedly forcing rotation.

Rule of thumb: device input adds a per-frame delta; scripted snaps assign an absolute Control Rotation; body facing remains a separate policy.

Going deeper