Події визначаються в папці /Hearts of Iron IV/events/
. Існує кілька типів подій, що змінюють вигляд або ціль подій.
Список типів подій включає country_event
, news_event
, state_event
, unit_leader_event
та operative_leader_event
.
У кожному типі подій область видимості ROOT
посилається на країну, яка отримує подію, однак стандартна передбачувана область видимості, також відома як THIS
, не завжди є суто країною. У подіях штату, подіях лідера оперативників та подіях лідера підрозділу передбачувана область видимості охоплює як країну, так і специфічний для події тип області видимості, приймаючи ефекти для будь-якої з областей видимості, сортуючи їх за бажанням. У випадку збігу між тим, що можливо для країни або іншої області видимості (наприклад, add_manpower
є ефектом як для штату, так і для країни), перевага надається країні.
Через цю плутанину рекомендується уникати подій штату, оскільки вони виглядають ідентично подіям країни (замість них можна використовувати цілі подій у подіях країни, спрямованих на конкретний штат), однак події лідера підрозділу та лідера оперативників можуть бути неминучими через їхній відмінний вигляд. Між типами подій майже немає різниці, за винятком вигляду, стандартних областей видимості та того факту, що для новинних подій можна вимкнути спливаюче вікно (однак країна все одно їх отримає). Якщо країна гравця отримує подію і не обирає варіант, за замовчуванням буде обрано перший варіант.
При спрацьовуванні за допомогою ефекту гра переносить звичайні цілі подій, що існують у попередньому блоці ефектів, до події, а також область видимості ROOT
блоку, яка стає FROM
всередині події. Області видимості FROM
попереднього блоку ефектів зміщуються на один рівень вниз, причому FROM
блоку ефектів стає FROM.FROM
, попередній FROM.FROM
стає FROM.FROM.FROM
і так далі. Через це FROM
у жаргоні часто називають "відправником" події, роблячи FROM.FROM
відправником відправника. Хоча це не завжди так, оскільки FROM.FROM
може бути чимось зовсім іншим, наприклад, додатковою областю видимості всередині on_actions
або ціллю рішення. Важливо, що це те, чим є блок FROM
ефекту, який її запустив, що залежить від того, де саме вона була запущена.
Цього не відбувається, якщо подія запускається за допомогою блоку random_events
в on_action
: застосовуються ті ж правила областей видимості, що й у звичайному on_action
.
Країна, яка не існує, все ще може отримувати події, якщо вони запущені через ефект, але будь-який інший метод не працює. Однак, якщо в ефекті, що запускає подію, встановлена затримка часу, таймери в кожному delayed_event
[a] не зменшуватимуться. Це фактично ставить будь-які події із затримкою часу в чергу очікування для країни, призупиняючи їх доти, доки країна не буде звільнена. Наприклад, якщо BHR не існує, коли виконується BHR = { country_event = { id = event.0 days = 1 } }
, то подія спрацює лише через день після того, як BHR почне існувати. Це також стосується початкового одержувача великих подій.
Зміст
1. Створення події
Кожна подія міститься в блоці коду, що відповідає типу події, наприклад, country_event
або news_event
. Усередині події обов'язковим є рядок id
, що відповідає ID події, наприклад, id = my_event.123
.
1.1. Правила ID
У файлі подій усі події повинні мати ID у форматі <простір_імен>.<цілочисельний_ID>
. Наприклад, у події my_event.123
, простір імен буде "my_event", а ID — "123".
Простір імен повинен бути створений перед визначенням будь-яких подій, які його використовують. Це робиться рядком add_namespace = my_event
, який повинен знаходитися поза будь-якою подією. Якщо простір імен не визначено, ID події буде вважатися неправильно сформованим токеном, що призведе до того, що вона не працюватиме в грі. Простір імен події складається з символів слова (наприклад, літери англійського алфавіту або підкреслення). Це включає крапки: add_namespace = my_event.subtopic
можна використовувати для подій типу id = my_event.subtopic.1
. Числовий ID буде взято як все, що йде після останньої крапки, перетворене на ціле число, або 0, якщо перетворення не вдалося.
Внутрішні ID визначаються для подій шляхом присвоєння ID кожному простору імен (ID присвоюються в порядку в коді, файли завантажуються за назвою файлу в порядку символів), причому першому визначеному простору імен присвоюється ID 10, збільшуючи його на 1 для кожного наступного створеного простору імен, множачи його на 100000 і додаючи цілочисельний ID. Якщо ID після простору імен не вдається перетворити на ціле число, він за замовчуванням стане 0. З цієї причини кожна подія з нецілочисельним ID вважатиметься тією ж самою подією, тому ID події після простору імен повинен бути цілим числом.
1.2. Локалізація
Рядки title
та desc
використовуються для присвоєння ключа локалізації події, створюючи її заголовок та опис залежно від поточної мови гри. Приклад рядка: title = my_event.123.t
або desc = my_event_description
. Подія повинна мати заголовок або опис, якщо вона не прихована.
Локалізація визначається в папці /Hearts of Iron IV/localisation/english/
для англійської мови. Бажано використовувати новий файл у папці замість перезапису будь-яких файлів базової гри. Новостворений файл повинен закінчуватися на _l_english.yml
у своїй назві (зауважте, що це мала літера L, а не велика I), щоб він правильно завантажувався. Крім того, він повинен використовувати кодування тексту UTF-8-BOM. Точні деталі щодо зміни кодування залежать від використовуваного текстового редактора. Усередині файлу, припускаючи, що l_english:
вже додано як перший рядок, локалізацію можна додати так:
my_event.123.t: "Мій заголовок події"
my_event_description: "Мій опис події"
Також можливо додати кілька заголовків та описів до події, змушуючи її обирати один залежно від умов. Це робиться наступним чином:
title = {
text = my_event.123.t.a
trigger = {
tag = ENG
}
}
title = {
text = my_event.123.t.b
}
Гра обере перший ключ локалізації, де умови виконані. У цьому випадку заголовок події використовуватиме ключ локалізації my_event.123.t.a
, якщо країна, що отримує подію, має тег ENG, а всі інші країни матимуть заголовок події, що використовує ключ локалізації my_event.123.t.b
. trigger
— це блок тригерів, що вимагає, щоб усі тригери всередині були істинними за замовчуванням. Форматування для описів подій таке ж саме, тільки title
замінено на desc
.
1.3. Зображення
Щоб додати зображення, яке буде показано для події, використовується аргумент picture
з назвою спрайта, що веде до файлу зображення, наприклад, picture = GFX_my_sprite
.
Спрайти визначаються в будь-якому файлі /Hearts of Iron IV/interface/*.gfx
, за замовчуванням використовуючи eventpictures.gfx
, який відкривається будь-яким текстовим редактором. Рекомендується створити новий файл у папці замість використання файлу базової гри в моді з міркувань сумісності з оновленнями. У вибраному вами файлі /Hearts of Iron IV/interface/*.gfx
можна додати наступні рядки всередині блоку spriteTypes = { ... }
для визначення спрайта:
spriteType = {
name = "GFX_my_sprite"
texturefile = "gfx/event_pictures/my_event_picture.dds"
}
Після створення цього спрайта файл
можна використовувати в події як picture = GFX_my_sprite
.
1.4. Запуск
Блок тригерів trigger = { ... }
використовується для оголошення умов, які повинні бути виконані, щоб подія могла з'явитися. Якщо він хибний, немає способу запустити подію, крім використання консольної команди. Це виглядатиме так:
trigger = {
tag = GER
has_political_power > 100
}
Якщо подія запускається в консолі, тригер буде записаний у неї як вміст звичайної підказки тригера, виділяючи, які умови були виконані, а які ні.
За замовчуванням подія спрацьовує автоматично. Це полягає в тому, що тригер перевіряється кожні 20 днів.[1] Якщо він істинний, перевірка змінюється на щоденну перевірку mean_time_to_happen = { ... }
. Це модифікований блок MTTH: він оцінюється для країни та повертає кількість днів; якщо повернута кількість днів дорівнює M, шанс спрацювання події в цей день становить 1 - 2-(1/M), що робить це медіанним часом до настання. Якщо тригер хибний при щоденній перевірці, він повертається до перевірки тригера кожні 20 днів.
mean_time_to_happen = { ... }
має атрибути days
, months
та years
для визначення базової кількості днів. Місяць інтерпретується як 30 днів, рік — як 365 днів. Якщо кількість днів повинна бути динамічною, modifier = { ... }
служить блоком тригерів з додатковими атрибутами add = 123
(додає цю кількість днів) та factor = 0.2
(множить кількість днів на вказане число). Модифікатори оцінюються в порядку їх розміщення, і вони підтримують змінні в аргументі. Приклад середнього часу до настання виглядає так:
mean_time_to_happen = {
days = 10
years = 1 # 375 днів як база.
modifier = {
factor = 0.2 # Для POL спрацьовує на 20% швидше, або за 75 днів.
tag = POL
}
}
Автоматичний запуск можна вимкнути, додавши is_triggered_only = yes
до події. Це не запобігає будь-якому іншому способу запуску події, чи то через ефект, що використовується для цього, чи через random_events
в on_action
, чи через прикордонну війну, чи будь-що інше. Це абсолютно не пов'язано з trigger = { ... }
: умови всередині все ще повинні бути виконані, щоб будь-який з цих способів міг запустити подію. Якщо ефект, що використовується для запуску події (наприклад, country_event
або state_event
), встановлений із затримкою, то тригер повинен бути істинним, коли подія має бути запущена.
fire_only_once = yes
робить неможливим запуск події більше одного разу. Це перевіряється всередині самої події: країна, що отримує подію, також запобігатиме отриманню її будь-якою іншою країною. Це обходиться за допомогою консольної команди.
major = yes
використовується для того, щоб подія спрацювала для кожної країни, як тільки будь-яка країна її отримає. Це робиться в кожній новинній події, оскільки новинні події є суто графічним переоформленням подій країни. У випадку збігу з fire_only_once = yes
, останній матиме пріоритет і усуне будь-який ефект того, що подія є великою, змушуючи її з'являтися лише для країни, яка отримує її вперше. Країни, крім першої країни, що отримує її, ігноруватимуть trigger = { ... }
. Щоб лише деякі країни отримували показану подію, поки вона все ще велика, використовується show_major = { ... }
як блок тригерів, який змушує подію з'являтися лише якщо він істинний. Якщо також додано fire_for_sender = no
, подія спрацює для кожної країни, яка відповідає show_major
, крім країни, яка мала її отримати.
1.5. Опції
Опція події додається за допомогою блоку option = { ... }
. Опція події — це блок ефектів з кількома додатковими опціями:
name
визначає ключ локалізації, що використовується для опції, наприклад,name = my_option_name
. Неможливо зробити так, щоб назва опції залежала від тригерів так само, як це можливо для заголовків подій; замість цього можна використовувати абсолютно різні опції подій, вимикаючи кожну з назвою, яка не повинна використовуватися.trigger = { ... }
— це блок тригерів, що визначає, коли опція видима для вибору. Якщо тригер хибний під час запуску, він не з'явиться, доки подія не буде запущена знову. Крім того, для великих подій можна використовуватиoriginal_recipient_only = yes
, щоб забезпечити, що лише країна, яка запустила подію, має цю опцію доступною, а інші — ні.ai_chance = { ... }
— це блок, що визначає шанс ШІ для опцій подій: пропорційно вирішуючи, яку опцію обрати. Шанси ШІ в опціях подій не обов'язково повинні сумуватися до 100, оскільки вони пропорційні. Він структурований майже ідентично середньому часу до настання. Якщо не встановлено, вважається 1. Ймовірність кожної опції — це її вага, поділена на суму всіх ваг опцій. Якщо всі опції мають вагу нуль, обирається перша. Випадковий вибір здійснюється кидком d100, тому опції не можуть мати ефективну ненульову ймовірність нижче 1%. Вибір залишається послідовним при перезавантаженнях, базуючись на унікальному зерні гри, внутрішньоігровому часі, країні та лідері підрозділу.
Як блок MTTH, атрибути мають форму base = 10
, factor = 0.1
, add = 10
, з modifier = { ... }
, що служать блоками тригерів:
ai_chance = {
base = 10.5
# Якщо країна - Німеччина, встановити значення 0,
# що призведе до дострокового завершення оцінки.
modifier = { tag = GER factor = 0 }
modifier = { is_major = yes add = 1 }
modifier = {
factor = 3
add = 2.5
tag = FRA
}
factor = 2
}
1.6. Додаткові аргументи
immediate = { ... }
— це блок ефектів, що виконується, як тільки подія запускається, перш ніж гравець обере опцію. Це також можна використовувати для ШІ: ШІ обирає опцію лише після того, як тригери події оцінені для кожної іншої країни, тоді якimmediate
виконується негайно, перш ніж оцінювати інші події. Це можна використовувати у великих подіях типу "середній час до настання": зробивши так, щобimmediate
встановлював глобальний прапор, який повинен бути не встановлений у тригері події, це запобігатиме її запуску більше одного разу для кожної країни, але бажано взагалі уникати подій типу "середній час до настання". Зауважте, що ефект з'явиться в підказці після опису події, тому інструмент потокуhidden_effect
може бути корисним.timeout_days = 20
встановлює кількість днів, протягом яких гравець повинен обрати опцію, перш ніж перша опція буде автоматично обрана. Це можна використовувати, щоб зробити подію більш-менш терміновою, ніж за замовчуванням. Якщо не встановлено, вважається 13 днів.[2]hidden = yes
зробить подію прихованою. Прихована подія не потребує заголовка чи опису. Перша визначена опція, якщо така є, буде автоматично обрана при запуску. Приховані події можуть бути корисними замість скриптованих ефектів для затримки виконання блоку ефектів на певний період часу або для використання області видимостіFROM
.minor_flavor = yes
позначає подію як незначну подію для атмосфери. Це не змінює її вигляд або ефекти, але дозволяє вимкнути спливаюче вікно в меню рішень гри.
2. Ефект
Будь-який блок ефектів може бути використаний для запуску події, наприклад, нагороди за фокуси, опції подій або ефекти рішень. Це зазвичай поєднується з is_triggered_only = yes
всередині події, щоб вимкнути автоматичний запуск.
У найпростішому вигляді це робиться за допомогою ефекту country_event = my_event.1
(або news_event = my_event.1
), який миттєво запустить подію для країни в області видимості. Оскільки події країни та новинні події по суті є одним і тим же, обидва скорочені ефекти можна використовувати як для подій країни, так і для новинних подій, без жодної різниці між ними. Однак можна додати більше опцій, головним чином для налаштування затримки. Крім того, розширені версії є обов'язковими для подій штату та лідера оперативників.
Більш складний ефект для запуску: country_event = { id = my_event.1 days = 100 random_days = 123 }
. Це запустить подію через 100-223 (100 + 123) дні. Існують наступні аргументи, які можуть увійти в ефект (усі вони опціональні, за одним винятком):
id = my_event.1
— ID події для запуску. Це обов'язково, щоб гра знала, яку подію запускати.hours = 1|days = 2|months = 3
— Нижня межа необхідного часу, через який спрацює подія. У цьому випадку місяць розглядається як рівно 30 днів. Якщо використовується кілька з них, гра їх сумує (наприклад, приклад з 1 годиною, 2 днями та 3 місяцями спрацює через 92 дні та 1 годину).random_hours = 1|random_days = 2
— Це встановлює верхню межу необхідного часу, через який спрацює подія. Гра вибирає випадкову кількість (рівномірний розподіл) днів та годин між 0 та встановленою кількістю, включаючи обидва кінці, і додає їх до затримки для запуску події. Аналогічно до вищесказаного, якщо вказано обидва, гра їх сумує.random = 123
також служить еквівалентомrandom_hours = 123
.tooltip = my_event.1.t
— Це визначає, як буде відображатися назва події, що спрацює, у локалізації. За замовчуванням назва події, це може бути корисно, якщо заголовок може змінитися між ефектом для її запуску та її фактичною появою.
Приклад ефекту з використанням кількох з цих параметрів:
country_event = {
id = my_event.1
hours = 12
random_hours = 6
days = 2
tooltip = another_event.1.t
}
Опціональна затримка неймовірно корисна, оскільки приховані події можна використовувати для створення затримки між виконанням блоку ефектів та фактичним застосуванням ефектів без того, щоб гравець щось помітив. Це також можна використовувати, щоб події виглядали більш "природно": новинні події можуть мати затримку в кілька годин (зазвичай близько 6-12), щоб симулювати час, необхідний інформаційним агентствам для повідомлення про подію. Аналогічно можна зробити з іншими типами подій, щоб симулювати очікування кілька годин на дипломатичну відповідь, замість того, щоб вона була неприродно миттєвою. trigger = { ... }
події перевіряється, коли вона мала б спрацювати, що означає, що також можливо запустити подію при запуску гри з необхідною затримкою, щоб отримати її в конкретний день, а потім використати тригер події для симуляції додаткових вимог.
Крім того, існують такі специфічні для типу події аргументи:
trigger_for = TAG
(Унікально для подій штату) — Країна, для якої спрацює подія. Це обов'язково, оскільки події штату повинні запускатися в області видимості штату. Це також можна замінити наcontroller
,owner
,occupied
або подвійну область видимості, яку можна використовувати як ціль, наприклад,ROOT
абоFROM
.originator = TAG
(Унікально для подій лідера оперативників) — Країна, яка служить ініціатором події (тобтоFROM
). За замовчуванням власник оперативника, якщо не встановлено.recipient = TAG
(Унікально для подій лідера оперативників) — Країна, яка отримає подію. За замовчуванням власник оперативника, якщо не встановлено.set_root = TAG
(Унікально для подій лідера оперативників) — Змінює область видимостіROOT
у динамічній локалізації події, фактично не змінюючи її в коді.set_from = TAG
(Унікально для подій лідера оперативників) — Змінює область видимостіFROM
у динамічній локалізації події, фактично не змінюючи її в коді.set_from_from = TAG
(Унікально для подій лідера оперативників) — Змінює область видимостіFROM.FROM
у динамічній локалізації події, фактично не змінюючи її в коді.
3. Поширені помилки
Деякі помилки досить поширені при початку створення подій, чи то через погану практику, чи то вони повністю перешкоджають роботі події. Деякі з них важко помітити під час Модингу, коли подія, здавалося б, працює нормально, наприклад, помилка, яка перешкоджає запуску новинних подій для більш ніж однієї країни. Тут розглянуто деякі з них, а також менш інтуїтивні помилки в лозі.
3.1. Незареєстровані помилки
- Залишення події як "тільки за тригером", коли вона має запускатися автоматично (подія ніколи не спрацьовує) –
is_triggered_only = yes
вимикає автоматичний запуск події, натомість змушуючи використовувати для цього ефект. Тому, якщо це залишено в події, призначеній для автоматичного запуску, подія ніколи цього не зробить.
Зауважте, щоtrigger = { ... }
все ще може співіснувати зis_triggered_only = yes
, тому подія з обомаis_triggered_only = yes
таtrigger = { ... }
все ще може бути правильною. Допустимі випадки їх одночасного використання включають запуск події черезrandom_events
вon_action
або затримку в ефекті, що її запускає (де тригер перевірятиме, коли подія має бути отримана), серед інших. - Невказання країни в тригері для специфічних для країни автоматично запускаються подій (подія спрацьовує для неправильної країни/ніколи не спрацьовує) – Події жодним чином не прив'язані до країн (простори імен та назви файлів служать суто організаційній меті), і тригер кожної події перевіряється для кожної країни в порядку, вказаному в списку тегів.
У наведеному прикладі подія вимагає, щоб ITA мала більше 123 політичної влади, після чого країна, що отримує подію, анексує AUS. Однак, як тільки ITA матиме стільки, цей тригер буде істинним незалежно від того, де він перевіряється. Першою країною в списку тегів за замовчуванням є GER, і тому вона буде першою країною, де перевірятимуться тригери. На практиці ця подія призведе до того, що GER анексує AUS, а не ITA.
У виправленні зроблено зміну: спочатку перевіряється, що країна, яка отримає подію, — це ITA, і лише потім перевіряється, що вона має достатньо політичної влади. Це гарантує, що жодна інша країна не зможе отримати цю подію. Вказувати тег необов'язково, якщо сам тригер вже передбачає певний тег (наприклад,has_completed_focus
з фокусним деревом, специфічним для тегу), але в іншому випадку це необхідно. - Невиправдане використання автоматично запускаються подій замість тих, що запускаються лише за тригером (погана практика/оптимізація) – Це більше погана практика, ніж помилка. Загалом, якщо умову події можна запустити ефектом, це слід зробити.
Приклад — найочевидніший спосіб зробити це: перевіркаhas_completed_focus
замість прямого запуску в фокусі. Однак можуть виникати й інші такі випадки, наприклад, коли починається війна між двома країнами, коли штат окуповано, або для запуску події в певну дату. Найкращою практикою є перевіркаon_actions
перед створенням автоматично запускається події, щоб побачити, чи можна їх відтворити. Запуск через ефект має перевагу миттєвості замість очікування до 20 днів. За бажанням можна додати затримку в кілька годин, щоб це виглядало природніше для гравця. Крім того, це служить способом оптимізації модифікації, оскільки зменшує кількість повторних перевірок тригерів. Події з великим середнім часом до настання особливо погані для продуктивності і в деяких випадках можуть бути замінені блоком ефектів, що запускає подію з великою затримкою, створеною за допомогоюrandom_days
всередині ефекту. - Вузькі межі для тригерів дати (подія ніколи не спрацьовує)/Автоматично запускається подія, призначена для запуску в певну дату (подія спрацьовує пізніше, ніж передбачалося) – Блок
trigger = { ... }
перевіряється кожні 20 днів за замовчуванням, і це неможливо змінити лише для однієї конкретної події. Якщо тригери дати встановлені з вузькими верхньою та нижньою межами (наприклад,date > 1936.1.1
таdate < 1936.1.3
), дуже ймовірно, що подія ніколи не спрацює, оскільки це не змусить гру перевіряти тригер у цю дату, а просто не дозволить їй запустити подію, якщо діапазон ніколи не перевіряється, оскільки гра не бачить у майбутнє і не може передбачити, що тригер буде істинним чи хибним у якийсь момент. Аналогічно, просто розміщенняdate > 1936.1.1
не гарантує, що подія спрацює рівно другого січня, але це може бути будь-який день між 2-м та 21-м (хоча це буде той самий день при кожному скиданні).
Щоб запустити подію в певну дату, найкраще запустити її при запуску гри з необхідною затримкою, встановивши подію так, щоб вона ніколи не спрацьовувала сама по собі за допомогоюis_triggered_only = yes
, і опціонально додавши додаткові передумови для її появи всерединіtrigger = { ... }
, які будуть перевірені в момент, коли подія має з'явитися. Щоб розрахунок кількості днів був правильним, високосні дні слід ігнорувати, оскільки гра їх не містить.
Можна використовувати будь-який блок ефектів, виконаний до або під час запуску. Приклад використанняon_startup
вon_action
наведено далі в статті. - Встановлення новинної події на одноразовий запуск або невстановлення її як великої (новинна подія спрацьовує лише для однієї країни) – Подія вимагає
major = yes
, щоб з'явитися для кожної країни. Новинні події є суто переоформленням подій країни і за замовчуванням не налаштовані на запуск для кожної країни, тому цей рядок є обов'язковим. Крім того, події, які спрацьовують лише один раз, не з'являються більше одного разу глобально, а не для кожної країни. Поява події для більш ніж однієї країни вважається її повторним запуском, тому встановлення події на одноразовий запуск призведе до того, що лише одна країна отримає новинну подію замість кожної, як передбачалося.
3.2. Неінтуїтивні зареєстровані помилки
Event is triggered only, but does not have a 1 base-factor.
– Це трапляється, коли в події є суперечливі аргументи щодо того, чи дозволено їй запускатися автоматично, чи її можна запустити лише вручну. Зокрема,mean_time_to_happen = { ... }
має ефект лише тоді, коли подію можна запустити лише автоматично. Однак, якщо подія запускається лише за тригером, вона не може бути запущена автоматично, що призводить до створення помилки.Event is set to trigger every day.
– Це трапляється, коли для події істинне все наступне:- Подію можна запустити автоматично. Іншими словами,
is_triggered_only = yes
відсутній у події. - Середній час до настання події становить 1 день або менше. Якщо його пропущено, вважається 1 день.
- Подія може спрацювати більше одного разу. Іншими словами,
fire_only_once = yes
відсутній у події.
trigger = { ... }
оцінюється як істинний у перевірці, що відбувається кожні 20 днів. Щоб усунути помилку, будь-яку з трьох необхідних умов можна зробити неістинною для події. Наприклад, у багатьох випадках можна зробити так, щоб подія не запускалася автоматично, а замість цього використовувати блок ефектів для її запуску, наприклад, за допомогоюon_actions
.- Подію можна запустити автоматично. Іншими словами,
Malformed token: event_id.123, near line
на рядку, що вказує ID події – Це трапляється, якщо простір імен події не було додано належним чином.Failed to create id 12300000 50. Already exists in game. This might crash the game. Reverse id lookup: id 12300000 = my_namespace.0
– Зауважте, що це та сама помилка, розділена на дві, а не дві окремі помилки, як може здатися на перший погляд. Це означає, що внутрішній ID події використовується 2 або більше подіями. Існують такі причини появи цієї помилки:- Помилкове розміщення 2 подій з абсолютно однаковим ID –
id = my_namespace.0
включено до двох подій одночасно. Це самоочевидно. - Використання нецілочисельних значень як числового ID після простору імен – Одна подія має
id = my_namespace.abc
, інша —id = my_namespace.cba
. Через те, як гра генерує внутрішні ID, нечисловий ID не підтримується, завжди стаючи числом 0. Таким чином, це абсолютно однакові ID, навіть якщо вони виглядають по-різному. - Використання числового ID, не меншого за 100000 – Дві події в різних просторах імен отримали однакові внутрішні ID. Завдяки тому, як гра генерує внутрішні ID, кожному простору імен присвоюється 100000 числових ID, від 0 до 99999. Усе, що більше, почне зазіхати на ID інших просторів імен. Гра повністю дозволяє такі великі числа як числові ID, тому подія може працювати, але дублікат внутрішнього ID означає, що існує пара подій, які розглядаються як одна й та сама подія, тобто одна з них запускатиме іншу.
- Помилкове розміщення 2 подій з абсолютно однаковим ID –
4. Приклад файлу події
add_namespace = my_event
add_namespace = my_hidden_event
country_event = {
id = my_event.1
title = my_event.1.t
desc = my_event.1.desc
is_triggered_only = yes
option = {
name = my_event.1.a
add_political_power = 100
}
}
add_namespace = my_news_event
news_event = {
id = my_news_event.1
title = {
text = my_news_event.1.t.a
trigger = {
tag = POL
}
}
title = {
text = my_event.1.t
}
desc = {
text = my_news_event.1.desc.a
trigger = {
tag = POL
}
}
desc = {
text = my_event.1.desc
}
picture = GFX_my_news_event_picture
is_triggered_only = yes
major = yes
option = {
name = my_news_event.1.a
trigger = {
tag = POL
}
}
option = {
name = my_news_event.1.b
trigger = {
NOT = { tag = POL }
}
}
option = {
name = my_news_event.1.c
original_recipient_only = yes
}
}
country_event = {
id = my_hidden_event.1
trigger = {
has_country_flag = event_happened
country_exists = BHR
}
mean_time_to_happen = {
days = 10
months = 2
years = 1
modifier = {
base = 300
country_exists = QAT
}
modifier = {
add = 10
country_exists = OMA
}
}
fire_only_once = yes
hidden = yes
immediate = {
random_country = {
limit = {
is_neighbor_of = BHR
}
annex_country = {
target = BHR
transfer_troops = yes
}
}
}
}
state_event = {
id = my_event.2
title = my_event.2.t
desc = my_event.2.desc
picture = GFX_my_event_picture
trigger = {
ROOT = {
has_country_flag = fire_this_event
}
}
is_triggered_only = yes
option = {
name = my_event.2.a
transfer_state_to = ROOT
}
option = {
name = my_event.2.b
ai_chance = {
base = 0 # Ніколи не обирати цю опцію.
}
transfer_state_to = FROM
}
}
4.1. Інтеграція з on_actions
Див. також: On actions
Це основні типи подій, які запускаються через on_actions
:
add_namespace = on_action_events
news_event = { # Новинна подія про захоплення міста
id = on_action_events.1
title = on_action_events.1.t # Падіння Гізи
desc = on_action_events.1.desc
is_triggered_only = yes
major = yes
option = {
trigger = {
OR = {
tag = EGY
is_in_faction_with = EGY
is_subject_of = EGY
}
}
name = on_action_events.1.a
}
option = {
trigger = {
NOT = {
tag = EGY
is_in_faction_with = EGY
is_subject_of = EGY
}
}
name = on_action_events.1.b
}
}
country_event = { # Запускається в певний день, якщо умови виконані
id = on_action_events.2
title = on_action_events.2.t
desc = on_action_events.2.desc
is_triggered_only = yes # Запобігає автоматичному запуску.
trigger = {
has_completed_focus = BHR_focus_name # Якщо фокус не завершено, ніколи не спрацює.
}
option = {
name = on_action_events.2
}
}
country_event = { # Інші типи on_actions
id = on_action_events.3 # У цьому випадку, запит при анексії країни з опцією її звільнення.
title = on_action_events.3.t
desc = on_action_events.3.desc
is_triggered_only = yes # Запобігає автоматичному запуску.
trigger = { # Якщо всі корінні штати FROM є корінними або заявленими ROOT, ніколи не має з'являтися.
NOT = { # Запускається всередині random_events = { ... } в on_annex, тому має той самий FROM, що й on_action
any_state = {
NOT = {
is_core_of = ROOT
is_claimed_by = ROOT
}
is_core_of = FROM
}
}
FROM = {
NOT = {
tag = GER # Має окрему подію
}
}
}
option = {
name = on_action_events.3.a # "Звільнити [FROM.GetName] як маріонетку"
every_owned_state = {
limit = {
is_core_of = FROM
NOT = {
is_core_of = ROOT
is_claimed_by = ROOT
}
}
transfer_state_to = FROM
}
if = {
limit = {
has_dlc = "Together for Victory"
}
set_autonomy = {
target = FROM
autonomy_state = autonomy_integrated_puppet
}
}
else = {
puppet = FROM
}
}
option = {
name = on_action_events.3.b # "Не звільняти [FROM.GetName]"
add_stability = -0.1
add_war_support = -0.1
}
}
Щоб це запустити, потрібно створити код у будь-якому файлі /Hearts of Iron IV/common/on_actions/*.txt
, іноді в поєднанні з булевими прапорами, щоб запобігти їх повторному запуску, якщо fire_only_once
неможливий. У наведеному вище прикладі буде використано таке:
on_actions = {
on_state_control_changed = {
effect = {
if = {
limit = {
FROM.FROM = {
state = 999 # Власний ID штату. Гра вилетить, якщо не існує.
}
NOT = {
has_global_flag = giza_fall # Щоб запобігти подвійному запуску.
} # Через 'major = yes', fire_only_once НЕ спрацює
}
news_event = { id = on_action_events.1 hours = 6 random_hours = 3 } # Запускається через 6-9 годин, щоб виглядати природніше.
}
}
}
on_startup = {
effect = {
BHR = {
country_event = {
id = on_action_events.2
days = 357
random_days = 7 # Запускається в останній тиждень 1936 року, припускаючи стандартну дату початку.
}
}
}
}
on_annex = {
random_events = {
1 = on_action_events.3
}
}
}
4.2. Інтеграція з історією
Див. також: Створення країни#Історія
Альтернативно, ви можете запустити подію всередині файлу /Hearts of Iron IV/history/countries/*.txt
:
# history/countries/BHR - Bahrain.txt
# Інший код пропущено
country_event = {
id = on_action_events.2
days = 357
random_days = 7 # Запускається в останній тиждень 1936 року, припускаючи стандартну дату початку.
}
5. Примітки та посилання
[a] Подія із затримкою
[1] `NEngine::PINGER_EVENT_DELAY_DAYS` (20 днів) в defines.
[2] `NEngine::EVENT_TIMEOUT_DAYS` (13 днів) в defines.