Skip to content

Started, Triggered, Ongoing, Canceled, Completed

Enhanced Input action events are not old Pressed and Released events with new names. They are notifications about how an action's trigger evaluation changed this frame.

The one-minute version

  • Enhanced Input checks an action's current value, modifiers, and triggers. The trigger logic internally ends up as None, Ongoing, or Triggered.
  • The Blueprint pins you bind to are trigger events: Started, Triggered, Ongoing, Canceled, and Completed. They describe transitions in the action's trigger evaluation during the last tick.
  • Triggered is the pin you use most often, but it does not always mean "pressed once." For axis actions and ordinary active input, it can run every frame while the value stays active.
  • Started is usually the first frame the action begins being evaluated. It can replace old Pressed behavior for simple button actions.
  • Completed is usually the release/end pin after an action successfully triggered. It is the common old Released replacement for a simple press or a completed hold.
  • Canceled means evaluation was interrupted before success, such as releasing a Hold action too early.

The two layers

There are two related ideas with similar names:

ETriggerState = what a trigger reports internally
ETriggerEvent = which Blueprint/C++ action-event pin fires this frame

The underlying trigger state is small:

Internal trigger state Beginner meaning
None The action is not currently satisfying its trigger conditions.
Ongoing The action is being watched, but it has not succeeded yet.
Triggered The action's trigger conditions have been met.

The event pins are the action's public notifications:

Event pin Beginner meaning
Started Evaluation began this frame.
Ongoing Evaluation is still in progress and has not succeeded yet.
Triggered The action succeeded this frame, or is continuing to succeed.
Completed The action finished after having succeeded.
Canceled The action stopped before it successfully triggered.

So the graph you see in Blueprint is not a direct list of keys. It is a list of moments in the action's trigger lifecycle.

stateDiagram-v2
    [*] --> None
    None --> Started: input begins
    Started --> Ongoing: trigger is waiting
    Started --> Triggered: simple trigger succeeds
    Ongoing --> Triggered: conditions met
    Ongoing --> Canceled: input ends too early
    Triggered --> Completed: input/action ends
    Completed --> None
    Canceled --> None

That diagram is a teaching model, not a promise that every trigger takes every arrow. A Tap, Hold, Chorded Action, and plain axis action can expose different event patterns.

Simple button press

For a normal button-style action with no special timing trigger, use this mental model:

press button
-> Started fires on the first active frame
-> Triggered fires while the action is active
release button
-> Completed fires when the triggered action ends

Common bindings:

Goal Bind this first
Do the action once when pressed Started, or Triggered if your trigger setup only fires once.
Keep doing something while held Triggered.
Stop a held behavior on release Completed.
Read a movement/look value every active frame Triggered.

For IA_Jump, a beginner-friendly setup is usually:

IA_Jump Started
-> Jump

IA_Jump Completed
-> Stop Jumping

That mirrors the old "Pressed -> Jump, Released -> Stop Jumping" shape without pretending every Enhanced Input action is a button.

Axis actions

Axis actions are why Triggered surprises beginners.

For IA_Move or IA_Look, the player is not asking for a one-shot command. They are producing a value that can change every frame:

IA_Move Triggered
-> Get 2D Axis Value
-> Add Movement Input from X and Y

If the movement key or stick stays active, Triggered can keep firing while the value stays nonzero. That is correct. Movement wants repeated updates.

Do not move axis logic to Started just to make it "only fire once." A movement action that only runs on the first frame of input will feel broken because the pawn stops receiving movement requests after that first event.

Hold trigger

A Hold trigger adds a waiting period before success.

Typical flow:

press button
-> Started
-> Ongoing while held but not long enough yet

hold long enough
-> Triggered

release after success
-> Completed

If the player releases too early:

press button
-> Started
-> Ongoing
release before hold time
-> Canceled

Use this for:

  • charge actions;
  • hold-to-interact;
  • hold-to-sprint if the sprint should only begin after a delay;
  • "confirm by holding" UI actions.

For a hold-to-open interaction:

IA_Interact Started
-> show hold progress

IA_Interact Ongoing
-> update hold progress

IA_Interact Triggered
-> open the door / complete the interaction

IA_Interact Canceled
-> hide progress and do nothing

IA_Interact Completed
-> clean up progress after a successful interaction

The quick path is to put the real interaction on Started and fake the hold with a Timeline or Delay. The concrete cost is that you now have two timing systems to cancel correctly when input is released, focus changes, or the pawn is destroyed. If the behavior is input-timing, use an Input Trigger first.

Tap and press-and-release triggers

Some triggers succeed on release, not on press. A Tap-style action is a good example: the system has to know that the player released within the allowed time before it can decide the tap succeeded.

Typical shape:

press
-> Started

release within tap window
-> Triggered
-> Completed

If the player holds too long, the action may cancel or never trigger depending on the exact trigger setup.

That is why "Triggered replaces Pressed" is an incomplete rule. For a press-and-release trigger, Triggered can be the release moment. Always read the trigger asset, not only the pin name.

Which pin replaces Pressed and Released?

Use this as a first-pass rule:

Old intent Enhanced Input starting point
Press once Started for simple buttons, or Triggered for triggers that intentionally succeed once.
Release after a successful press/hold Completed.
Held every frame Triggered for active values, or Ongoing while a timed trigger is still waiting.
Released before the required condition Canceled.
Movement/look axis update Triggered.

Then test the action with Print String and the Output Log or breakpoints. Print the pin name and the action value for one press, one hold, one early release, and one axis movement. That small test is faster than guessing.

Why a pin never fires

  1. The trigger type does not support that event. Some trigger classes only ever produce a subset of Started, Triggered, Ongoing, Canceled, and Completed.
  2. The Mapping Context is not active. No active mapping means the Input Action event has no physical input feeding it.
  3. A higher-priority context consumes the key. The action may be correct, but another active context wins the input first.
  4. The action value never actuates. Dead zones, modifiers, device input, or wrong value type can leave the action at zero.
  5. You bound the wrong state for the behavior. A Hold interaction may use Canceled for early release, while a simple button release may be Completed.
  6. The Blueprint instance is not receiving input. The pawn may not be possessed, or the input binding may live on a different actor than the one you are watching.
  7. UI/input mode changed the route. A focused widget, UI-only mode, or paused flow can make the gameplay graph stop seeing input even when the action asset is correct.

Use showdebug enhancedinput during play to inspect active Enhanced Input state, then step the actual Blueprint instance that should receive the action.

Recipes

Input behavior Action setup Bindings
Jump button Boolean action, plain button behavior Started -> Jump, Completed -> Stop Jumping
Movement Axis2D action Triggered -> read Vector2D -> Add Movement Input
Hold to interact Boolean action with Hold trigger Started show progress, Ongoing update, Triggered commit, Canceled abort
Charge and release Boolean action with Hold or timed trigger Started begin charge, Ongoing update, Completed release if success, Canceled fail/cleanup
Tap dodge Boolean action with Tap trigger Triggered performs the dodge after the tap is recognized
Toggle menu Boolean action Started or one-shot Triggered, then open/close UI once

Keep the recipe close to the action's meaning. Do not put movement on Completed, do not put one-shot toggles on an axis every-frame value, and do not ignore Canceled on any interaction that can be interrupted.

Lookalikes - which one do I want?

Thing Use when Not the same as
Started You need the first frame an action begins evaluation. The action's success for delayed/tap triggers.
Triggered The action has succeeded, or an active axis/button value should drive gameplay. A guaranteed one-shot press event.
Ongoing A timed or conditional trigger is still waiting. Successful completion.
Completed A successfully triggered action ended. Early release before success.
Canceled Evaluation stopped before success. Normal release after success.
Input Trigger You need Hold, Tap, Chorded Action, Pressed, Released, or custom conditions. The Input Action asset's value type.
Input Modifier You need to reshape values, such as Negate, Swizzle, or Dead Zone. Timing/condition logic.
Add Mapping Context A local player should use the mappings that feed this action. Binding to a trigger event pin.

Going deeper