Wiki

effect · print_variables

Definition

  • Supported scope:STATE, COUNTRY, CHARACTER
  • Supported target:none

Description

prints all variables in scope and temp variables to a file
Example: print_variables = {
file = log_file
text = header_text
append = yes
print_global = yes
var_list = { a b c } #optional
}

实战 · 配合 · 坑

实战内容由 AI 生成,并已对照 vanilla 命令词表校验 —— 请当作起点而非权威依据。上方的定义节才是游戏自带文档原文。

实战用法

print_variables 主要用于 mod 调试阶段,当你需要追踪某个国家/州/角色上的变量值是否被正确设置时,可以将其临时插入执行块,把当前 scope 内所有变量和临时变量输出到日志文件,方便排查逻辑错误。开发完成后通常会将其注释掉或删除,避免影响性能。

# 调试:验证某次事件触发后变量是否正确赋值
country_event = {
    id = debug.1
    hidden = yes
    immediate = {
        print_variables = {
            file = "debug_log"
            text = "=== Event debug.1 fired ==="
            append = yes
            print_global = yes
        }
    }
}

配合关系

  • [has_active_rule](/wiki/trigger/has_active_rule):在确认某规则激活后紧跟 print_variables,可验证规则触发时变量状态是否符合预期。
  • [clr_country_flag](/wiki/effect/clr_country_flag):清除标记前先打印变量快照,便于对比清除前后状态,定位标记逻辑错误。
  • [country_event](/wiki/effect/country_event):通过触发专用调试事件来集中调用 print_variables,使日志输出更有组织,便于批量检查多个 scope。
  • [any_owned_state](/wiki/trigger/any_owned_state):遍历州时配合在子 scope 中调用 print_variables,可逐一输出每个州上的变量值,适合排查州级变量同步问题。

常见坑

  1. 忘记在发布版本中移除print_variables 每次执行都会进行文件 I/O,若遗留在高频触发的 effect 块中(如每日脉冲),会严重拖慢游戏性能,必须在调试结束后删除或用 if 条件块包裹控制。
  2. 误以为 var_list 可以省略所有字段file 字段是必填项,省略会导致脚本报错或输出到意外位置;而 var_list 才是真正可选的——不写则输出 scope 内全部变量,写了则只输出指定变量,两者行为差异容易混淆。

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

print_variables is primarily used during mod debugging. When you need to track whether a variable on a specific country, state, or character has been correctly set, you can temporarily insert it into an execution block to output all variables and temporary variables within the current scope to the log file, making it convenient for troubleshooting logic errors. After development is complete, it is typically commented out or deleted to avoid impacting performance.

# Debug: verify whether variables are correctly assigned after a certain event fires
country_event = {
    id = debug.1
    hidden = yes
    immediate = {
        print_variables = {
            file = "debug_log"
            text = "=== Event debug.1 fired ==="
            append = yes
            print_global = yes
        }
    }
}

Synergy

  • [has_active_rule](/wiki/trigger/has_active_rule): Immediately follow with print_variables after confirming a rule is active to verify whether the variable state matches expectations when the rule fires.
  • [clr_country_flag](/wiki/effect/clr_country_flag): Print a variable snapshot before clearing a flag to easily compare the state before and after, pinpointing flag logic errors.
  • [country_event](/wiki/effect/country_event): Trigger a dedicated debug event to centralize print_variables calls, making log output more organized and convenient for batch checking across multiple scopes.
  • [any_owned_state](/wiki/trigger/any_owned_state): When iterating through states, call print_variables in child scopes to output variable values for each state one by one, ideal for troubleshooting state-level variable synchronization issues.

Common Pitfalls

  1. Forgetting to remove before release: print_variables performs file I/O each time it executes. If left in frequently-triggered effect blocks (such as daily pulses), it will severely degrade game performance. You must delete it or wrap it with an if condition block after debugging is complete.
  2. Mistaking var_list as omitting all fields: The file field is mandatory; omitting it causes script errors or unexpected output locations. The var_list is what is truly optional—omitting it outputs all variables within the scope, while including it outputs only specified variables. The behavioral difference between the two is easy to confuse.