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
- 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.
- 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.