These docs describe Fixed Angles and Blendshot, the next update, in development: everything in 1.3 and what it adds. 1.3 is in testing: read its docs.

The claim ladder

Nothing sets the camera. Everything asks, with a priority, and the highest claim holds the shot.

When the player aims, the aim Rig doesn't replace the normal one. It claims the camera at a higher priority. When they stop aiming, the claim goes away and the camera blends back to whatever is underneath. Everything that changes the camera works this way, so nothing has to remember what to put back.

Claim	Priority	Who asks
Manual	0	A direct Blueprint call
Input device	2	Gamepad or keyboard-and-mouse detection
View mode	5	The standing view: third person, over the shoulder, first person
Idle	7	Nobody has touched the controls for a while
Fixed camera	8	A fixed camera whose area you're in
State	10	Aiming, crouching, in the air
Lock-on	15	A lock on a target, set on its Lock-On Preset
Urgent state	20	Ragdoll, takedown
Cinematic	100	Sequencer

The highest priority holds the shot. That's the whole rule.

A fixed camera isn't a Rig, so it doesn't sit on the ladder itself: it stands beside it and takes the shot whenever nothing on the ladder outranks its Priority, 8 unless you change it on the camera. Aiming and every other state take the shot from it and hand it back.

The order matters, not the numbers#

You can change the numbers per Preset. What has to stay true is the order: idle above the standing view, a state above idle, the input device below the view.

Asking again replaces, it doesn't stack#

Each claim is tagged with who made it. Asking again from the same place updates your claim rather than adding a second one, so a system that re-asks every frame never piles up. And if the thing that made a claim disappears (a volume unloaded with its level, say), its claim is swept away on its own.

Go deeperWhy the two kinds of claim break ties differently

Rig claims and Preset claims settle a tie in opposite directions, because they live differently.

Rig claims favour whoever already holds the shot. Systems re-assert Rig claims every frame, so if ties went to the most recent, two systems at the same priority would swap the camera back and forth depending on which refreshed last. You'd see it as a flicker.
Preset claims favour the most recent. They're made once, when the player walks into a region, and never refreshed, so most recent is exactly the region you just entered.

Both are right. They just have different lifetimes.

Go deeperPriorities in code

The constants live in BlendableTypes.h, so you never have to repeat bare numbers:

namespace BlendablePriority
{
    inline constexpr int32 Manual       = 0;
    inline constexpr int32 InputDevice  = 2;
    inline constexpr int32 ViewMode     = 5;
    inline constexpr int32 Idle         = 7;
    inline constexpr int32 FixedCamera  = 8;
    inline constexpr int32 State        = 10;
    inline constexpr int32 UrgentState  = 20;
    inline constexpr int32 Cinematic    = 100;
}

Use them when you write a claim of your own. An automation test checks the order, so if a number is ever moved into the wrong place the build says so. The lock-on's 15 is a setting rather than a constant: Rig Priority on each Lock-On Preset.

Go deeperThe claim calls

RequestRig(Source, Rig, Priority, BlendTime) claims, and ClearRigRequest(Source, BlendTime) lets go. States have their own shorthand: SetCameraState(Name, Active), with SetAiming and SetRagdollFraming wrapping the two everyone uses. BlendToRig and SnapToRig claim at the bottom of the ladder under the name "Manual", so a stray call can never take the shot away from a cutscene. Because a Manual claim is never released on its own, prefer states for anything that comes and goes.

When the camera surprises you, the camera stack readout shows both ladders with the winner marked, which is usually the answer.