Fix: Construct 3 Animation Not Changing on Trigger

You press the jump key, and the "Set animation to Jump" action runs — you can verify it with debug text. But the sprite stays in the idle animation. Or it flickers to the jump animation for a single frame and snaps back to idle. The action is executing, the animation name is correct, yet the visual result is wrong. This is one of the trickiest Construct 3 issues to debug because the problem is usually not with the event you are looking at, but with a different event entirely.

The Symptom

You have a sprite with multiple animations (Idle, Run, Jump, Attack, etc.) and events that switch between them based on player input or game state. The "Set animation" action appears to do nothing, or the animation changes for a single frame and then reverts. Specific variants of this problem:

The sprite is stuck on one animation (usually Idle or the default animation) regardless of what input you provide. Adding a debug text that displays the current animation name shows it flickering between two animations, or it shows the expected animation name but the sprite does not match.

The animation changes sometimes but not others. Jumping works if you are standing still, but if you jump while running, it stays on the Run animation. Or the Attack animation plays once and then the sprite freezes on the last frame instead of returning to Idle.

A non-looping animation (like a death animation) restarts from frame 0 every tick, appearing frozen on the first frame. The animation never progresses because it keeps resetting.

What Causes This

There are five causes, listed by frequency:

1. Another event is overwriting the animation. This is the cause in the vast majority of cases. Construct 3 runs every event in the event sheet every tick, from top to bottom. If Event 3 sets the animation to "Jump" and Event 8 sets it to "Idle" (because the "is on ground" condition is true on the same tick the jump starts), the sprite will show "Idle" because Event 8 ran after Event 3. The engine does not "remember" that you wanted Jump — it just applies actions in order, and the last one wins.

2. Animation name is misspelled or has wrong casing. Animation names in Construct 3 are case-sensitive. "Jump", "jump", and "JUMP" are three distinct names. If your animation is named "Jump" in the editor but your event uses "jump", the Set Animation action fails silently. No error is displayed — the animation simply does not change. This is especially common when you type animation names manually rather than selecting them from the dropdown.

3. "From beginning" restarts the animation every tick. The Set Animation action has a "from" parameter: "beginning" or "current frame". If you use "from beginning" inside an event that runs every tick (like "Is key down" without "Trigger once"), the animation restarts from frame 0 every single tick. The animation appears frozen on the first frame because it never gets a chance to advance to frame 1.

4. Missing "Trigger once while true" condition. Continuous conditions like "Keyboard: Key is down" are true every tick while the key is held. If your Set Animation action is in an event with only a continuous condition and no "Trigger once while true", the action runs every tick. Combined with "from beginning", this freezes the animation. Without "from beginning", it may seem fine but wastes processing on redundant calls.

5. Looping property mismatch. Each animation in Construct 3 has a "Loop" property (Yes/No). If an animation is set to not loop and plays to its last frame, the sprite stays on that last frame. If you expect the animation to return to a different animation (like Idle) after finishing, you need to use the "On animation finished" trigger. The engine does not automatically switch back.

The Fix

Step 1: Reorder events to establish priority. Put your animation-setting events in order of priority, with the highest-priority animations last (since the last action wins). Use sub-events or "else" to prevent lower-priority animations from overwriting higher-priority ones.

// BAD: Idle event runs after Jump event and overwrites it
+ Keyboard: On "Space" pressed
  -> Player: Set animation to "Jump" (from beginning)

+ Platform: Is on floor
  -> Player: Set animation to "Idle" (from beginning)

// GOOD: Use sub-events and else to create priority
+ Platform: Is on floor
  + Keyboard: Key "Right" is down
    -> Player: Set animation to "Run" (from beginning)
  + System: Else
    -> Player: Set animation to "Idle" (from beginning)

+ Platform: Is NOT on floor
+ Platform: Is falling
  -> Player: Set animation to "Fall" (from beginning)

+ System: On Keyboard "Space" pressed
  -> Player: Set animation to "Jump" (from beginning)

Step 2: Verify animation names exactly. Open the Animations editor in the sprite and note the exact name of each animation, including capitalization. Use the expression dropdown in the Set Animation dialog rather than typing names manually.

// Debug: display the current animation to verify
+ System: Every tick
  -> DebugText: Set text to
     "Current: " & Player.AnimationName
     & newline & "Frame: " & Player.AnimationFrame
     & newline & "Speed: " & Player.AnimationSpeed

// If AnimationName shows the correct name but the
// sprite looks wrong, the animation frames themselves
// may be incorrect (wrong images imported).

Step 3: Use "Trigger once while true" for continuous conditions. Whenever you set an animation from a condition that is true every tick, add "Trigger once while true" to prevent the action from firing repeatedly.

// BAD: Restarts animation every tick, freezing on frame 0
+ Keyboard: Key "Right" is down
  -> Player: Set animation to "Run" (from beginning)

// GOOD: Only fires once when key first pressed
+ Keyboard: Key "Right" is down
+ System: Trigger once while true
  -> Player: Set animation to "Run" (from beginning)

// ALSO GOOD: Use "from current frame" to avoid restart
+ Keyboard: Key "Right" is down
  -> Player: Set animation to "Run" (from current frame)

The difference between "from beginning" and "from current frame" is critical. "From current frame" is idempotent — if the animation is already "Run", calling Set Animation to "Run" from current frame does nothing. This is safe to call every tick. "From beginning" always restarts from frame 0, which is only correct when you want to guarantee the animation starts over.

Step 4: Handle non-looping animations with "On animation finished". For animations that should play once and then transition (attack, death, land), use the "On animation finished" trigger.

// Attack animation plays once, then return to Idle
+ Keyboard: On "Z" pressed
  -> Player: Set animation to "Attack" (from beginning)

+ Player: On animation "Attack" finished
  -> Player: Set animation to "Idle" (from beginning)

// Make sure "Attack" has Loop set to No in the
// animation properties. If Loop is Yes, the
// "On animation finished" trigger will never fire.

Step 5: Use an animation state variable for complex state machines. For characters with many animations and complex transition rules, use an instance variable to track the desired state rather than setting animations directly from input events.

// Instance variable: AnimState (String) = "idle"

// Input events set the state, not the animation:
+ Keyboard: On "Space" pressed
+ Platform: Is on floor
  -> Player: Set AnimState to "jump"

+ Keyboard: Key "Right" is down
+ Platform: Is on floor
  -> Player: Set AnimState to "run"

+ Platform: Is on floor
+ Keyboard: Key "Right" is NOT down
+ Keyboard: Key "Left" is NOT down
  -> Player: Set AnimState to "idle"

// One single event applies the animation from state:
+ System: Every tick
+ Player: AnimationName <> Player.AnimState
  -> Player: Set animation to Player.AnimState
     (from beginning)

This pattern centralizes animation application to a single event. It eliminates conflicts because only one Set Animation action exists, and it only fires when the animation actually needs to change.

Why This Works

Construct 3's event system is not interrupt-driven — it is sequential. Every event runs every tick, in order. There is no concept of "this event already handled the animation, skip the others." When multiple events set the same property (position, animation, variable), only the last one applied matters because each subsequent action overwrites the previous one.

The "Trigger once while true" condition converts a continuous condition into an edge trigger. It remembers the previous state and only allows the event to run on the transition from false to true. This is essential for any action that should happen once per state change rather than continuously.

The "from current frame" parameter turns Set Animation into a conditional operation: if the target animation is already playing, do nothing. This prevents the restart-every-tick problem without needing Trigger Once.

The state variable pattern works because it separates the decision (which animation should play) from the execution (actually changing the animation). Multiple events can compete to set the state variable, and the last one wins — but the actual Set Animation call only happens in one place, only when the state has actually changed.

"If the animation flickers, another event is fighting you for it. Search your event sheet for every 'Set animation' action on that object. The conflict is always there."

Related Issues

If your animation works but the object disappears entirely when changing layouts, see object not found after layout change for global object persistence. For collisions that should trigger animation changes but never fire, check collision not detected between objects. If you are trying to save the player's animation state and restore it after reload, Local Storage data not persisting covers async storage issues. And if sound effects that should play on animation events are silent, audio not playing on first touch addresses the browser autoplay policy.

Last Set Animation wins. If it flickers, two events are competing.