trigger · log

Hands-On Usage

The log trigger is commonly used during mod debugging to output variable states or execution checkpoints to game.log in complex condition chains or event triggers, helping verify that scripts execute as intended. Since it can be used in any scope, it is often temporarily inserted into limit, trigger, or available blocks to troubleshoot issues.

# Embed logging in event trigger conditions to confirm whether a country passes the check
trigger = {
    log = "DEBUG: [This.GetTag] is checking war trigger block"
    has_global_flag = some_mod_flag
    is_debug = yes
}

Synergy

• [is_debug](/wiki/trigger/is_debug): Using it together ensures log output only takes effect in debug mode, preventing published mods from polluting the player's log file.
• [check_variable](/wiki/trigger/check_variable): Insert log statements before and after variable checks to track whether variable values match expectations and quickly locate logic errors.
• [has_global_flag](/wiki/trigger/has_global_flag): Pair log with flag checkpoints to print status before and after, confirming the initialization sequence of global flags is correct.
• [log](/wiki/effect/log) (same-named command on the effect side): The effect block also contains log; during debugging you can instrument both trigger and effect sides simultaneously to compare discrepancies between condition evaluation and actual execution.

Common Pitfalls

1. Forgetting to remove from release builds: The log trigger itself does not affect game logic, but excessive log output will degrade performance and bloat the player's game.log. Before official release, always wrap with is_debug = yes or delete directly.
2. Confusion between localization string syntax: log supports localization keys, but beginners often mix localization keys with plain strings, causing the log output to show the key name rather than intended text. Confirm that corresponding entries in localization files are properly defined.