实战用法
is_mio_available 常用于需要动态判断某个军工组织当前是否满足其自身 available 与 visible 条件的场景,例如在事件或决议中根据 MIO 的可用状态决定是否触发特定奖励或解锁后续流程。典型场景是 mod 中设计"有条件地激活 MIO 特性或拨款"的逻辑链。
# 在事件选项中,仅当目标 MIO 当前可用时才追加资金
option = {
trigger = {
mio:my_custom_mio = {
is_mio_available = yes
}
}
mio:my_custom_mio = {
add_mio_funds = 50
}
}
配合关系
[is_mio_visible](/wiki/trigger/is_mio_visible):is_mio_available 只检查 available 与 visible 双重条件均为真,配合单独使用 is_mio_visible 可拆分调试,确认到底是可见性还是可用性导致整体返回假。
[has_mio_flag](/wiki/trigger/has_mio_flag):常在 available 块内用 flag 标记组织是否已完成前置步骤,与 is_mio_available 联动构成"前置 flag → 解锁可用"的条件链。
[add_mio_funds](/wiki/effect/add_mio_funds):is_mio_available 通过后往往紧跟资金奖励,是最常见的"判断 → 激励"组合。
[is_mio_trait_available](/wiki/trigger/is_mio_trait_available):两者常并列出现在同一 limit 块中,分别把关组织整体可用性与具体特性可用性,防止对不可用组织执行特性操作。
常见坑
- scope 写错:新手容易在国家 scope 下直接写
is_mio_available = yes,导致脚本报错或静默失败。必须先用 mio:xxx = { ... } 或其他方式进入 INDUSTRIAL_ORG scope 再调用此 trigger。
- 误以为可以主动"设置"可用性:
is_mio_available 只是读取 MIO 定义中 available 与 visible 块的结果,本身不缓存状态。若条件块内的底层 trigger(如 has_mio_flag)未正确被置位,即使反复调用 is_mio_available = yes 也永远返回假,需要检查 flag 写入逻辑而非这个 trigger 本身。