Compose your camera. Don't code it every frame.

No. The camera manager, component, modes, push/pop, shoulder, zoom, lag, recenter, shake, occlusion fade, pawn facing and the whole lock-on system, hard and soft, are Blueprint-accessible. The C++-only surface is small and deliberate: the UI-camera takeover (UCrimsonUICameraManagerComponent), the DetermineCameraModeDelegate selection delegate (Blueprint overrides the Determine Camera Mode event instead), and the one-frame AddFieldOfViewOffset. Any of them wraps in a single BlueprintCallable function on your own class.

Yes, and there is almost nothing to manage. Camera is a local concern: every feature runs on the locally-controlled pawn and produces only that client's view, so the mode stack, lock-on, occlusion fade and shakes have no state to replicate. Lock-on changes only the local control rotation, which already replicates as the player's view. The one exception is opt-in pawn facing, and the component handles it for you: the owning client resolves the facing, applies it, and mirrors the resolved mode to the server, which stores it for simulated proxies. Push facing overrides from a context that runs on both machines (a predicted ability does this naturally), and don't treat the camera's locked target as server-authoritative.

No. CrimsonCamera is fully standalone and owns its own types, including ECrimsonPawnFacing and FCrimsonLockOnTargetInfo. Your gameplay code reads the target with Get Current Lock On Target and pushes modes or facing on the component directly. Lock-on additionally uses Unreal's first-party Gameplay Targeting System, which enabling the plugin turns on for you; note Epic still marks that plugin Experimental. Everything except lock-on works without it.

No. It's data-driven, not code. You author a targeting preset (selection, then filters, then sort) and a config asset, add two components, and bind input; the indicators show up on their own. Reorder or disable tasks to change targeting with no recompile. Team filtering is a separate task shipped by CrimsonCore, so lock-on never depends on a team system: omit it, or drop in your own affiliation filter.

Yes. The plugin exposes a runtime setter for each option, and your settings system supplies the values. There is a persistent field-of-view override (0 clears it back to each mode's authored FOV), an occlusion on/off plus fade strength, live lag and auto-recenter setters on the active mode, and a per-player screen-shake scale. That shake scale is worth knowing about: the Crimson camera manager installs its own shake modifier, so one slider scales every shake the player receives, including Play World Camera Shake, camera shake source components and Sequencer shake tracks, not just shakes this plugin played. What it does not ship is a settings store or an options UI; those stay yours, and FOV, shake scale and occlusion live on pawn-owned components, so re-apply them after a new pawn is possessed.

Almost always a targeting preset with no selection task: filters and sorts only ever narrow a selection, so zero selected is zero candidates. Type Crimson.Camera.DevTools in the console during PIE and the inspector answers it directly: a Targets tab listing every candidate with per-filter pass/fail and its screen-center rank, a Lock-On tab showing what Get Current Lock On Target resolves to right now, a Camera tab with the active mode and blend weights, and a Preset tab that puts the hard and soft presets side by side and flags a soft preset missing its Frontal Cone filter, which is the reason soft lock latches onto enemies behind you.

CrimsonCore is the free integration layer, available through the Crimson Discord, and it compiles only with every Crimson plugin installed. With it, the lock-on target automatically becomes the Motion Warping target, gameplay abilities get nodes to push a camera mode or face the pawn for their lifetime, a team-attitude filter task joins the lock-on preset, and a camera manager applies saved player settings. Without it, wire the same public hooks yourself.