How-To: React to a Camera Mode Change

Goal: change how the game reads input when the perspective changes - third-person to side-scroller, say, where 'forward' stops meaning anything and only the plane's lateral axis should move the pawn.

Prerequisites

You completed Quick Start, and you have at least two camera modes to switch between (see How-To: Switch Camera Modes).

Two halves: poll or subscribe

Pick by whether the decision is re-made every frame or happens once at the switch. Using the wrong one is the usual source of stale state.

	Use	For
Poll	`Get Active Camera Type Tag`	Continuous decisions re-evaluated every frame anyway - how move input maps to the world, whether look input is consumed. Always correct, cannot go stale.
Subscribe	`On Camera Mode Changed`	Edge-triggered work that should happen once - swapping an input mapping context, starting a transition effect, enabling a HUD element.

Key on the tag, not the class

Both halves hand you the mode's CameraTypeTag. Branching on the tag keeps your pawn and controller decoupled from CrimsonCamera's mode classes - and it keeps working when a designer swaps in a different Blueprint mode with the same tag.

1. Tag your modes

Set Camera Type Tag in each mode's Blending category - for example Camera.Type.ThirdPerson and Camera.Type.SideScroller. A mode with no tag reports an invalid tag, which is a perfectly good 'default' branch.

2. Poll for movement input

Read the active tag inside your move handler and map the axis accordingly.

In the pawn's move handler: Input Action (Move), Triggered -> Get Crimson Camera Component (drag the component in from My Blueprint -> Components) -> Get Active Camera Type Tag -> Equal (GameplayTag) (B = Camera.Type.SideScroller) -> Branch. On True, a single Add Movement Input along your plane's lateral axis, Scale Value = the event's Action Value X. On False, Get Control Rotation -> Break Rotator -> Make Rotator (Yaw only) -> Get Forward Vector and Get Right Vector, into two Add Movement Input calls (Action Value Y drives forward, X drives right). The tag is read fresh every frame, so it can never go stale.

3. Subscribe for the input context swap

Bind on BeginPlay and swap whatever should change exactly once at the transition.

Event BeginPlay -> Get Crimson Camera Component (drag the component in from My Blueprint -> Components) -> Assign On Camera Mode Changed (drag off the component pin and pick it under Crimson|Camera). That drops a red event node exposing New Mode, New Camera Type Tag, Previous Mode and Previous Camera Type Tag. From the event: Get Enhanced Input Local Player Subsystem (under Local Player Subsystems) -> Remove Mapping Context (the IMC you map to Previous Camera Type Tag) -> Add Mapping Context (the IMC you map to New Camera Type Tag). Guard the branch where a mode pointer is null - its tag is invalid then.

Verify

Push the other mode at runtime - the event fires once with both tags populated, and the mapping context swaps. Either mode pointer can be null (no mode active yet, or the stack emptied), in which case its tag is invalid; handle that branch.

Timing: the event beats the blend

The event fires as soon as the new mode reaches the top of the stack - not when it finishes blending. With a typical Blend Time of 0.5s the camera still looks mostly like the old mode for the first several frames. That is deliberate: input has to respond immediately, or the player feels a dead half-second. For anything cosmetic that should wait for the visuals to settle, poll Get Blend Info - it reports the top-of-stack mode's tag and its current blend weight, so act when the weight reaches 1.

Multiplayer: this is a local-only signal

Never drive authoritative state from this event

Camera modes are evaluated only where there is a local player, so the server never fires this for a remote pawn. The trap with a side-scroller is the movement plane constraint: bConstrainToPlane and PlaneConstraintNormal are plain UCharacterMovementComponent properties that do not replicate, and the server runs the same movement simulation. Constrain on the client only and the server disagrees every frame - you get corrections and rubber-banding.

Set movement state server-side and replicated, from whatever gameplay decision also chose the camera mode - a trigger volume, a level-section actor, a gameplay ability - and let the camera follow that decision rather than make it. UCrimsonCameraMode_SideScroller's Derive Axis From Movement Plane is built for this direction: the camera reads the pawn's constraint instead of owning it, so the two can never disagree.

The same shape as pawn facing

This is the identical problem DeclaredPawnFacing solves for rotation flags, and it is solved the same way: the owning client mirrors its resolved state to the server with a reliable RPC, and the server replicates the result to simulated proxies. See How-To: Face the Lock-On Target.