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.

The pawn's Enhanced Input move handler: Get Crimson Camera Component -> Get Active Camera Type Tag -> a tag switch/equality branch choosing between camera-relative Add Movement Input and plane-relative Add Movement Input.

3. Subscribe for the input context swap

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

BeginPlay -> Get Crimson Camera Component -> Assign On Camera Mode Changed. The event node exposes New Mode, New Camera Type Tag, Previous Mode, Previous Camera Type Tag; the body removes the previous mapping context and adds the new one.

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.