Fix: Construct 3 Event Sheet Conditions Not Working As Expected

Here is how to fix Construct 3 event sheet conditions that are not working as expected. You set up an event with multiple conditions, and it either fires when it should not or never fires at all. No error appears — the logic just behaves differently from what you intended. This is one of the most common sources of confusion in Construct 3, and it comes down to how the engine evaluates condition blocks internally.

The Symptom

You have an event sheet with conditions that should restrict when an action runs. For example, you want an action to fire only when the player presses the jump key AND is on the ground. But the action fires even while the player is in the air. Or the opposite: the event never triggers at all despite both conditions appearing to be true.

In another scenario, you use an Else event to handle the "otherwise" case of a condition, but it fires at the wrong time or never fires. Or you have multiple conditions in an OR block, and the event triggers on every tick instead of only when one specific condition is met.

The debugger shows that variable values are correct. The conditions themselves are not wrong — the structure of how they are combined is the problem.

What Causes This

There are five common causes:

1. OR block when you need AND (or vice versa). By default, all conditions on a single event are AND-ed — every condition must be true. When you right-click and select "Make OR block," any one condition in that group being true is enough. Developers frequently add OR blocks without realizing they changed the logic from "all must be true" to "any one is enough."

2. Mixing trigger and non-trigger conditions. Trigger conditions (like "On key pressed," "On collision," "On button clicked") fire once at a specific moment. Non-trigger conditions (like "Is overlapping," "Compare variable") are checked every tick. You cannot combine them in the same event block. If you do, the non-trigger condition is only evaluated at the exact instant the trigger fires, which causes subtle timing bugs.

3. Else placement errors. The Else condition applies to the immediately preceding event only. If you accidentally insert another event between the original condition and the Else, the Else will negate that intervening event instead. Additionally, Else does not work reliably after trigger events because triggers are instant — the "previous event" was not true or false in the conventional sense.

4. Event ordering and top-down evaluation. Construct 3 evaluates events top to bottom, left to right. If an earlier event modifies a variable that a later event checks, the later event sees the already-modified value. This can cause cascading triggers or conditions that appear to be skipped.

5. System Compare evaluating the wrong value. When using System → Compare two values, developers sometimes reference an instance variable on an object type that has multiple instances. Construct 3 picks the first instance in creation order by default, which may not be the instance you expect.

The Fix

Step 1: Replace OR blocks with sub-events for AND logic.

// WRONG: OR block fires if EITHER condition is true
Event [OR]
  Condition: Keyboard → On "Space" pressed
  Condition: Player → Is on ground
  Action: Player → Set velocity Y to -600

// CORRECT: Trigger first, then sub-event for the check
Event
  Condition: Keyboard → On "Space" pressed
  Sub-event
    Condition: Player → Is overlapping Ground
    Action: Player → Set velocity Y to -600

The first version fires the jump if the player presses Space OR is on the ground. The second version fires the jump only when Space is pressed AND the player is overlapping the ground object.

Step 2: Never mix triggers with non-triggers on the same event.

// WRONG: Trigger + non-trigger on same event
Event
  Condition: Mouse → On Left button clicked on Player
  Condition: System → Compare: PlayerHealth > 0
  Action: Player → Spawn Bullet

// CORRECT: Trigger as main event, check in sub-event
Event
  Condition: Mouse → On Left button clicked on Player
  Sub-event
    Condition: System → Compare: Player.Health > 0
    Action: Player → Spawn Bullet

This ensures the trigger fires once on click, and only then does the engine evaluate whether health is above zero.

Step 3: Fix Else placement.

// WRONG: Another event sits between the condition and Else
Event 1
  Condition: System → Compare: Score >= 100
  Action: Set text to "You win!"

Event 2
  Condition: System → Compare: Lives = 0
  Action: Set text to "Game over"

Event 3
  Condition: System → Else
  Action: Set text to "Keep playing"
  // This Else negates Event 2, NOT Event 1

// CORRECT: Else immediately follows the event it negates
Event 1
  Condition: System → Compare: Score >= 100
  Action: Set text to "You win!"

Event 2
  Condition: System → Else
  Action: Set text to "Keep playing"
  // This Else negates Event 1

Step 4: Use the debugger to trace evaluation order.

// Add debug actions to trace which events run
Event
  Condition: System → Compare: GameState = "playing"
  Action: Browser → Log "Event: GameState is playing"
  Action: ... your actual actions ...

// In JavaScript (via script block) for deeper inspection:
const state = runtime.globalVars.GameState;
const score = runtime.globalVars.Score;
console.log(`Tick ${runtime.tickcount}: state=${state}, score=${score}`);

The Browser → Log action or a script-based console.log will output to the browser developer tools console (F12), letting you see exactly when and in what order events are evaluated each tick.

Why This Works

Each fix addresses a different aspect of how Construct 3 evaluates event sheets:

Sub-events enforce correct AND logic. By placing the trigger on the parent event and the check on a sub-event, you tell the engine: "When this trigger fires, then additionally check this condition." This is structurally unambiguous and avoids the OR block confusion entirely.

Separating triggers from non-triggers respects the engine’s two evaluation modes. Triggers are instant callbacks that interrupt normal tick processing. Non-trigger conditions are polled every tick. Combining them in one event block forces the engine to shoehorn a polled check into an instant callback context, which leads to missed evaluations.

Correct Else placement matters because Construct 3 implements Else as a modifier on the previous event’s boolean result. It does not create a traditional if/else branch across arbitrary events. It simply inverts the outcome of the single event immediately above it.

Debugging evaluation order exposes the top-down sequential nature of event sheet execution. Once you see the actual order of operations in the console, cascading variable modifications become obvious.

"Event sheets look declarative but execute imperatively. Every event runs top to bottom, every tick. Once you internalize that, the weird behavior stops being weird."

Related Issues

If your conditions work but physics objects pass through floors, see our guide on physics objects falling through floors in Construct 3. For save/load systems where conditions appear to evaluate stale data after loading a save state, check Construct 3 save/load not working. And if your tilemap collision conditions trigger inconsistently, see tilemap collision fixes.

When in doubt, add a sub-event. It is always clearer than cramming conditions onto one line.