Gameplay Camera Reference

The gameplay half: modes, states, and the data behind them. This is the Beta half of the plugin and the one you integrate first.

The Runtime Pieces

UAgenticCameraDirector::GetRuntimeSnapshot(Camera, OutSnapshot) is the Blueprint-pure read of live director state: the active mode, the effective post-state runtime config, and the state container last read from the provider.

Project Settings

Project Settings → Game → Agentic Camera:

The plugin's own Config/Game.ini layers onto your project's Game branch, so a project that merely enables the plugin gets the shipped tables wired with no clicks. Your project's DefaultGame.ini still wins if it sets any of these keys — which is the usual reason a table reads as "not configured". Configure Shipped Defaults assigns every table reference still unset; Validate All Tables cross-checks them and regenerates the schema.

The cinematic half has nothing to configure here: UAgenticShotFlow assets are discovered from the Asset Registry by their FlowTag, and the corrections self-register.

Mode Tags

Activation targets for SetCameraMode / the director. Every tag below is registered — it resolves in a picker and in code — but only five have an authored mode behind them in the shipped table. The rest are vocabulary for modes you author.

Five modes ship authored, as both a row in DT_GameCameraModes and a browsable Data Asset under /AgenticGameplayCamera/Game/Modes/: Exploration, Combat Melee, Combat Ranged, Combat Lock-on and Aim Bow. Every other tag in the table above is a registered name with no row behind it yet — activating one logs not found in registry and keeps the previous mode. Author it by adding a row (or duplicating a shipped Data Asset and giving it that mode tag).

State Tags

States are supplied by your game, never auto-detected. The director reads them each frame and, when the set changes, writes the state's values into the running rig's camera variables — a retarget, not a rebuild, so smoothing nodes keep their history. That covers everything exposed as a camera parameter. Where a state differs in a non-parameter property (a plain float, or an inner struct that cannot be driven as a variable), the candidate build's bake hash detects it and the rig is genuinely replaced, promoted with a cut; the log line for a state change says which of the two happened.

Multiple states can be active at once; their configs blend with equal weight.

The Component's State API

Component Configuration

Mode Transitions

Mode changes use Epic's BlendStack to blend the old rig's output into the new rig's target.

1. The mode change clears persisted lag state.
2. The new rig outputs its target pose directly, with no lag interpolation.
3. BlendStack blends from the old output to that target over the incoming mode's blend-in time.

{
    "Name": "Exploration",
    "ModeTag": { "TagName": "Agentic.Camera.Exploration" },
    "ModeBlendInTime": 0.5,
    "ModeBlendOutTime": 0.3,
    "BlendCurve": "EaseInOut"
}

Mode vs State Transitions

A state's StateBlendInTime picks which:

{
    "StateTag": { "TagName": "Agentic.Camera.State.Crouching" },
    "StateBlendInTime": 0.3,
    "Parameters": []
}

Authoring Pipeline

The same mode data exists in three places, and the round-trip between them is the point:

JSON file  ◄──►  DataTable asset  ◄──►  Camera Mode Data Asset
(agents,          (the registry           (the Details panel,
 diffs, review)    imports this)           a designer's view)

On a mode Data Asset, the DataTable Sync section gives you three buttons: Import from DataTable fills the asset from the row matching its ModeTag, Update DataTable writes the asset back to that row, and Validate checks the tables. Results appear as a toast and in the Agentic Camera Message Log.

The generated schema is authoritative for parameter key names. Regenerate it whenever you validate — the two are kept in lockstep deliberately.

Adding a Tag

Tags have one source of truth and an order that matters:

1. Add the row to DT_GameCameraTags.csv (or the cinematic DT_CinematicCameraTags.csv).
2. Reimport that DataTable in the editor.
3. Only then reference the tag from a modifier registry row or a mode row.

The plugin registers its own tag search path at module startup, the same mechanism Game Feature plugins use, so a consumer project never edits its own DefaultGameplayTags.ini.

Debugging

Per-node flags — on a mode's Lag config, or on the YawFollow, PitchFollow, Focus, Awareness, Constraints and correction entries — mean "force this one on at full detail" regardless of the global level. That table of sites is the complete list of debug draws; see Modifiers for which flag lives where.

Colours are chosen to stay distinct from Agentic Targeting's cyan / yellow / green: blue for the director's arm and pivot (cyan at the camera socket), magenta for focus and lock-on, purple for awareness threats, orange for pitch and yaw constraints, dark green for yaw follow (green while actively recentring), olive for pitch follow, teal for lag, white for the director's state readout.

Every draw is also recorded to the Visual Logger under the AgenticCamera category, so a session can be scrubbed after it happened rather than watched live.