How-To: Face the Lock-On Target

Goal: make your character strafe toward the locked target (souls-like), or deliberately stay free to orient toward its own movement. Facing is declared per camera mode over a project-wide default, so a lock-on camera can strafe while a top-down camera stays free - without either one being special-cased.

Prerequisites
You completed Quick Start (a pawn with a UCrimsonCameraComponent and at least one camera mode). For the lock-on half you also completed How-To: Set Up Lock-On.
Opt-in, and off by default
Out of the box CrimsonCamera writes no movement flag at all. It writes control rotation (the view/aim rotation), reads the pawn's view rotation for its pivot, and leaves bUseControllerRotationYaw, bOrientRotationToMovement, and bUseControllerDesiredRotation exactly as your Blueprint authored them. Everything on this page is inert until you set one of the values below to something other than Unchanged.

1. Know the four facing modes

ECrimsonPawnFacing is the single vocabulary used by the project default, by each camera mode, and by runtime gameplay overrides.

ValuePawn bUseControllerRotationYawCMC bOrientRotationToMovementCMC bUseControllerDesiredRotationResult
Unchanged---No opinion. Falls through to the next lower-priority source.
OrientToMovementfalsetruefalseCharacter turns toward its velocity. Camera orbits independently.
FaceControlRotationtruefalsefalseCharacter yaw is slammed to the camera yaw every frame.
FaceControlRotationSmoothlyfalsefalsetrueCharacter interpolates toward the camera yaw at RotationRate.
Why you should stop setting these flags by hand
With bOrientRotationToMovement and bUseControllerRotationYaw both true, the movement component rotates the pawn toward its velocity and then FaceRotation slams the yaw back to the control rotation in the same frame. The visible symptom is a character that keeps snapping to face the camera no matter which way it runs. Once you set a facing value the camera component owns all three flags and this combination cannot happen.

2. Set the project default

Open Project Settings -> Crimson -> Crimson Camera -> Pawn Facing and set Default Pawn Facing. This is what every camera mode that has no opinion of its own falls back to. For most third-person action games this is OrientToMovement.

Leaving it Unchanged
Unchanged (the shipped default) means the camera component never takes ownership, and your pawn keeps whatever its Blueprint authored. You can still opt in per camera mode in step 3 - the first mode that declares a facing is what takes ownership.
Verify
Play in editor and run in a circle without touching the camera. With Default Pawn Facing = Orient To Movement the character faces the direction it runs and never snaps back to the camera's forward.

3. Let a camera mode override it

Every UCrimsonCameraMode has a DeclaredPawnFacing property (Facing category, Unchanged by default). Whenever that mode is the active (top-of-stack) mode, its declaration wins over the project default. This is the whole per-camera mechanism.

Open your camera mode Blueprint -> Class Defaults -> Facing -> set Declared Pawn Facing. Nothing else is required; the camera component reads it as the mode blends in.

Typical assignments: your lock-on mode -> Face Control Rotation Smoothly, your top-down mode -> Orient To Movement, your aim/ADS mode -> Face Control Rotation, your UI mode -> leave Unchanged.

Lock-on facing is not a separate mechanism
The lock-on camera mode is pushed exactly when a hard lock is held and popped when it is released, so its DeclaredPawnFacing is your lock-on facing. There is no lock-on facing setting, no delegate to bind, and nothing to keep in sync. To keep free orientation while locked, just leave that mode's declaration Unchanged.
Prefer a smooth turn to a snap
FaceControlRotationSmoothly turns the character at the movement component's RotationRate instead of snapping the yaw. It reads far better on lock-on acquire, and it is what most action games ship.
Verify
Lock on and strafe: the character keeps facing the target while sidestepping. Release the lock: the lock-on mode pops, its declaration goes with it, and facing returns to the project default.

4. Layer gameplay on top

Aiming, casting, and heavy-attack windups usually want facing-lock regardless of which camera mode is active. Push a request under your own id instead of writing the flags - the camera component resolves highest priority first, so the default priority of 100 wins over any camera mode's 50, and the previous mode is restored the moment you clear it.

On ability start: Push Facing Override on the Crimson Camera Component (Source Id = Aiming, Facing = Face Control Rotation Smoothly, Priority = 100). On ability end: Clear Facing Override (Source Id = Aiming). Use the same Source Id in both nodes.

Push overrides on both the server and the owning client
Overrides are not replicated - only the resolved mode is mirrored. Push and clear them from a context that runs on both machines, which a predicted gameplay ability does naturally. A server-only push leaves the owning client resolving a different mode, and the mismatch shows up as movement corrections.
Verify
Start the ability while a lock-on mode is active: facing changes to the override. End it: facing returns to the camera mode's declaration without you restoring anything.

5. Multiplayer: what runs where

GetCameraView only runs on a machine that has a local player, so a dedicated server never evaluates the camera mode stack and cannot derive facing on its own. Neither rotation flag replicates either. The camera component handles both problems; this table is what it does on your behalf.

MachineWhat happens
Owning clientEvaluates the stack, resolves the winning facing, applies it, and mirrors the resolved mode to the server with a reliable RPC when it changes.
ServerApplies the mirrored mode and stores it for proxies. It does not re-resolve, because it has no camera stack to resolve from.
Simulated proxiesReceive the server's resolved mode. Nothing is strictly required of them - a proxy has no controller, so FaceRotation never runs and its rotation comes from replicated movement.
Verify
Run Play As Client with 2 players. Lock on with client 1 and strafe: on client 2's screen, client 1's character faces its target smoothly with no rubber-banding or snapping back.

6. Opt out entirely

Not every game wants the camera deciding how the character faces. Twin-stick, top-down, and many action games keep free orientation and use lock-on only to frame the camera and to feed Get Current Lock On Target to attacks. Leave Default Pawn Facing and every mode's DeclaredPawnFacing on Unchanged and the plugin never writes a movement flag - set the two CMC flags on your character Blueprint as you always would. Lock-on still drives the camera, the indicators, and the target query.

See also

  • How-To: Set Up Lock-On - the lock-on camera mode whose declaration drives locked facing.
  • How-To: Switch Camera Modes - how the mode stack decides which declaration is active.
  • Concept: The Mode Stack - blending, and what "active mode" means during a blend.
  • Concept: Multiplayer - what runs where across the whole plugin.