Wiki

trigger · hidden_trigger

Definition

  • Supported scope:STATE, COUNTRY, CHARACTER, COMBATANT, ACE, STRATEGIC_REGION, OPERATION, INDUSTRIAL_ORG, PURCHASE_CONTRACT, RAID_INSTANCE, SPECIAL_PROJECT, FACTION
  • Supported target:THIS, ROOT, PREV, FROM, OWNER, CONTROLLER, OCCUPIED, CAPITAL

Description

A hidden trigger, that will not be displayed in the tooltip.
The trigger can still be evaluate when generating a tooltip.
This might be required in the following cases:

* The trigger has a side effect (e.g. temporary variables).
* The trigger uses random numbers (e.g. acts on a random state)

There are three possible evaluation techniques to use when computing tooltips for
hidden_triggers:

* `eval` - Standard evalulation of the trigger.
This is most likely what you need if you have a trigger that has side effects or random parts.
* `no_eval` - If you have no random parts or side effects, then this will give you a slightly faster computation of the tooltip.
* `legacy` - Previous behaviour that is similar to `eval` but a lot less predictable.
Using this explicitly is very likely a bug.

#### Examples

hidden_trigger = { tooltip_evaluation = eval set_temp_variable = { unlock_compare = 0 } all_collection_elements = { collection = { input = game:scope operators = { faction_members } } add_to_temp_variable = { unlock_compare = num_armies } } }

hidden_trigger = { tooltip_evaluation = no_eval add_political_power = 10 }

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

hidden_trigger is commonly used in scenarios where temporary variable calculations or randomized logic are needed, but you don't want players to see the intermediate steps in tooltips. A typical use case is within a focus/decision's available block, where you first use temporary variables to aggregate allied country military strength and then perform comparisons. Selecting the correct tooltip_evaluation mode helps avoid tooltip and actual result inconsistencies caused by side effects.

available = {
    hidden_trigger = {
        tooltip_evaluation = eval
        set_temp_variable = { total_members = 0 }
        all_allied_country = {
            add_to_temp_variable = { total_members = 1 }
        }
        check_variable = { total_members > 3 }
    }
    is_faction_leader = yes
}

Synergy

  • [all_allied_country](/wiki/trigger/all_allied_country) / [any_allied_country](/wiki/trigger/any_allied_country): Iterating through allies within hidden_trigger and writing to temporary variables is the most common "hidden aggregation" pattern.
  • [count_in_collection](/wiki/trigger/count_in_collection): Use in conjunction when you need to count a collection, preventing intermediate counting logic from being exposed in tooltips.
  • [meta_trigger](/wiki/trigger/meta_trigger): Often nested together with hidden_trigger. When you need to parameterize hidden logic, use meta_trigger to dynamically generate internal evaluation code, with hidden_trigger wrapping it externally.
  • [add_political_power](/wiki/effect/add_political_power) (paired with no_eval): When a trigger block needs lightweight effects for architectural reasons, explicitly declare no_eval to prevent tooltip side effects from executing multiple times (though this is an edge case requiring careful consideration).

Common Pitfalls

  1. Forgetting to specify tooltip_evaluation: Omitting this field reverts to legacy behavior, which the official documentation explicitly states is "very likely a bug"—randomized or side-effect-prone logic produces unpredictable tooltips, and beginners often mistakenly attribute this to errors elsewhere in their scripts.
  2. Placing ordinary side-effect-free conditions inside hidden_trigger: This hides the condition's fulfillment state from players entirely, reducing readability and debuggability. hidden_trigger should only be used for logic that genuinely requires hiding intermediate steps; ordinary conditions should be written in the outer layer instead.