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 |
| 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.
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 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.