Controls and Input

This document explains how you fly an RHCP helicopter: the four core control axes a helicopter pilot uses, the complete default key/button bindings for keyboard & mouse, gamepad, and touch, and the systems that sit behind them — the Input Actions asset, mouse-cursor capture, the input-locking system menus use, and the sensitivity/invert options. Everything here is verified against the shipped RHCP_InputActions.inputactions asset and the Runtime/Input/ source so the names, paths, and values match the asset exactly. If you only want to fly, read Control Concepts and Default Bindings; the rest is for when you wire your own UI, AI, or rebinding.

Control Concepts

A helicopter is flown with three flight axes plus the engine, and RHCP maps each to one input action. Understanding what each axis physically does makes the bindings below self-explanatory, because the action names (Collective, Pedals, Cyclic, EngineToggle) are the aviation terms. RHCP normalizes every device down to the same small set of signed values, so the same flight model code runs whether you fly with a keyboard, a gamepad, or on-screen touch sticks.

The four controls are:

• Collective — vertical thrust (lift). Raising the collective increases the pitch on all rotor blades at once, generating more lift and climbing; lowering it descends. In RHCP this is the Collective action, a signed axis where +1 is full up and -1 is full down (0 is the neutral, hovering-trim center).
• Cyclic — tilts the main rotor disc to produce pitch and roll, which is how a helicopter moves horizontally. Push the cyclic forward and the disc tilts forward, pulling the aircraft forward; push left/right to bank and turn. This is the Cyclic action, a Vector2 where x is roll (+ = right) and y is pitch (+ = nose down).
• Pedals (anti-torque / yaw) — the spinning main rotor tries to spin the fuselage the opposite way (torque reaction); the tail rotor counters it, and the pedals trim that balance to point the nose left or right. This is the Pedals action, a signed axis where + yaws the nose right.
• Engine — RHCP models a real engine spool-up/governor/shutdown cycle, so the rotor only produces usable lift once the engine is running and the rotor RPM is up. The EngineToggle button starts or stops that engine state machine.

Two more concepts appear in flight tuning and in the Flight Tuning doc but are not separate inputs: ground effect is the extra lift you get when hovering close to the ground (a cushion of air under the disc), and translational lift (ETL) is the efficiency gain the rotor gets once you have some forward speed. They are produced automatically by the flight model from your collective and cyclic inputs.

Camera control is a fourth input group. It is a separate action map (Camera) so it can stay live independently of flight — you can look around or switch view even while flight input is locked. See Cameras for what each camera mode does; this doc covers only the input side (Look, FreeLook, CameraSwitch, Zoom).

Default Bindings

The tables below list every action and its default binding, read directly from RHCP_InputActions.inputactions. The asset has three action maps — Flight, Camera, and Demo — and the Demo map's actions are convenience controls used only by the demo scene, not by the runtime flight code. All of these are remappable; see Rebinding.

Keyboard and Mouse

The mouse Cyclic binding (the CyclicDelta source) pre-scales the raw mouse delta by a built-in ScaleVector2 factor of 0.05 per axis, and the scroll Zoom binding scales by 0.02, before your sensitivity settings are applied (the Look mouse-delta binding has no static scale — its magnitude is shaped entirely by lookSensitivity). Holding the right mouse button is what tells RHCP "this mouse motion is for the camera, not the cyclic" — while it is held the cyclic is frozen at its last value (see The Input Actions Asset).

Gamepad

The gamepad right stick is bound to both Cyclic and (with LB held) the camera Look orbit. RHCP resolves the overlap by freezing the cyclic while LB is held, so the stick orbits the camera without also lurching the helicopter. Gamepad zoom uses a separate action (ZoomAxis) from the mouse scroll Zoom because a held D-Pad direction is integrated as a rate over time (so dolly speed stays the same regardless of frame rate), whereas the scroll wheel delivers discrete deltas.

Note: RestartDemo is bound on the keyboard (R) but has no default gamepad binding in the shipped asset, and D-Pad Up is intentionally left free (zoom uses D-Pad Y). If you want a gamepad restart button, add a binding in the Demo map (see Rebinding).

Touch

RHCP's mobile controls do not use a separate touch binding scheme. Instead, the on-screen controls (under Runtime/Mobile/) create a virtual gamepad device and feed the same gamepad control paths the table above already binds, so there is no touch-specific input code — one code path serves all three input methods. See HUD and Mobile for the on-screen layout, sizing, and how to enable it.

Because the on-screen controls write virtual-gamepad paths, anything you rebind on the Gamepad scheme also changes how the touch controls map. Camera free-look is not bound by default on mobile (the chase camera is the default mobile view); add a swipe-look region only if your project needs it.

The Input Actions Asset

All input is defined in one asset, RHCP_InputActions.inputactions, located at Assets/Realistic Helicopter Controller Pro/Runtime/Input/. It contains the three action maps described above — Flight, Camera, and Demo — and each map can be enabled or disabled independently, which is what lets RHCP freeze flight while keeping the camera live, or run the demo-only actions only in the demo scene. The maps and their actions are exactly:

Flight   : Collective, Pedals, Cyclic, CyclicDelta, EngineToggle
Camera   : Look, FreeLook, CameraSwitch, Zoom, ZoomAxis
Demo     : RestartDemo, ToggleHUD, OpenSettings

CyclicDelta is the raw mouse-delta source for the cyclic; the provider integrates it into a virtual stick rather than reading the mouse directly elsewhere. Zoom (mouse scroll) and ZoomAxis (gamepad D-Pad) are two separate actions that both feed one zoom value, for the frame-rate reason noted above. Both are optional — if they are missing from a modified copy of the asset, the camera simply has no zoom and the rest of input still works.

RHCP loads its own asset; it does not use Unity's project-wide Input System "default actions." The RHCP_InputManager component on each helicopter holds a reference to the asset in its actionsAsset field, and the Setup Wizard assigns the shipped default automatically. At startup, RHCP_InputProvider_InputSystem resolves each action by name once and caches the references, so there are no per-frame string lookups while flying. If the actionsAsset reference is missing, or required Flight/Camera actions cannot be found in a hand-edited copy, the provider logs a single clear error naming the Setup Wizard and then treats all input as neutral — the helicopter stays physical and the engine stays off, with no per-frame log spam.

The flight model never reads devices directly. The provider produces a normalized RHCP_InputState snapshot (collective, pedals, cyclic, look, zoom, plus latched button edges), the manager publishes it onto the helicopter hub each physics step, and every other system — cameras, HUD, the cockpit stick visual — reads that snapshot. Input is sampled every frame in Update and consumed once per FixedUpdate, so a button press between physics steps is registered exactly once (never missed at high frame rates, never double-fired at low ones). For the programmer-facing details of RHCP_InputState, IRHCP_InputProvider, and RHCP_InputManager, see the XML documentation comments on those types (surfaced by your IDE's IntelliSense).

Mouse Cursor Capture

Because mouse motion drives the cyclic (and, with the right button held, the camera), RHCP locks and hides the OS mouse cursor for the local player while the camera is live. Without this, the system pointer would wander off the game view and your mouse movement would stop reaching the helicopter. When the cursor is captured it is centered and invisible, and all mouse motion becomes cyclic or camera input.

The capture is keyed to the Camera input channel, not the Flight channel. That is deliberate: the cursor stays captured even when flight input is locked (for example, a paused cinematic that still lets you orbit), and it is released only when the camera itself is locked — which is what a full menu does. The cursor auto-releases in these situations, then re-captures when conditions allow:

You can turn capture off entirely with the lockCursorDuringFlight field on the RHCP_InputConfig asset. It defaults to on; set it off for gamepad-only or touch builds where you never want the OS cursor hidden. Capture also applies only to the helicopter flagged as the local player (isPlayer on RHCP_InputManager) — AI and remote helicopters never touch the cursor.

Input Locking

When a menu opens, flight must stop without losing the helicopter's state and without one system clobbering another's "input enabled" flag. RHCP solves this with a counted lock system on RHCP_InputManager, organized by channel: Flight, Camera, and Demo. A channel is suppressed while any live lock holds it, and it resumes only when the last one is released — this is a count, not a last-writer-wins flag, so two systems can lock the same channel safely.

The API is token-based. You call AcquireLock(owner, channel) and get back a disposable RHCP_InputLockToken; disposing the token (or calling ReleaseLock(token)) releases one count. While the Flight channel is locked, the collective, pedals, and cyclic all read neutral (0), the cyclic accumulator resets, and the EngineToggle edge is suppressed — so a menu cannot accidentally start the engine. Locking the Camera channel additionally frees the OS cursor, which is exactly what a full menu wants. The owner you pass is carried for diagnostics so the editor tooling can show which object is holding a lock.

The system is robust against leaks. If a lock owner is destroyed without releasing its token (for example, a UI panel that is deleted), the manager sweeps the dead reference each frame and reclaims the count, so a despawned menu can never leave the helicopter permanently frozen. In the shipped demo, the Settings panel acquires both a Flight and a Camera lock while open (the Camera lock is what frees the cursor for the menu); the crash/respawn flow takes a different route — RHCP_Damage disables a configured list of behaviours (its disableWhileCrashed list, which can include the input manager) during the death window rather than acquiring a Flight lock. You use the same AcquireLock/ReleaseLock pair for your own menus. Note that free-look needs no lock — it is resolved structurally by the FreeLook modifier described in The Input Actions Asset.

Sensitivity and Invert

Control feel — inversion and sensitivity — lives in a single ScriptableObject, RHCP_InputConfig, separate from flight handling (rates and assists, which live in RHCP_FlightConfig; see Flight Tuning). The boundary is simple: anything a player would call a "controls option" is here, anything a designer would call "handling" is in the flight config. A default config ships and the Setup Wizard assigns it; if a helicopter has no config, the provider falls back to these same defaults. Create your own via Assets ▸ Create ▸ BoneCracker Games ▸ RHCP ▸ Input Config.

The full field set, with the exact defaults from RHCP_InputConfig.cs:

A key design point: inversion and sensitivity are never baked into the bindings. They are applied at runtime by the provider, after the binding's static processors and before the cyclic is accumulated and clamped. This keeps one source of truth and means a future rebinding UI never has to round-trip processor state.

For end users, the demo Settings panel (opened with Esc) exposes the common feel options at runtime — invert and sensitivity — and writes them as runtime overrides rather than modifying the shared config asset. This matters: writing to a ScriptableObject in Play Mode would persist and corrupt the shipped defaults, so the panel instead calls SetInvertPitch and SetCyclicSensitivity on RHCP_InputManager, which the provider reads in preference to the asset until you call ClearControlOverrides. See HUD and Mobile for the Settings panel's full row list.

Rebinding Notes

Because all bindings live in the one RHCP_InputActions.inputactions asset, you can edit them in Unity's Input Actions editor (double-click the asset) to change keys, add gamepad bindings, or support additional devices — the runtime resolves actions by name, so any binding you add to the Collective action (for example) is picked up automatically. The fact that the touch controls reuse the gamepad paths means a gamepad rebinding also re-maps the on-screen controls; keep that in mind if you remap the sticks.

For in-game, player-facing rebinding, use Unity's Input System runtime rebinding (PerformInteractiveRebinding) against the same asset, and persist overrides with SaveBindingOverridesAsJson. Because RHCP keeps inversion and sensitivity out of the bindings, your rebinding UI only ever has to deal with the bindings themselves, not processor state. Composite parts (the up/down halves of a 1D-axis composite, for instance) need a part-aware rebind flow; that is standard Input System work, not RHCP-specific.

If you need to drive a helicopter from a system that is not the New Input System — legacy Input Manager, Rewired, an AI controller, or a network replication layer — you do not modify RHCP's shipped input code. Instead you implement the IRHCP_InputProvider interface in your own assembly and assign it with RHCP_InputManager.SetProvider(...). Your provider produces RHCP_InputState snapshots and nothing else; only RHCP's own provider references UnityEngine.InputSystem, so a custom provider has zero coupling to it. The contract is documented in the XML doc comments on IRHCP_InputProvider.

Troubleshooting

Most input problems come down to the project's input setting, a missing asset reference, or the cursor-capture behavior surprising you. The table below covers the common ones; see also Troubleshooting and the Setup Wizard / Project Doctor, which detect several of these automatically.

If the demo-only controls (R, H) do nothing, that is expected outside the demo scene — the Demo action map is enabled only by the demo components and is not part of the runtime flight loop. To use those convenience actions in your own scene, enable the Demo map and read the latched restartPressed / toggleHudPressed flags from RHCP_InputManager.CurrentState, as the demo controller does.