Wiki

effect · every_purchase_contract

Definition

  • Supported scope:any
  • Supported target:none

Description

Executes children effects on every purchase contract (or \"random_select_amount\" of random purchase contracts if specified) of the country in scope, that fulfills the \"limit\" trigger.
tooltip = key need to be added to override the tooltip title.
By default the effects are only displayed once, you may display them for each matching purchase contract with display_individual_scopes.
ex: GER = {
  every_military_industrial_organization = {
	limit = { ... contract scope triggers ... }
	tooltip = my_loc_key # Optional
	random_select_amount = 3 # Optional
	display_individual_scopes = yes # Optional - default = no
    ... Purchase Contract scope effects ...
  }
}

实战 · 配合 · 坑

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

实战用法

every_purchase_contract 常用于军事工业化 mod 中,对某国当前所有采购合同批量执行操作,例如在事件触发时取消所有不满足条件的合同,或遍历合同并记录数据。配合 limit 可精确筛选合同来源方或设备类型,配合 random_select_amount 可随机抽取若干合同进行处理。

GER = {
    every_purchase_contract = {
        limit = {
            buyer = {
                tag = ITA
            }
        }
        cancel_purchase_contract = yes
    }
}

配合关系

  • cancel_purchase_contract:最常见的搭配,在遍历合同时直接取消满足条件的合同,是该 effect 最核心的子效果。
  • buyer:在 limit 块中用于筛选合同的买方国家,确保只对特定买家的合同执行操作。
  • seller:与 buyer 对应,用于筛选合同的卖方,在多国同时存在合同时做精确过滤。
  • hidden_effect:包裹 every_purchase_contract 以隐藏自动生成的 tooltip,再配合 custom_effect_tooltip 提供自定义说明,避免界面信息冗余。

常见坑

  1. 忘记指定 scope 导致合同遍历范围错误every_purchase_contract 作用于"当前 scope 国家"的合同,若外层 scope 不是目标国(如忘记写 GER = { ... }),会遍历到意料之外国家的合同甚至不执行,务必确认进入正确的国家 scope 后再调用。
  2. limit 中使用了不属于采购合同 scope 的 trigger:合同 scope 内只能使用 buyersellerdeal_completioncontract_contains_equipment 等专属 trigger,若误写普通国家 trigger(如直接写 tag = GER)会导致条件永远不匹配或报错,需改为嵌套在 buyer = { tag = GER } 内部使用。

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

every_purchase_contract is commonly used in military-industrial mods to batch-process all purchase contracts belonging to a country — for example, cancelling all contracts that no longer meet certain conditions when an event fires, or iterating over contracts to record data. Use limit to precisely filter by buyer country or equipment type; use random_select_amount to randomly sample a subset of contracts for processing.

GER = {
    every_purchase_contract = {
        limit = {
            buyer = {
                tag = ITA
            }
        }
        cancel_purchase_contract = yes
    }
}

Synergy

  • cancel_purchase_contract: The most common pairing — cancels any contract that matches the limit condition during iteration. This is the most essential child effect used alongside every_purchase_contract.
  • buyer: Used inside a limit block to filter contracts by the purchasing country, ensuring operations only apply to contracts belonging to a specific buyer.
  • seller: The counterpart to buyer; filters contracts by the selling country, allowing precise targeting when multiple nations have overlapping contracts.
  • hidden_effect: Wraps every_purchase_contract to suppress the auto-generated tooltip, then pairs with custom_effect_tooltip to provide a custom description, keeping the UI clean and free of redundant information.

Common Pitfalls

  1. Forgetting to specify the correct scope, causing contracts to be iterated from the wrong country: every_purchase_contract operates on contracts belonging to the current scope country. If the outer scope is not the intended nation (e.g. omitting GER = { ... }), the effect may iterate over an unintended country's contracts or not execute at all. Always confirm you have entered the correct country scope before calling this effect.
  2. Using triggers inside limit that do not belong to the purchase contract scope: Within a contract scope, only dedicated triggers such as buyer, seller, deal_completion, and contract_contains_equipment are valid. Writing a plain country-level trigger directly (e.g. tag = GER) will cause the condition to never match or produce an error. Instead, nest it inside the appropriate scope, e.g. buyer = { tag = GER }.