> 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/input-receivers.md).

# Input Receivers

Sometimes you do not want a processor per action. You want the pawn, or a component on it, to receive tagged input events and decide what to do in its own Event Graph. That is what **input receivers** are for.

| Piece     | Class                                                              | Header                                                        |
| --------- | ------------------------------------------------------------------ | ------------------------------------------------------------- |
| Interface | `IMIPS_InputReceiver`                                              | `Core/MIPS_InputReceiver.h`                                   |
| Processor | `UMIPS_InputProcessor_CallInputReceiver` (**Call Input Receiver**) | `Processors/Gameplay/MIPS_InputProcessor_CallInputReceiver.h` |

***

## How It Works

The **Call Input Receiver** processor walks the owner chain (the owner, the pawn, the controller, the player state, and every component on each of them, in that order) and calls **Handle Input Event** on each object that implements `IMIPS_InputReceiver`. The first one that returns **true** handles the event; the processor then reports *Handled* to the mode. If nobody returns true, the processor reports *Not Handled* and the next processor gets a turn.

```
Call Input Receiver (Input.Interact)
  ├─ Owner (pawn)            implements receiver? ── returns false
  ├─   pawn's components     BP_InteractionComponent ── returns true  ◄── handled here
  ├─ Controller ...          (not asked)
  └─ Player State ...        (not asked)
```

***

## Setup

{% stepper %}
{% step %}

## Implement the interface

Open the Blueprint that should receive input (a pawn, a controller or an actor component), go to **Class Settings > Interfaces** and add **MIPS\_InputReceiver**.
{% endstep %}

{% step %}

## Handle the event

Implement **Handle Input Event**. It receives the **Event Tag** and the full **Context**, and returns whether it dealt with the event.

```
Event Handle Input Event (Event Tag, Context)
  └─ Switch on Gameplay Tag (Event Tag)
        Input.Interact ──► Try Interact ──► Return true
        Input.Reload   ──► Reload       ──► Return true
        Default        ──► Return false
```

Break the **Context** to reach the event (trigger event, value, time). The event's **Value** converts to bool, float or vector pins like any Enhanced Input value.
{% endstep %}

{% step %}

## Add the processor to a mode

In your Input Mode, add a **Call Input Receiver** processor and set its **Input Tags** to the inputs it should forward, for example `Input.Interact` and `Input.Reload`, and its **Trigger Events** (usually *Started*).

Leave **Event Tag** empty to forward the input tag itself, or set it to send a semantic tag instead, e.g. forward `Input.Interact` as `Event.Use`.
{% endstep %}
{% endstepper %}

***

## C++

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

UCLASS()
class UMyInteractionComponent : public UActorComponent, public IMIPS_InputReceiver
{
    GENERATED_BODY()

public:
    virtual bool HandleInputEvent_Implementation(FGameplayTag EventTag, const FMIPS_InputContext& Context) override
    {
        if (EventTag.MatchesTagExact(TAG_Input_Interact) && Context.Event.TriggerEvent == ETriggerEvent::Started)
        {
            return TryInteract();
        }
        return false;
    }
};
```

***

## Tips

* **Components make receivers modular.** An interaction component, a weapon component and an emote component can each implement the interface and answer only to their own tags; the first that returns true wins.
* **Return false for tags you do not handle**, so the next receiver in the chain, or the next processor in the mode, can react.
* **Pair with gates.** Receivers only see events the mode's gates allowed, so rules such as "no interacting while stunned" stay in the mode.
* **Use `Context.bReplayedFromBuffer`** to tell a replay from a buffer window apart from a live press, e.g. to continue a combo instead of starting a new one.

***

## Alternatives

| Option                                                           | When to use it                                                                                                                                           |
| ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Broadcast Tag Event** processor + component's **On Tag Event** | Many listeners should hear about an input, and none of them needs to report back.                                                                        |
| **Wait For Input** async node                                    | One-off waits, e.g. "press any key to continue" or a tutorial step.                                                                                      |
| **On Input Event** on the component                              | You want every event and its verdict, e.g. for input hints or analytics.                                                                                 |
| A custom processor                                               | The behaviour is reusable across pawns. See [Writing Gates & Processors](/dante-docs/modular-input-system/core-concepts/custom-gates-and-processors.md). |

***

## Next Steps