> For the complete documentation index, see [llms.txt](https://dante-3.gitbook.io/dante-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dante-3.gitbook.io/dante-docs/modular-input-system/core-concepts/controller-owned-input.md).

# Controller Owned Input

The Modular Input Component works on a pawn or on a player controller. Putting it on the **player controller** keeps the mode stack, the buffer and anything bound to the component's events alive across respawns and vehicle changes. With a **setup provider**, each pawn still brings its own inputs.

| Piece            | Class                                          | Header                           |
| ---------------- | ---------------------------------------------- | -------------------------------- |
| Interface        | `IMIPS_InputSetupProvider`                     | `Core/MIPS_InputSetupProvider.h` |
| Component option | **Use Setup From Owner Chain** (on by default) | `Runtime/MIPS_InputComponent.h`  |

## When to Use It

| Keep the component on the pawn when...       | Move it to the player controller when...                                  |
| -------------------------------------------- | ------------------------------------------------------------------------- |
| each pawn class has its own, unrelated input | the player switches between pawns (character, vehicle, turret, spectator) |
| the mode stack can reset on respawn          | pushed modes (a menu, a cinematic) must survive a respawn                 |
| UI binds to the pawn anyway                  | UI binds to the component once, for the whole session                     |

## Setup

{% stepper %}
{% step %}

### Add the component to the player controller

Add a **Modular Input Component** to your PlayerController Blueprint. Give it the configs every pawn shares (menus, chat, pause) and, optionally, a default mode for when no pawn provides one.
{% endstep %}

{% step %}

### Let pawns provide their own setup

On each pawn class, or on a component the pawn carries, add the **MIPS\_InputSetupProvider** interface and implement its two functions:

| Function                   | Return                                                                                                                     |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Get Input Configs**      | The configs to bind while this pawn is possessed.                                                                          |
| **Get Default Input Mode** | The mode to make the component's default while this pawn is possessed. Return nothing to keep the component's own default. |

```
BP_Character   Get Input Configs      ─► [DA_Config_OnFoot]
               Get Default Input Mode ─► DA_Mode_OnFoot

BP_Vehicle     Get Input Configs      ─► [DA_Config_Vehicle]
               Get Default Input Mode ─► DA_Mode_Driving
```

{% endstep %}

{% step %}

### Possess and play

On every possession change the component:

1. gives back the configs and the default mode the previous provider contributed,
2. asks the owner chain for a new provider,
3. adds that provider's configs (skipping any it already has) and sets its default mode,
4. rebinds, so the new mapping contexts and actions take effect.
   {% endstep %}
   {% endstepper %}

## How the Provider Is Found

The component searches the owner chain and uses the **first** object that implements the interface: each actor is checked first, then its components.

```
Player controller (owner) ─► its components ─► Pawn ─► pawn's components ─► Player state ─► ...
```

{% hint style="warning" %}
Because the owner comes first, do **not** implement the provider on the player controller (or a component on it) when you want pawns to provide their setup: the controller would always win.
{% endhint %}

When the provider changes, its default mode is only taken back if nothing else replaced it in the meantime. Modes you pushed onto the stack are not touched.

Turn off **Use Setup From Owner Chain** on the component to ignore providers entirely.

## C++

```cpp
#include "Core/MIPS_InputSetupProvider.h"

UCLASS()
class AMyVehicle : public APawn, public IMIPS_InputSetupProvider
{
    GENERATED_BODY()

public:
    virtual TArray<UMIPS_InputConfig*> GetInputConfigs_Implementation() const override
    {
        return { VehicleConfig };
    }

    virtual UMIPS_InputMode* GetDefaultInputMode_Implementation() const override
    {
        return DrivingMode;
    }

private:
    UPROPERTY(EditDefaultsOnly, Category="Input")
    TObjectPtr<UMIPS_InputConfig> VehicleConfig;

    UPROPERTY(EditDefaultsOnly, Category="Input")
    TObjectPtr<UMIPS_InputMode> DrivingMode;
};
```

## Things to Know

* **Processors still reach the pawn.** `Context.GetPawn()`, **Get Context Pawn** and **Find Context Component** walk from the controller to its pawn, so the ready-made Move, Look and Jump processors work unchanged.
* **Tags come from the pawn too.** Owner tags are gathered from the controller, the pawn, the player state and their components.
* **Timing.** A player controller is spawned before it receives its local player. The component ticks until the player arrives, then binds and stops ticking. On a dedicated server, remote controllers never bind.
* **Providers also work on pawn-owned components.** A shared component Blueprint on every pawn can take pawn-specific configs from a provider on the pawn.
* **No pawn, no pawn setup.** With no pawn possessed, the component stays bound with the controller's own configs and default mode only, which suits spectating and menus.

## Next Steps