The claim ladder
Nothing sets the camera. Everything asks, with a priority, and the highest claim holds the shot.
| 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's touched the sticks for a while |
| State | 10 | Aiming, crouching, in the air |
| Urgent state | 20 | Ragdoll, takedown |
| Cinematic | 100 | Sequencer |
Read the ordering, not the numbers#
The values are defaults you can re-tune per preset. What actually has to hold is the ordering: idle above the standing view, a state above idle, the input device below the view.
Get that wrong and you get a camera that quietly stops responding to preset changes. No error, no warning at runtime, nothing in the log. It's a genuinely miserable afternoon, and it's the reason the preset validator now checks the ordering every time you save one.
Claims are addressed by source#
Each claimant has an identity. Asking again replaces your previous claim rather than stacking a second one, so a system that re-asserts every frame doesn't pile up.
A claimant that stops existing gets swept out on the next resolve. That's what lets a region streamed out from under the player let go of the camera without having run any cleanup of its own, which is impossible to guarantee for a volume that gets unloaded mid-overlap.
The tie-break asymmetry#
This one looks like a bug until you know why, so it's worth stating plainly.
- Rig claims break ties in favour of whoever already holds the shot.
- Preset claims break ties in favour of the most recent.
Rig claims get re-asserted every frame, because that's the only way a claim survives something else clearing the list. If ties went to the most recent, two systems sharing a priority would trade the camera back and forth depending on which happened to refresh last, which reads as a flicker.
Preset claims are edge-triggered by walking into a region and never refresh. There, most-recent is exactly right: it's the region you just walked into.
Both are correct. They differ because the two kinds of claim have different lifetimes.
Priorities in code#
The constants live in BlendableTypes.h rather than being repeated as 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 rather than literals when you write a claim of your own. An automation test asserts the ordering holds, so if someone re-tunes one into the wrong place the build tells them.