Wiki

effect · log

Definition

  • Supported scope:any
  • Supported target:none

Description

Print message to game.log, console (if visible) and history logger (if running. you can use category|log to specify a category), Can be localized

Hands-On Notes

Hands-on notes are AI-generated and checked against the vanilla command vocabulary — treat them as a starting point, not authoritative reference. The definition above is the game's own documentation.

Hands-On Usage

log is primarily used for debugging complex mod logic by tracking variable values and execution flow. For example, you can output the current country tag and variable state after an event fires, helping developers confirm that scripts execute as intended. It is also commonly used to mark "which branch was taken" in large if/else structures, and combined with the game.log file to quickly locate issues.

country_event = {
    id = my_mod.1
    immediate = {
        log = "my_mod.1 fired for [Root.GetTag], var=[?my_variable]"
        if = {
            limit = { check_variable = { my_variable > 5 } }
            log = "debug|my_mod.1: branch A taken, my_variable=[?my_variable]"
            add_to_variable = { my_variable = 1 }
        }
    }
}

Synergy

  • [if](/wiki/effect/if) — Write one log statement at the entry and exit of each conditional branch to precisely track which branch is hit. This is standard practice when debugging nested if/else structures.
  • [hidden_effect](/wiki/effect/hidden_effect) — Before final release, wrap debug log statements in hidden_effect for convenient bulk enabling or commenting, preventing log spam from affecting performance.
  • [set_variable](/wiki/effect/set_variable) / [add_to_variable](/wiki/effect/add_to_variable) — Add one log before and after modifying variables to directly compare variable changes in the log file and confirm that numeric calculations are correct.
  • [is_debug](/wiki/trigger/is_debug) — Use is_debug = yes as a gate on the trigger side, combined with log to output information only in debug mode, preventing useless logs in the actual game.

Common Pitfalls

  1. Forgetting to use category prefixes makes logs hard to filter: When output volume is large, omitting the category| prefix means all logs are mixed in game.log and extremely difficult to search. Develop the habit of naming as log = "my_mod|..." so you can filter by keyword.
  2. Writing bare log statements in loops or per-frame triggered blocks: In loop structures like every_country and while_loop_effect, writing log without conditions generates massive log entries each execution, severely slowing down the game. Always add conditional restrictions or keep log only during the debug phase.