Hands-On Usage
every_controlled_state is commonly used in events or decisions to batch-modify properties across all controlled states — for example, uniformly raising compliance and lowering resistance during occupation events, or adding buildings to every controlled state after a war victory. It is also frequently used in mod initialization scripts to mass-apply flags or change categories across all states controlled by a given country.
# After a specific decision, the Soviet Union lowers resistance and raises compliance across all controlled states
SOV = {
every_controlled_state = {
limit = {
is_controlled_by = SOV
resistance > 20
}
add_resistance = -10
add_compliance = 5
}
}
Synergy
- is_controlled_by: Used inside a
limit block to further filter for states genuinely controlled by the target country, preventing unintended effects in joint-control or temporary occupation scenarios.
- add_compliance: Batch-raising compliance across all controlled states is one of the most common use cases paired with this iterator.
- set_state_flag: Sets a flag on each qualifying state inside the loop, making it available for subsequent trigger or event checks.
- set_occupation_law: Uniformly applies an occupation law to all controlled states; frequently seen in policy decisions or game-start initialization scripts.
Common Pitfalls
- Omitting
limit causes unintended wide coverage: every_controlled_state applies its effects to every controlled state. Without a limit condition, even core states or the capital will be affected, which can easily introduce logic errors. Always use limit to precisely filter the intended target states.
- Confusing it with
every_owned_state: Controlled (controlled) ≠ owned (owned). This iterator operates on states the country controls, not states it owns. If your target is the country's own core territory (and cases where states are owned but not controlled also exist), choose the correct iterator based on your actual intent — otherwise the effect may not cover the states you expect.