trigger · is_debug

Hands-On Usage

is_debug is commonly used during mod development to insert debug-only log outputs, force condition triggers, or bypass cumbersome prerequisites for easier testing without affecting the player experience in the official release. For example, you can add a debug branch within an event's availability conditions, or temporarily bypass certain restrictions in a focus's available block:

available = {
    OR = {
        is_debug = yes
        AND = {
            has_global_flag = some_prerequisite_flag
            date > 1939.1.1
        }
    }
}

Synergy

• [has_global_flag](/wiki/trigger/has_global_flag): In debug mode, commonly paired with global flags to quickly toggle test states; is_debug serves as an outer guard to ensure this logic doesn't affect regular gameplay.
• [log](/wiki/effect/log): Used together with is_debug within hidden_effect or if blocks to output variable or state information to the log file only when debug mode is enabled, avoiding excessive useless logs during official runs.
• [if](/wiki/trigger/if): Almost always wrap is_debug inside an if block when used in effect contexts to conditionally execute debug-only operations.
• [hidden_effect](/wiki/effect/hidden_effect): Enclose debug-specific side effects in a hidden_effect + is_debug = yes combination to both hide notification messages and ensure they only take effect in development environments.

Common Pitfalls

1. Forgetting to remove or protect debug branches before release: Writing is_debug = yes directly at the top level of available or trigger without OR/if protection will cause the condition to always evaluate to false in non-debug mode, making the content completely inaccessible to regular players.
2. Assuming it can be dynamically toggled in regular single-player games: is_debug depends on the game launch parameter -debug and cannot be modified at runtime by any effect; using it as a "toggleable cheat switch" is an ineffective design approach.