DEACTIVATE [TASK]

UI name in toolbox: deactivate [TASK]

Block type: Statement block (executes in sequence)

Definition: Temporarily disables one or more tasks while the condition remains true. Tasks re-enable when the condition becomes false.

When it executes:

  • Tasks are disabled while the condition is TRUE
  • Tasks are re-enabled when the condition becomes FALSE
  • This is reversible and re-evaluates continuously

Important characteristics:

  • NOT permanent (unlike other action blocks)
  • Uses virtual logic (the condition is continuously evaluated)
  • Can behave unexpectedly—use with caution
  • Reverses immediately when condition becomes false

How to build it:

  1. Drag deactivate [TASK] from Actions category
  2. Connect a task block to the [TASK] socket
  3. Place inside then section of WHEN-THEN block (not canvas)

Input requirements:

  • [TASK] input: must be type Task

How it works:

  1. Condition becomes TRUE
  2. Specified tasks become unavailable (grayed out or hidden)
  3. Condition becomes FALSE
  4. Tasks become available again (automatically re-enable)

Example (Simple):
WHEN: score < 100
THEN: deactivate [bonus task]
Result: Bonus task is unavailable until score reaches 100; when score ≥ 100, task re-enables

Example (Edge Case – Overlapping deactivation):
Rule 1: WHEN score < 100 → DEACTIVATE [Task 5]
Rule 2: WHEN timer > 5 min → DEACTIVATE [Task 5]
Result: Task 5 is deactivated if either condition is true (re-activates only when both are false)

Caution – Unexpected behavior:

  • Using NOT blocks with Deactivate can create confusing state logic
  • Contradictory deactivation rules may cause unpredictable behavior
  • Test thoroughly before deploying

Example (Avoid this complexity):
WHEN: logic_negate [task 1 finished] → DEACTIVATE [bonus]
WHEN: logic_negate (logic_negate [task 1 finished]) → DEACTIVATE [bonus]
Result: Confusing double negation; use clearer logic

Notes:

  • Temporary and reversible (unlike hiding tasks permanently)
  • Useful for conditional task gating
  • Powerful but requires careful logic design
  • Disable/enable happens in real-time as condition changes

Common mistakes:

  • Creating overly complex deactivation chains
  • Expecting permanent deactivation (it reactivates when condition becomes false)
  • Using with contradictory conditions (causes unclear behavior)
  • Over-relying on deactivate for game flow (use simpler patterns when possible)
Tagged: