Wiki

trigger · is_mio_available

Definition

  • Supported scope:INDUSTRIAL_ORG
  • Supported target:none

Description

Checks if the available AND visible triggers in the Military Industrial Organisation in scope return true.
ex:
mio:my_mio = {
	is_mio_available = yes
	is_mio_available = no
}

实战 · 配合 · 坑

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

实战用法

is_mio_available 常用于需要动态判断某个军工组织当前是否满足其自身 availablevisible 条件的场景,例如在事件或决议中根据 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 只检查 availablevisible 双重条件均为真,配合单独使用 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 块中,分别把关组织整体可用性与具体特性可用性,防止对不可用组织执行特性操作。

常见坑

  1. scope 写错:新手容易在国家 scope 下直接写 is_mio_available = yes,导致脚本报错或静默失败。必须先用 mio:xxx = { ... } 或其他方式进入 INDUSTRIAL_ORG scope 再调用此 trigger。
  2. 误以为可以主动"设置"可用性is_mio_available 只是读取 MIO 定义中 availablevisible 块的结果,本身不缓存状态。若条件块内的底层 trigger(如 has_mio_flag)未正确被置位,即使反复调用 is_mio_available = yes 也永远返回假,需要检查 flag 写入逻辑而非这个 trigger 本身。

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

is_mio_available is commonly used in scenarios where you need to dynamically check whether a specific military industrial organization currently satisfies both its own available and visible conditions. Typical use cases include events or decisions that trigger specific rewards or unlock subsequent processes based on the MIO's availability state. A classic pattern is designing conditional logic chains for "activating MIO traits or allocating funds contingent on availability" in mods.

# In an event option, only append funds if the target MIO is currently available
option = {
    trigger = {
        mio:my_custom_mio = {
            is_mio_available = yes
        }
    }
    mio:my_custom_mio = {
        add_mio_funds = 50
    }
}

Synergy

  • [is_mio_visible](/wiki/trigger/is_mio_visible): is_mio_available checks both available and visible conditions simultaneously. Using is_mio_visible separately enables isolated debugging to pinpoint whether the false result stems from visibility or availability.
  • [has_mio_flag](/wiki/trigger/has_mio_flag): Commonly used within available blocks to mark whether an organization has completed prerequisite steps via flags. Works in tandem with is_mio_available to form prerequisite flag → unlock availability conditional chains.
  • [add_mio_funds](/wiki/effect/add_mio_funds): Following a successful is_mio_available check, fund rewards typically follow. This is the most common "check → reward" combination.
  • [is_mio_trait_available](/wiki/trigger/is_mio_trait_available): Both triggers often appear side-by-side in the same limit block, gating overall organization availability and specific trait availability respectively, preventing trait operations on unavailable organizations.

Common Pitfalls

  1. Incorrect scope: Beginners often write is_mio_available = yes directly under a country scope, causing script errors or silent failures. You must first enter the INDUSTRIAL_ORG scope using mio:xxx = { ... } or similar constructs before invoking this trigger.
  2. Mistaking it for an active setter: is_mio_available merely reads the evaluation of the available and visible blocks defined in the MIO, it does not cache state. If the underlying triggers within the condition block (such as has_mio_flag) are not properly set, repeatedly calling is_mio_available = yes will always return false. You should verify the flag write logic rather than suspecting the trigger itself.