The plugin ships with ~27 camera nodes, 9 transitions, and a modifier system, but gameplay needs are endless. When the shipped set doesn't cover your case, you extend — write your own node, transition, or modifier in C++. This section is the authoring guide.

What to write, and when¶

If you're unsure whether to write a node or a modifier, the rule of thumb is: is this effect always part of this camera's behavior, or is it conditional? Always-present → node. Conditional → modifier. If the effect is temporary and should expire on its own, it's probably an action.

Editor integration — authoring per-asset slate widgets, customizing the Details panel, adding K2 pins — is covered separately in Editor Hooks. Most extension work doesn't need it: the runtime already handles reflection-driven pin generation, subobject pin exposure, and standard property Details rendering for everything you throw at it.

Prerequisites¶

You should be comfortable with:

• UE's reflection system (UCLASS, USTRUCT, UPROPERTY, UFUNCTION, their metadata specifiers).
• Instanced UObject subobjects and how DefaultToInstanced interacts with EditInlineNew.
• The plugin's three-module layout (ComposableCameraSystem runtime, ComposableCameraSystemEditor, ComposableCameraSystemUncookedOnly).

If you're extending the editor (slate widgets, K2 node customizations, graph schema rules), you should also be comfortable with FAssetEditorToolkit, IDetailCustomization, and UE's UEdGraph APIs.

Where your code goes¶

Placement follows the runtime module's subfolder convention:

Do not scatter these into Core/ or Utils/. The runtime reflection registration and the editor's palette / context menu both walk the whole UComposableCameraCameraNodeBase / UComposableCameraTransitionBase / UComposableCameraModifierBase hierarchies, so your new class will be picked up automatically once it's in the right folder and compiled.

Hard rules¶

A few constraints carry over from the runtime architecture. Violate them at your own risk:

• The evaluation hot path must not allocate. Inside OnTickNode, OnEvaluate, or ApplyModifier, no new, no TArray::Add, no TMap::Add, no FString formatting, no MakeShared. Preallocate in OnInitialize / OnBeginPlay, reuse buffers.
• UPROPERTY-ed object references must use TObjectPtr<T>. Not raw UObject*.
• Use the plugin's log categories. LogComposableCameraSystem for runtime, LogComposableCameraSystemEditor for editor. Do not use LogTemp.

These rules apply to extensions exactly as they apply to shipped code.

Reading the recipes¶

Each of the five recipes below is self-contained — you can jump directly to the relevant one:

• Custom Nodes — the biggest recipe; covers reflection, pin schema, OnInitialize vs OnTickNode, subobject pin exposure, and node-vs-modifier decision guidance.
• Custom Transitions — pose-only contract, four-phase lifecycle, velocity handling, testing in isolation, and a worked bounce-and-settle example.
• Custom Modifiers — blueprint-authored in most cases, but C++ modifiers make sense for performance-sensitive or cross-project reusable effects. Includes a sprint FOV walkthrough.
• Custom Actions — fire-and-forget behaviors with built-in lifetime management. Covers execution timing, expiration types, and a worked look-at-target example.
• Editor Hooks — for when the default reflection-driven editor surface isn't enough.

Start with the one closest to what you want to build. The Custom Nodes page is also the densest general reference — if you only read one, read that.