Рішення та місії представляють дії, які гравець може або повинен вжити, кожна з яких зберігається у відповідній категорії. Самі рішення визначаються у файлах /Hearts of Iron IV/common/decisions/*.txt, тоді як категорії визначаються у /Hearts of Iron IV/common/decisions/categories/*.txt. Хоча зазвичай у назву файлу включають тег країни, це насправді не має значення: файли можуть мати будь-яку назву, і це ніяк не вплине на те, як вони будуть прочитані.
Зміст
1. Базове створення
Кожне рішення повинно зберігатися в категорії. Категорії рішень визначаються в будь-якому файлі /Hearts of Iron IV/common/decisions/categories/*.txt. Дуже базове визначення категорії рішень виглядає так:
my_decision_category = {
}Це створить категорію my_decision_category, яку можна використовувати в рішеннях.
Після цього рішення для цієї категорії можна створювати в будь-якому файлі /Hearts of Iron IV/common/decisions/*.txt. Рішення призначаються категорії шляхом розміщення їх у блоці цієї категорії, охопленому фігурними дужками, як у наступному прикладі:
my_decision_category = {
my_decision_1 = {
}
my_decision_2 = {
}
}Це створить рішення my_decision_1 та my_decision_2 зі стандартною іконкою та без ефекту, і призначить їх категорії my_decision_category.
Назва рішення відповідно до поточної увімкненої мови може бути визначена в будь-якому файлі локалізації, беручи назву рішення як ключ, а назву рішення з доданим _desc в кінці — як назву для ключа локалізації опису. Наприклад, локалізація для цих рішень для англійської мови виглядатиме так у будь-якому файлі /Hearts of Iron IV/localisation/english/*_l_english.yml:
l_english:
my_decision_category: "Моя категорія рішень"
my_decision_category_desc: "Опис моєї категорії рішень"
my_decision_1: "Моє рішення"
my_decision_1_desc: "Опис мого рішення"
my_decision_2: "Моє рішення без опису"2. Аргументи для рішень та категорій
Наступні аргументи можуть використовуватися як у рішеннях, так і в категоріях рішень, зазвичай з подібним ефектом.
2.1. Тригери
Зазвичай бажано обмежити рішення так, щоб його не завжди можна було прийняти, наприклад, обмежити його певною країною. Для цього існує кілька блоків тригерів, що служать різним цілям. Рішення буде доступним або видимим лише якщо відповідні умови виконані як у категорії, так і в самому рішенні.
allowed— це блок тригерів, який перевіряється лише на початку гри або при завантаженні збереження, в основному використовується для обмеження рішення для країни (якtag = BHRабоoriginal_tag = POL) та/або DLC (якhas_dlc = "One Step Back"). Якщо умоваallowedдля рішення або категорії не виконана, воно ніколи не з'явиться, якщо тільки вона не стане істинною при перезавантаженні збереження або перезавантаженні самих рішень. Якщо пропущено, вважається завжди дозволеним. Це перевіряється лише один раз!allowed = { original_tag = BHR }visible— це блок тригерів, який безперервно перевіряє кожен кадр, чи виконаноallowed, що необхідно для того, щоб рішення або вся категорія була видимою на екрані вибору рішень. У випадку цільових рішень тут можна перевіряти якFROM, так іROOT, але рекомендується використовуватиtarget_trigger, коли це можливо, для оптимізації. Краще розміщувати перевірки країни або DLC вallowed. Нічого не робить для місій!visible = { is_subject = no }available— це блок тригерів, який безперервно перевіряє кожен кадр, чи виконаноvisible, що необхідно для можливості фактично прийняти рішення. Якщо хибно, рішення (або, у випадку категорій, рішення всередині) залишатиметься видимим (якщо не встановлено інше), але буде сірим та неможливим для виконання. Це застосовується поверх вартості політичної влади. Для місій застосовується по-різному.available = { has_war = yes }
2.2. Іконка
Іконка — це невелике зображення, що відображається зліва від назви рішення або категорії. Іконки використовують спрайти, визначені в будь-якому файлі /Hearts of Iron IV/interface/*.gfx, за замовчуванням у decisions.gfx. У рішенні або категорії вона встановлюється за допомогою icon = icon_name. Зауважте, що гра автоматично вставляє або GFX_decision_, або GFX_decision_category_, залежно від того, чи це рішення, чи категорія. Таким чином, приклад з icon_name змусить її використовувати спрайт GFX_decision_icon_name для рішень та GFX_decision_category_icon_name для категорій, або, навпаки, щоб використати GFX_decision_sprite_name у рішенні, воно повинно мати icon = sprite_name. Однак, icon = GFX_decision_icon_name також працюватиме, оскільки гра перевірить spriteType з точно такою ж назвою. Загалом, розробник сам вирішує, чи включати GFX_decision_/GFX_decision_category_ в іконку чи ні.
2.3. Пріоритет
Пріоритет використовується для зміни порядку відображення рішень або категорій зверху вниз, причому вищий пріоритет знаходиться ближче до верху. За замовчуванням рішення має пріоритет 1. Пріоритет рішення можна встановити в короткій формі для статичного значення або в довгій формі, подібно до форматування ai_will_do.
У короткій формі наступний код встановить для рішення або категорії значення пріоритету 10: priority = 10
У довгій формі наступний код матиме значення пріоритету 13 для POL та 3 для інших країн:
priority = {
base = 3
modifier = {
add = 10
tag = POL
}
}2.4. Підсвічування штатів
Рішення або всі рішення в категорії можуть бути налаштовані на підсвічування штату або кількох штатів контуром при наведенні на них у меню вибору. Ось код, необхідний для цього:
highlight_states = {
highlight_state_targets = {
state = 123
state = 321
}
highlight_color_while_active = 3
highlight_color_before_active = 2
}highlight_state_targets вибирає конкретний штат або кілька штатів, які будуть підсвічені. Якщо штат невідомий, замість цього можна використовувати highlight_states_trigger як блок тригерів, що оцінюється для кожного штату на карті.
highlight_color_before_active — це колір, який матиме підсвічування штату перед вибором рішення, від 0 до 3. Якщо не встановлено, за замовчуванням буде білий контур.
highlight_color_while_active — це колір, який матиме підсвічування штату після вибору рішення під час таймера, перш ніж воно буде видалено, від 0 до 3. Якщо не встановлено, за замовчуванням буде білий контур.
2.5. Підсвічування провінцій
Крім підсвічування штатів, з патчу 'Stella Pollaris' (1.13.6) також можливо підсвічувати окремі провінції. Ось код, необхідний для цього:
highlight_states = {
highlight_state_targets = { state = 123 }
highlight_provinces = { 123 213 321 232 }
}Де highlight_provinces = { ... } — це ефект, який зберігає окремі провінції для підсвічування.
3. Аргументи для категорій
Це вікі, що підтримується спільнотою. Якщо ви помітили помилку, будь ласка, допоможіть її виправити.
Ці аргументи можуть використовуватися лише в категоріях і не можуть використовуватися в окремих рішеннях.
3.1. Зображення
Категорія рішень може мати визначене зображення на додаток до своєї звичайної іконки. Зображення відображатиметься зліва від опису категорії, зміщуючи його вліво. Зображення використовують спрайти, визначені в будь-якому файлі /Hearts of Iron IV/interface/*.gfx, за замовчуванням у decisions.gfx. Спрайт з назвою GFX_decision_category_picture можна встановити як зображення категорії за допомогою picture = GFX_decision_category_picture. Категорія повинна мати визначений опис у локалізації, щоб зображення з'явилося.
3.2. Видимість при порожнечі
За замовчуванням категорія рішень невидима, якщо в ній немає принаймні одного видимого рішення. Це не завжди корисно, оскільки категорія може відображати важливу для гравця інформацію у своєму описі. Щоб це змінити, ви можете додати рядок visible_when_empty = yes всередині категорії рішень.
3.3. Область на карті
Категорії рішень може бути призначена область на карті, яка відображатиметься у верхній частині списку рішень подібно до рішення. Натискання на кнопку перемістить камеру до вказаного штату або штатів, а також встановить рівень масштабування на задане значення. Це рекомендується робити в категоріях рішень, що містять рішення, спрямовані на штати. Визначення області на карті виглядає так:
on_map_area = {
state = 123
name = my_localisation_key
zoom = 850
target_root_trigger = {
tag = ENG
}
}state встановлює один штат, який використовується як центр області, куди переміститься камера. Якщо область на карті має бути динамічною, можна використовувати форматування, подібне до цільових рішень, де доступні та змішувані targets, target_array та target_trigger.
name — це ключ локалізації, який використовуватиметься як назва псевдо-рішення, що переміщує камеру до області на карті.
zoom — це рівень масштабування для області на карті, встановлений у кількості пікселів від землі, тобто менше значення означає більше наближення. Для порівняння, за замовчуванням гравець може змінювати масштабування камери між 50[1] та 3000[2].
Крім того, кожен з блоків тригерів, визначених для рішень та категорій (крім available), може знаходитися всередині on_map_area, наприклад, target_root_trigger.
Приклад map_area з динамічним тригером цілі:
on_map_area = {
target_array = controlled_states
name = occupied_states_map_area
zoom = 150
target_trigger = {
FROM = {
NOT = { is_owned_by = ROOT }
}
}
}3.4. Скриптовий GUI
Категорії рішень можна налаштувати так, щоб вона мала скриптовий контейнер графічного користувацького інтерфейсу всередині категорії, що відображається під описом. Відповідний скриптовий GUI повинен мати тип контексту decision_category, щоб це працювало. Це встановлюється за допомогою scripted_gui = my_scripted_gui. Дивіться деталі на спеціальній сторінці для скриптового GUI.
4. Приклади категорій
POL_my_category = {
allowed = {
tag = POL
}
priority = 10
picture = GFX_decision_category_picture
icon = POL_category
visible_when_empty = yes
scripted_gui = POL_scripted_gui
}
my_map_category = {
visible = {
has_completed_focus = my_focus
}
icon = my_map
highlight_states = {
highlight_states_trigger = {
is_owned_by = ROOT
is_capital = yes
}
}
on_map_area = {
state = 123
targets = { capital }
zoom = 350
}
}5. Аргументи для рішень
Ці аргументи можуть використовуватися лише в рішеннях і не можуть використовуватися в категоріях.
5.1. Ефекти при виборі
complete_effect — це блок ефектів, який виконується негайно при виборі рішення (запускаючи таймер, якщо він є).
complete_effect = {
annex_country = { target = QAT }
}5.2. Повторна поява рішення
За замовчуванням рішення знову з'являється наступного дня після його прийняття. Щоб збільшити час перезарядки в днях, можна використовувати days_re_enable = 123, щоб вказати більшу кількість днів для перезарядки.
Щоб рішення зникло назавжди після виконання, рядок коду fire_only_once = yes забезпечить це, роблячи можливим виконання рішення лише один раз для кожної країни.
5.3. Вартість рішення
Щоб призначити рішенню вартість у політичній владі, використовується аргумент cost = . Вартості можна призначити змінну. Як приклад рішення, якому призначено вартість 50 політичної влади:
find_resources = {
develop_infrastructure = {
cost = 50
available = {
has_manpower > 500
}
complete_effect = {
random_owned_state = {
add_building_construction = { type = infrastructure level = 2 instant_build = yes }
}
add_manpower = -500
}
}
}Альтернативно, рішення також може приймати власний рядок локалізації як вартість. Це робиться наступним чином:
custom_cost_trigger = {
<тригери>
}
custom_cost_text = <ключ_локалізації>Якщо custom_cost_trigger виконано, то для локалізації буде використано <ключ_локалізації>, інакше — <ключ_локалізації>_blocked. <ключ_локалізації>_tooltip використовуватиметься при наведенні на вартість. Наприклад, для наступного:
custom_cost_trigger = {
command_power > 14
}
custom_cost_text = decision_cost_CP_15Файл локалізації матиме наступне:
l_english:
decision_cost_CP_15: "£command_power §Y15§!"
decision_cost_CP_15_blocked: "£command_power §R15§!"
decision_cost_CP_15_tooltip: "Прийняття рішення коштує £command_power §Y15§!"Для відображення іконок використовуються текстові іконки. Власна вартість насправді нічого не коштуватиме, і те, що ви встановите як вартість, доведеться відняти в complete_effect рішення, бажано як прихований ефект.
Оскільки власну вартість не можна використовувати разом зі звичайною вартістю, якщо вона включає політичну владу, ШІ не знатиме, що йому слід накопичити її певну кількість перед прийняттям рішення. Це можна виправити за допомогою ai_hint_pp_cost = 100: цей атрибут змусить ШІ думати, що рішення використовуватиме 100 політичної влади, незалежно від того, чи так це насправді, забезпечуючи, що він накопичить стільки перед спробою його використати. Це має бути постійна сума, а не змінна.
5.4. Таймер при виборі
Щоб додати таймер між вибором рішення та застосуванням деяких його ефектів, використовується days_remove = 123 для визначення кількості днів. Якщо встановлено -1, рішення ніколи не буде видалено через закінчення таймера, хоча додаткові блоки тригерів можуть його видалити.
Щодо визначення ефектів, які виконуватимуться після закінчення таймера, використовується remove_effect = { ... } як блок ефектів. Зауважте, що complete_effect = { ... } — це коли рішення обрано, починаючи таймер, а не коли таймер закінчується. Іншими словами, цей таймер з'являється після завершення рішення і залишається там доти, доки рішення не буде видалено. Крім того, remove_trigger = { ... } використовується для миттєвого видалення рішення, як тільки тригери всередині нього будуть виконані для країни, також спрацьовуючи для блоку remove_effect = { ... }.
Крім того, можна змусити рішення застосовувати модифікатори протягом тривалості таймера, де modifier = { ... } надає блок модифікаторів. Подібно до ідей, targeted_modifier = { ... } також існує як спосіб застосування цільових модифікаторів, у тому ж форматі з tag = BHR, що встановлює ціль, наприклад, наступний приклад:
targeted_modifier = {
tag = ENG
attack_bonus_against = 0.1
defense_bonus_against = -0.15
}Щоб змусити таймер скасуватися достроково без надання ефектів, visible = { ... } за замовчуванням не працює. Натомість використовується cancel_trigger = { ... } як блок тригерів. Після того, як він буде оцінений як істинний, таймер рішення закінчується без виконання remove_effect = { ... }. cancel_if_not_visible = yes, за замовчуванням хибно, служить простим способом додати тригери visible до блоку cancel_trigger = { ... }. Після скасування рішення виконується блок ефектів cancel_effect = { ... }. Це може бути корисним як спосіб скасувати ефекти, застосовані в complete_effect.
5.5. ШІ
Основна стаття: Модинг ШІ § AI will do
Шанс для ШІ вибрати рішення визначається блоком ai_will_do = { ... } всередині рішення, який є блоком MTTH (середній час до настання події). За замовчуванням рішення ніколи не буде обрано ШІ, і цей блок необхідний, щоб ШІ його обирав.
Як блок MTTH, структура складається з factor = 10 або base = 10 для вибору початкового значення та modifier = { ... } як блоків тригерів, що призначають add/factor/base у вказаному порядку. Наприклад, наступне змусить рішення ніколи не обиратися ШІ, якщо тільки країна не перебуває у війні з ITA, у цьому випадку воно має вагу 10:
ai_will_do = {
base = 0
modifier = {
add = 10
has_war_with = ITA
}
}5.6. Попередження про війну
Якщо ваше рішення призводить до того, що одна нація оголошує війну іншій нації, існує кілька аргументів, які можна використовувати для інформування цільової нації про наближення війни, а також для сповіщення ШІ про необхідність почати переміщення військ до кордону:
war_with_on_remove = TAGзмусить гру припускати, що рішення у своємуremove_effectоголосить війну вказаній країні, змушуючи її готуватися, коли починається таймер.war_with_on_complete = TAGзмусить гру припускати, що рішення у своємуcomplete_effectоголосить війну вказаній країні, змушуючи її готуватися, коли рішення стане доступним.
Ці аргументи не працюють для цільових рішень; див. Цільові рішення: Попередження про війну.
5.7. Фіксоване випадкове зерно
Рішення за замовчуванням використовують фіксоване випадкове зерно. Це означає, що такі області видимості, як random_list або random_owned_controlled_state, вибиратимуть те саме щоразу, коли рішення використовується, роблячи вибір на початку гри. fixed_random_seed = no забезпечить динамічність випадкового зерна, роблячи можливим різний результат.
6. Приклади рішень
Припускається, що QAT_category та BHR_category вже створені в будь-якому файлі /Hearts of Iron IV/common/decisions/categories/*.txt.
QAT_category = {
QAT_example = {
allowed = {
tag = QAT
}
icon = QAT_example #Для GFX_decision_QAT_example
fire_only_once = yes
days_remove = 100
war_with_on_remove = BHR
modifier = {
training_time_factor = -0.3
}
remove_effect = {
create_wargoal = {
target = BHR
type = puppet_focus_wargoal
}
}
cancel_trigger = {
OMA = {
is_subject_of = BHR
}
}
cancel_effect = {
BHR = {
puppet = ROOT
}
}
}
}
BHR_category = {
BHR_example = {
allowed = {
tag = BHR
}
visible = {
has_war_with = QAT
}
available = {
QAT = {
surrender_progress > 0.5
}
}
icon = GFX_decision_BHR_example
priority = 10
days_re_enable = 200
custom_cost_trigger = {
has_command_power > 14
}
custom_cost_text = decision_cost_CP_15
war_with_on_complete = OMA
fixed_random_seed = no
complete_effect = {
hidden_effect = {
add_command_power = -15
}
annex_country = { target = QAT }
random = {
chance = 50
OMA = { load_oob = "OMA_prepared" }
}
declare_war_on = {
target = OMA
type = annex_everything
}
}
}
}7. Місії
Місії — це інший тип рішень, що активуються, коли тригери істинні, і вимагають від гравця виконання дії для позитивного результату місії. Вони здебільшого використовують ті ж атрибути, що й звичайні рішення, але є деякі суттєві відмінності. Зокрема:
days_mission_timeout = 123— це кількість днів, протягом яких триватиме місія, і це атрибут, який перетворює рішення на місію.timeout_effect = { ... }— це ефекти, які будуть виконані для країни, якщо таймер закінчиться або не буде перерваний.available = { ... }визначає тригери, які роблять місію можливою для вибору, виконуючиcomplete_effect. За замовчуванням завжди істинно, що призводить до миттєвого зникнення.selectable_mission = yes, якщо встановлено, перетворює місію на таку, де гравець повинен натиснути кнопку. Якщо не встановлено або встановлено наfalse, тоcomplete_effectспрацює, як тількиavailableстане істинним.activation = { ... }визначає тригери, які повинні бути виконані, щоб рішення з'явилося, припускаючи, щоallowedбуло істинним на початку гри. Це перевіряється щодня.visible = { ... }нічого не робить і не повинен використовуватися в місіях.- Ефект
activate_mission = mission_nameможе обійти якallowed, так іactivation, і зазвичай краще оптимізовано використовувати його для появи рішення, замість того, щоб покладатися на автоматичну активацію. is_good = yesзмінює підказки, що відображаються гравцеві в невибірній місії. За замовчуванням або якщо встановлено наfalse, підказка стверджує, щоavailableзавершить місію, називаючиtimeout_effectефектами, якщо її не завершено. Якщо встановлено наtrue,complete_effectнатомість зміниться на "Ефекти при невдачі". Це суто графічно і може використовуватися для кращого донесення до гравця, чи слід йому прагнути виконати передумови, чи уникати їх істинності.war_with_on_timeout = TAGзмусить гру припускати, що місія у своємуtimeout_effect = { ... }оголосить війну вказаній країні. Це використовується для того, щоб ШІ підготувався до оголошення війни та зібрав свої війська на кордоні. Це також надасть сповіщення цілі та всім її союзникам про те, що виправдовується привід для війни.
Інші атрибути, такі як cancel_trigger або cancel_effect, загалом можуть використовуватися всередині місій і повинні працювати так само, як і поза ними.
7.1. Приклад місії
my_mission = {
activation = {
has_civil_war = yes
}
available = {
has_civil_war = no
has_war = yes
}
cancel_trigger = {
has_war = no
}
icon = mission_icon # Для GFX_decision_mission_icon
is_good = yes
war_with_on_timeout = SOV
days_mission_timeout = 100
selectable_mission = yes
complete_effect = {
add_ideas = my_idea
}
timeout_effect = {
declare_war_on = {
target = SOV
type = annex_everything
}
}
}8. Цільові рішення
Крім звичайних рішень, які приймаються країною щодо самої себе, можливо зробити рішення цільовим щодо іншої країни або групи країн. У цьому випадку рішення клонуватиме себе для кожної країни, на яку воно націлене, розміщуючи прапор країни в правому нижньому куті іконки рішення. Цільову країну можна буде посилатися в коді за допомогою FROM, тоді як ROOT все ще є країною, яка отримує рішення. Незважаючи на те, що назви можуть вводити в оману, FROM є ціллю рішення, а не країною, що його приймає. fire_only_once у цьому випадку змусить рішення спрацювати лише один раз для кожної цільової країни: рішення, націлене на BLR, не зникне, якщо буде виконано рішення з тим самим ID, націлене на LIT. Місії, як і звичайні рішення, можуть бути цільовими.
Рішення стає цільовим, якщо до нього додано будь-який спосіб перевірки цілі:
8.1. Перевірка цілі
Існує кілька способів обмежити вибір цілей. Якщо будь-який з цих трьох присутній у рішенні, воно буде позначено як цільове.
Основний спосіб обмежити вибір кількома країнами — це targets = { TAG TAG }. У цьому випадку, якщо ви хочете, щоб гра перевіряла кожну країну з цим оригінальним тегом (включаючи повстання громадянської війни та інші типи динамічних країн), рядок коду targets_dynamic = yes забезпечить, що гра перевірятиме більше, ніж країну, якій насправді належить тег країни. Крім того, за замовчуванням неможливо націлитися на неіснуючу країну. Аргумент target_non_existing = yes можна використовувати для зняття цього обмеження.
Крім того, можливо використовувати масиви для обмеження вибору за допомогою target_array = array_name, де масив повинен бути призначений країні. Ви можете побачити список масивів, автоматично згенерованих грою, тут.
Разом з будь-яким з двох попередніх способів або без них, target_trigger = { ... } — це блок тригерів, що оцінюється щодня як для FROM, так і для ROOT, якщо target_root_trigger оцінюється як істинний.
Для цільових рішень також можна використовувати target_root_trigger як блок тригерів, який безперервно перевіряє щодня, чи виконано allowed, що необхідно для того, щоб рішення або вся категорія була видимою на екрані вибору рішень. Це перевіряє лише ROOT, виконуючись перед target_trigger = { ... }. Це існує для оптимізації, оскільки перевірка умови для однієї країни щодня займає набагато менше часу, ніж для кожної комбінації країн.
8.1.1. Огляд тригерів
allowed = { ... }перевіряє країну, яка повинна отримати це рішення, і перевіряє лише на початку гри або при перезавантаженні рішень, наприклад, при завантаженні збереження. Якщо хибно, рішення назавжди вимкнено.target_root_trigger = { ... }перевіряє країну, яка повинна отримати це рішення, щодня. Якщо хибно, рішення не з'явиться до наступної щоденної перевірки. Незважаючи на перевірку лише однієї країни, це все одно робить рішення цільовим.target_trigger = { ... }перевіряє будь-які країни (або штати), які відповідаютьtargets = { ... }таtarget_array = array_name, якщо вони присутні. ТутROOT(область видимості за замовчуванням) — це країна, яка отримує рішення, аFROM— потенційна ціль рішення. Це перевіряється щодня, роблячи рішення невидимим до перевірки наступного дня, якщо хибно. Додавання цього автоматично робить рішення цільовим.visible = { ... }таavailable = { ... }перевіряються кожен тік. Якщо рішення цільове, то перевіряєтьсяFROMразом зROOT, інакше перевіряється лишеROOT.
8.2. Попередження про війну
Звичайні аргументи war_with_on_ не працюють, якщо використовується FROM як ціль. Замість них існують альтернативи спеціально для цільових рішень:
war_with_target_on_complete = yes- Еквівалентноwar_with_on_complete = FROMwar_with_target_on_remove = yes- Еквівалентноwar_with_on_remove = FROMwar_with_target_on_timeout = yes- Еквівалентноwar_with_on_timeout = FROM
8.3. Додаткова примітка
Подібно до місій, існує ефект activate_targeted_decision = { target = TAG decision = my_decision }. Якщо можливо, рекомендується використовувати цей ефект замість того, щоб дозволяти йому активуватися автоматично, роблячи його ніколи не дозволеним. Наприклад, якщо цільове рішення активується перебуванням у війні з країною, on_war_relation_added в on_actions можна використовувати для його активації замість використання target_array = enemies.
8.4. Приклад цільового рішення
my_targeted_decision = {
target_root_trigger = {
has_completed_focus = my_focus
}
targets = { BHR QAT SAU OMA YEM IRQ SYR LEB ISR PAL }
targets_dynamic = yes
target_trigger = {
FROM = {
has_idea = my_idea
}
}
icon = my_icon
cost = 20
war_with_target_on_complete = yes
complete_effect = {
create_wargoal = {
target = FROM
type = annex_everything
}
}
}9. Цільові рішення для штатів
Якщо рішення має state_target = yes, то замість цього воно буде націлене на штат. Можливі значення: yes, no, any, any_owned_state, any_controlled_state, continent_key (europe, africa, north_america...). Це матиме ефект лише якщо не вказано жодних 'цілей', інакше це слід встановити на 'any' (або 'yes'), якщо цілі використовуються. Якщо не пропущено або не встановлено на "no", робить рішення цільовим для штату. Які штати будуть перевірені, залежить від значення:
any(абоyes): перевірятиме кожен штат у грі на відповідність 'target_trigger'.any_owned_state: перевірятиме кожен штат, що належить країні. Це еквівалентно додаванню 'owner = ROOT' у target_trigger.any_controlled_state: перевірятиме кожен штат, контрольований країною. Це еквівалентно додаванню 'is_controlled_by = ROOT' у target_trigger.continent_key(europe, africa, north_america...): перевірятиме кожен штат на континенті. Це еквівалентно додаванню 'is_on_continent = xxx' у target_trigger.
При використанні явних цілей, таких як через targets = {} або target_array = yes, працюватимуть лише state_target = yes/any, інші спричинять помилку.
Націлювання все ще працює так само, маючи FROM як область видимості штату. targets стає targets = { 123 321 } або, у випадку одного штату, також можна використовувати targets = { state = 123 }.
Рішення, націлені на штати, матимуть іконку, що з'являється над штатами, поки відкрито меню рішень. Щоб уникнути плутанини, до категорії рішень можна додати область на карті.
Крім того, аргумент on_map_mode визначатиме, де з'являтимуться цільові рішення.
on_map_mode = map_onlyзмусить цільові рішення з'являтися лише на карті.on_map_mode = decision_view_onlyзмусить цільові рішення з'являтися лише в меню рішень.on_map_mode = map_and_decisions_viewзмусить цільові рішення з'являтися як на карті, так і в меню рішень.
9.1. Приклад
my_state_targeted_decision = {
state_target = yes
target_root_trigger = {
has_completed_focus = my_focus
}
target_array = GER.core_states
target_trigger = {
FROM = {
is_owned_by = ROOT
}
}
on_map_mode = map_and_decisions_view
icon = my_icon
cost = 20
complete_effect = {
FROM = {
remove_core_of = GER
}
}
}