trigger · is_operative_captured

Hands-On Usage

is_operative_captured is commonly used in events or decisions related to operatives, to check whether a specific operative character is currently in a captured state, thereby triggering rescue missions, diplomatic negotiations, or punishment logic. For example, in an operative rescue event, the rescue option should only be available to the player when the operative is actually captured:

# In an option's available block of some event
option = {
    name = my_event.option_rescue
    available = {
        scope:target_operative = {
            is_operative_captured = yes
        }
    }
    # Subsequent effect...
}

Synergy

• [free_operative](/wiki/effect/free_operative): After confirming the operative is captured, invoke this effect upon successful rescue to release them, forming a complete "check → action" workflow.
• [kill_operative](/wiki/effect/kill_operative): When a captured operative poses a risk of defection, you can confirm their captured status and choose to execute them to prevent intelligence leaks.
• [operative_leader_mission](/wiki/trigger/operative_leader_mission): Can be used in conjunction to further distinguish what type of mission the operative was executing when captured, enabling more granular branching logic.
• [has_character_flag](/wiki/trigger/has_character_flag): Use alongside character flags to prevent the same capture event from triggering repeatedly, or to track whether the operative has already experienced certain story branches.

Common Pitfalls

1. Scope Errors: This trigger must be used under CHARACTER scope. If written directly in a country-level scope trigger block without switching to character scope via scope: or any_character, it will cause script errors or silent failures. Beginners often forget to switch scopes.
2. Mixing up yes/no Logic: is_operative_captured = no means the operative is not captured. Some beginners mistakenly think this syntax is invalid or behaves differently from NOT = { is_operative_captured = yes }, when in fact both are equivalent. However, mixing them in nested logic can easily cause condition evaluation errors.