Модинг HOI4 (Розширений Переклад)

Модинг

Модинг, або створення модів, — це процес модифікації поведінки базової гри (часто званої "ванільною версією"), або для особистого користування, або для публічного випуску для інших гравців, наприклад, через Майстерню Steam.

Як і всі ігри Paradox, Hearts of Iron IV значною мірою піддається Модингу. Мотивації моддерів можуть сильно відрізнятися: кращий переклад на рідну мову, більше подій чи рішень, кращі карти, капітальний ремонт гри тощо.

Моди зберігаються в папці mod/ у каталозі користувача. Разом з модами гра завантажуватиме будь-які файли, що зберігаються в каталозі користувача. Внутрішній редактор карт гри, Nudger, зберігає свої результати в цій папці. Шлях до папки, що містить файли мода, не може містити жодних символів, що не належать до ASCII, таких як літери з діакритичними знаками або нелатинський шрифт.

Гра читатиме будь-який файл .mod у папці mod/, а локальний мод можна створити через лаунчер: "Усі встановлені моди" -> "Завантажити мод" -> "Створити мод". Це обмежує параметри шляху та дозволеної структури мода, тому може знадобитися ручне редагування результату.

Моди не можуть збігатися за назвою; у такому випадку лише перший завантажений мод (визначений за назвою файлу дескриптора користувача) матиме будь-який ефект у грі.

Зміст

1. Офіційні відеоуроки
2. Рекомендації
3. Текстовий редактор
- 3.1. Пошук у кількох файлах
- 3.2. Відступи
4. Універсальні концепції Модингу
5. Структура мода
- 5.1. Зміст дескриптора
  - 5.1.1. replace_path
6. Ігрові дані
7. Інструменти та утиліти
8. Поширені помилки
9. Корисні знання
10. Див. також
11. Примітки

1. Офіційні відеоуроки

Офіційні посібники з Модингу від Paradox на Youtube.

Beginner's Modding Guide (Посібник з Модингу для початківців)
Intermediate Modding Guide (Посібник з Модингу для середнього рівня)

2. Рекомендації

Ніколи не змінюйте файли гри: використовуйте мод навіть для невеликих змін і ніколи не змінюйте безпосередньо файли гри в папці Steam Hearts of Iron 4, оскільки ваші зміни можуть бути скасовані без попередження.
Мінімізуйте перезапис ванільних файлів, додаючи окремі файли та завантажуючи з папок, коли це можливо, для покращення сумісності та обслуговування модів. (Ваші файли можуть мати будь-яку назву, всі файли в папці будуть завантажені грою. Тому оберіть назву, яку ніхто інший не використовуватиме, наприклад, назву вашого мода. Приклад: coolmod_countries)
Використовуйте належний інструмент для злиття (наприклад, WinMerge), щоб зливати вміст папок та оновлювати змінені ванільні файли до нової версії гри.
Робіть резервні копії своєї роботи, щоб не втратити все. Розгляньте можливість використання системи контролю версій, такої як Git, та платформи для спільної розробки, наприклад GitHub або Gitlab, для управління командною співпрацею або просто робіть копії файлів в іншому місці. Збереження версій через Github або Gitlab також може бути дуже корисним для налагодження, оскільки обмежує вибір потенційно пошкоджених файлів.
The Modding Git Guide — це посібник, створений спільнотою, для використання Git, GitHub/GitLab та пов'язаних інструментів, таких як KDiff3. Він може бути корисним джерелом відповідей на питання, що виходять за рамки цієї вікі, і містить покрокові інструкції для багатьох речей, про які тут йдеться.
Використовуйте кодування UTF-8 без позначки порядку байтів (BOM) для текстових файлів. Це зазвичай називається "UTF-8", але іноді може бути вказано як "UTF-8 without BOM".
Використовуйте кодування UTF-8 з позначкою порядку байтів (BOM) для файлів локалізації (.yml). Це зазвичай називається "UTF-8-BOM", але може бути просто "UTF-8", у такому випадку пропуск позначки порядку байтів є окремою опцією. Деякі текстові редактори, такі як Atom, повністю не підтримують позначку порядку байтів і їх слід уникати для локалізації.
Використовуйте коментарі, що починаються з символу #, щоб пам'ятати причини написання складних речей. Один символ решітки зробить решту рядка повністю проігнорованою. У коді немає нотації для багаторядкових коментарів.
Ефективно налагоджуйте, увімкнувши режим налагодження. Зробіть це, додавши -debug до параметрів запуску в Steam. Параметри запуску доступні в меню, яке відкривається клацанням правою кнопкою миші по грі та вибором "Властивості...".
Альтернативно, у Windows можна створити ярлик до файлу hoi4.exe або dowser.exe, а потім відкрити властивості ярлика та додати -debug (через пробіл) після кінця шляху, наприклад: "C:\Program Files (x86)\Steam\steamapps\common\Hearts of Iron IV\hoi4.exe" -debug.

3. Текстовий редактор

Це найпоширеніші текстові редактори для Модингу гри:

Visual Studio Code.
- Має розширення CWTools, створене фанатами, з підсвічуванням синтаксису Paradox, валідацією та підказками для тригерів та ефектів. Щоб встановити його, перейдіть до Extensions на лівій панелі VS та знайдіть CWTools. (Примітка: правила валідації неповні та показуватимуть багато помилкових помилок у файлах gui та локалізації).
- Останні версії з автоматичним підсвічуванням пар {} різними кольорами та позначенням відкриваючих/закриваючих дужок, у яких відсутня пара, червоним кольором, варті золота.
Notepad++. Оберіть Perl як мову, оскільки це забезпечить гарне підсвічування та дозволить згортати блоки коду та коментарів. Щоб встановити це за замовчуванням, перейдіть до Settings, Style Configurator, знайдіть Perl у списку зліва та додайте "gui txt" (без лапок) до поля "User ext." унизу.
- Деякі опції, які зазвичай увімкнені за замовчуванням в інших текстових редакторах, вимкнені в Notepad++, але їх можна змінити на верхній панелі. Це включає Word wrap, Document map, Indent guide та Folder as workspace.
Sublime Text. Існує розширення для нього, випущене розробниками Imperator, яке можна було б використовувати з HOI4, але використовуйте на свій страх і ризик: Sublime Tools. Воно додає кольорове підсвічування для ефектів та тригерів. Якщо ви хочете перемикати коментарі в Sublime, вам також потрібно додати цей файл до тієї ж папки "User".

Причини використання не стандартного текстового редактора включають наступне:

Підсвічування дужок та синтаксису. Підсвічування дужок полегшує виявлення будь-яких відсутніх або непотрібних файлів, дозволяючи вибрати дужку та побачити, де вона відкривається або закривається, щоб знати, що знаходиться всередині цього блоку. Підсвічування синтаксису може зробити код легшим для читання, підсвічуючи важливіші частини, а також виключаючи дужки всередині коментарів з розгляду.
Пошук у кількох файлах в одній папці. У кожному наданому інструменті це активується гарячою клавішею Ctrl + Shift + F і може мати фільтри імен файлів для обмеження файлів, які шукаються (наприклад, *.txt шукатиме лише текстові файли, ігноруючи будь-які інші файли, такі як *.dds).
Кожен рядок нумерується збоку. Оскільки лог помилок зазвичай вказує на рядок, де присутня помилка, це значно прискорює пошук відповідного рядка порівняно з тим, як Microsoft Notepad лише повідомляє номер поточного вибраного рядка внизу.
Більші можливості для роботи з кількома файлами. Кожен з цих редакторів може мати лише один екземпляр, відкритий одночасно з кількома відкритими файлами (перемикання між ними за допомогою Ctrl + Tab), на відміну від Microsoft Notepad, який відкриває окремий екземпляр для кожного відкритого файлу, що може швидко заповнити меню Alt + Tab. Однак все ще можна відкривати кілька екземплярів текстового редактора. Інструмент порівняння тексту також існує в кожному з них: плагін "ComparePlus" у Notepad++, пакет "Compare Side-By-Side" або "Diffy" у Sublime Text, або різноманітні розширення Visual Studio Code ("Partial Diff" є найпопулярнішим).
Більші можливості налаштування: кожен з цих текстових редакторів дозволяє широкий вибір світлих або нічних тем, які можна вибрати за бажанням, також існують теми для завантаження. Оскільки під час Модингу доведеться багато дивитися на текстовий редактор, вибір теми, яка добре виглядає для очей, може значно покращити досвід.

3.1. Пошук у кількох файлах

Однією з особливостей не стандартних текстових редакторів є можливість гнучкого пошуку по всіх файлах у межах однієї папки. Це надзвичайно корисно для усунення помилок та знаходження розташування певних елементів. Windows File Explorer є поганим вибором для цього, оскільки він шукає лише всередині файлів .txt, тоді як може бути бажано шукати файли інших розширень, наприклад, .yml, .gfx, .gui або .asset, і він помітно повільніший, ніж будь-який текстовий редактор: пошук, що займає ~10 секунд у текстовому редакторі, може тривати до 15 хвилин у Windows File Explorer.

Ось як саме ця функція вмикається у поширених текстових редакторах:

Notepad++ – Ця функція знаходиться в меню "Search" на верхній панелі як "Find in Files...". За замовчуванням папка не вказана. "Follow current doc." дозволяє текстовому редактору автоматично вводити папку поточного відкритого документа як місце для пошуку, або її можна ввести вручну. Альтернативно, це меню можна відкрити з контекстного меню папки в меню "Folder as Workspace" – доступ до якого здійснюється кнопкою на верхній панелі – що автоматично встановить розташування папки на цю папку. Гаряча клавіша Ctrl+Shift+F також відкриває меню для цієї функції за замовчуванням.
Sublime Text – Ця функція знаходиться в меню "Find" на верхній панелі як "Find in Files...". Щоб додати папку для пошуку, можна відкрити меню праворуч від рядка "Where:", де кнопки "Add Folder" (для вибору окремої папки) або "Add Open Folders" (для автоматичного вибору всіх папок, відкритих через Sublime Text) служать для цього. Гаряча клавіша Ctrl+Shift+F також відкриває меню для цієї функції за замовчуванням.
Visual Studio Code – Visual Studio Code за замовчуванням шукає лише в поточній відкритій папці. Папка відкривається або через кнопку "Open Folder..." у меню "File" на верхній панелі, або в меню "Explorer", доступ до якого здійснюється через панель зліва. Після цього функціонал можна знайти в меню "Edit" як "Find in Files". Щоб шукати в інших папках, відкрийте меню 'search details', представлене трьома крапками, і введіть повний шлях до папки в область 'Files to include'. Щоб прискорити пошук, можна використовувати фільтри імен файлів. Наприклад, localisation/english/*.yml у "files to include" шукатиме лише кожен файл *.yml у папці <поточна відкрита папка>/localisation/english/, де * означає будь-яку кількість (включаючи 0) будь-яких символів у назві файлу. Подібні фільтри можна використовувати в попередніх двох текстових редакторах, однак без можливості фільтрувати папки — лише імена файлів. Гаряча клавіша Ctrl+Shift+F також відкриває меню для цієї функції за замовчуванням.

Фільтр за розширенням файлу можна встановити для прискорення пошуку. Це залежить від текстового редактора. Зауважте, що * використовується для позначення будь-якої кількості будь-яких символів, і це універсально.

У Notepad++ це робиться за допомогою меню 'filter'. Фільтри розділяються пробілами, а знак оклику на початку позначає його як фільтр виключення. Наприклад, *.yml !*french.yml призведе до пошуку всіх файлів локалізації, крім французьких.
У Sublime Text це знаходиться в меню 'where'. Фільтри розділяються комами, а знак мінус на початку позначає його як фільтр виключення. Наприклад, C:\Program Files (x86)\Steam\steamapps\common\Hearts of Iron IV\, *.txt, -GER* шукатиме кожен текстовий файл у базовій грі (припускаючи стандартне розташування у Windows на Steam), за винятком тих, що починаються з GER.
У Visual Studio Code це знаходиться в меню, що викликається кнопкою 'Toggle Search Details', представленою трьома крапками. Це меню має окремі меню "Files to include" та "Files to exclude", які використовуються відповідно. Крім того, це дозволяє представляти назви папок у меню, причому подвійний * (як у **) використовується для представлення довільної назви папки. Наприклад, *.gfx у "Files to include" та dlc/** у "Files to exclude" шукатиме кожен файл з розширенням .gfx, за винятком тих, що знаходяться в папці dlc.

Існують такі способи використання цієї функції:

Знаходження внутрішнього ID шляхом пошуку в папці локалізації за локалізованою назвою. Наприклад, пошук заголовка події може бути використаний для визначення ID.
Знаходження місця визначення запису бази даних певного типу, коли це не є інтуїтивно зрозумілим. Наприклад, пошук ID обладнання в папці, що зберігає обладнання (або навіть /Hearts of Iron IV/common/ загалом), може бути використаний для знаходження точного файлу, що не є очевидним для деяких типів обладнання.
Підмножина цього включає знаходження розташування спрайтів або елементів інтерфейсу: консольна команда gui (або її еквівалент у головному меню в режимі налагодження) може бути використана для знаходження назви певного SpriteType (з префіксом GFX_) або елемента інтерфейсу. Пошуковий запит із заданою назвою в папці /Hearts of Iron IV/interface/ надасть файл, де визначено спрайт (таким чином, також надаючи texturefile, що вказує шлях до зображення в gfx) або папку інтерфейсу (що дозволяє скопіювати його до моду та редагувати).
Розв'язання неінтуїтивних помилок, де місцезнаходження не вказано, наприклад, Invalid Decision Category, де це може бути використано для визначення, який файл викликає помилку.
З'ясування, що може спричинити певну подію, наприклад, що запускає певну подію або що встановлює певний косметичний тег.
Виконання масових замін у кількох файлах одночасно, зазвичай використовується разом з регулярними виразами. Це може бути використано для автоматизації монотонних завдань, таких як додавання логу до кожної події, або найпростіше для зміни власника в кількох штатах (наприклад, коментуючи попереднього власника та вставляючи іншого, замінюючи owner= на owner=XYZ#).

3.2. Відступи

Ще однією причиною використання не стандартних текстових редакторів є кращі можливості для роботи з відступами. Відступи — це використання нових рядків та пробілів на початку рядка, що не впливає на інтерпретацію коду, але полегшує візуальне сприйняття зв'язків між різними частинами коду. Зазвичай як один рівень відступу використовується або символ табуляції (представлений як \t), або 4 пробіли, розміщені від початку рядка до початку коду в рядку. Щоб збільшити рівень відступу коду, у текстових редакторах використовується клавіша Tab, що можна зробити для кількох рядків одночасно, виділивши їх. І навпаки, Shift+Tab використовується для зменшення рівня відступу рядка на один.

Додатковою опцією, присутньою в цих редакторах, є 'Indent guide' (напрямна відступів), що малює лінію на кожному рівні відступу, щоб полегшити бачення меж кожного рівня відступу, що може допомогти в читанні коду. Хоча ця опція увімкнена за замовчуванням у Sublime Text та Visual Studio Code, її потрібно вмикати вручну в Notepad++ на верхній панелі.

Ось типові угоди, що використовуються для відступів:

Перший рядок файлу має нульовий відступ.
Відкриваюча дужка та відповідна їй закриваюча дужка повинні розміщуватися в рядках з однаковим рівнем відступу.
Якщо рядок вводить незакриту відкриваючу дужку, то все до відповідної закриваючої дужки повинно бути на один рівень відступу правіше порівняно з рядком з відкриваючою дужкою.
Рядок не повинен містити більше однієї дужки кожного типу.
Якщо рядок містить закриваючу дужку, не містячи відкриваючої дужки, то він не повинен містити нічого, крім закриваючої дужки та відступу перед нею.

Ось приклад правильного відступу:

TAG = {
    if = {
    |    limit = {      // Символ "|" використовується для візуалізації напрямної відступів, а не в коді.
    |    |    has_stability > 0.5
    |    |    has_war_support > 0.5
    |    }
    |    country_event = { id = my_event.1 hours = 1 }
    }
}

Правильні відступи мають дві основні переваги:

Легко побачити, де міститься аргумент, перемістившись на один рівень відступу вліво, а потім слідуючи лінії напрямної відступів, доки вона не досягне коду.
Легко знайти, що знаходиться всередині блоку, слідуючи лінії напрямної відступів від рядка з відкритою дужкою до точки, де вона досягає закриваючої дужки.

Деякі поширені помилки, які слід перевіряти у відступах:

Непотрібне зменшення рівня відступу. Це зазвичай можна виявити, помітивши будь-які переривання в лінії, згенерованій напрямною відступів, від рядка з відкриваючою дужкою до закриваючої дужки:

ideas = {
    country = {
    |   my_idea_1 = {
    |   |   modifier = {
    |   |   |   political_power_gain = 0.1
    |   |   } // закриває modifier = { ... }
    |   my_idea_2 = { // Перериває лінію від my_idea_1 до закриваючої дужки, тому є помилковим
    |   }             // Не працює через розташування всередині my_idea_1
    }
}
characters = {
    my_character = {
    |   name = character_name
    |
    portraits = {  // Помилково
    |   civilian = {
    |   |   large = GFX_my_sprite
    |   }
    } // закриває portraits = { ... }
    my_character_2 = { // Не працює через розташування всередині іншого персонажа
    |   <...>
    }
}

Розміщення закриваючої дужки на тому ж рівні, що й попередній скрипт:

if = {
    limit = {
        my_scripted_trigger = yes
    }
    } // Закриває оператор if, і тому мав бути на один рівень лівіше, щоб відповідати рівню відступу оператора if.
    my_scripted_effect = yes // Завжди виконується, оскільки знаходиться поза оператором if.
}
country_event = {
    id = my_event.1
    option = {
        name = my_event.1.a
        } // Закриває option = { ... }
    }     // Закриває country_event = { ... }
    option = { // Не працює, оскільки визначено поза подією.
        <...>
    } // Ця фігурна дужка зайва або не на місці

Недодавання рівня відступу після незакритої відкриваючої дужки:

my_technology_1 = {
enable_building = { // Має бути відступ
    building = industrial_complex
    level = 20
} // Закриває enable_building
my_technology_2 = { // Всередині my_technology_1 = { ... }, не працює.
    ...
} // Закриває my_technology_1

Розміщення сусідніх рядків з різницею щонайменше у 2 рівні відступів:

focus = {
    <...>
    completion_reward = {
        TAG = { // Має бути відступ
            country_event = my_event.1
    } // Закриває TAG = { ... }
}     // Закриває completion_reward = { ... }
// Тут мала б бути закриваюча дужка для focus
focus = { // Не працює через те, що міститься всередині іншого focus = { ... }
    <...>
} // Закриває другий focus

Дотримання правил відступів та перевірка на ці помилки відступів забезпечать відсутність помилок, пов'язаних з дужками, у коді.

4. Універсальні концепції Модингу

Настійно рекомендується вимкнути приховування розширень файлів у Провіднику Windows, якщо ви використовуєте Windows. Розширення файлів вважаються частиною імені файлу, і їх приховування може призвести до того, що файли не працюватимуть через неправильні імена файлів (наприклад, випадкове збереження файлів локалізації як файлів .txt, збереження зображення в неправильному форматі та нерозуміння цього тощо).

4.1. Каталог користувача

Каталог користувача використовується для зберігання інформації, пов'язаної з Hearts of Iron IV, яка не вбудована в гру, а створена користувачем. Розташування визначається gameDataPath у файлі /Hearts of Iron IV/launcher-settings.json базової гри. За замовчуванням каталог користувача для Hearts of Iron IV знаходиться в таких папках:

Windows: C:\Users\<Username>\Documents\Paradox Interactive\Hearts of Iron IV\ або C:\Users\<Username>\OneDrive\<Documents (мовою системи)>\Paradox Interactive\Hearts of Iron IV\
Mac OS: ~/Documents/Paradox Interactive/Hearts of Iron IV/
Linux: ~/.local/share/Paradox Interactive/Hearts of Iron IV/

Зокрема, примітним вмістом каталогу користувача є:

Дескриптори модів, специфічні для користувача, знаходяться в папці /Hearts of Iron IV/mod/. Це використовується для призначення інформації про мод, такої як шлях до папки, що містить мод. Ця ж папка містить стандартне розташування локальних модів після їх створення в лаунчері, хоча для цього може використовуватися будь-яка папка.
Результати роботи Nudger зберігаються в цій папці. Зокрема, /Hearts of Iron IV/map/, /Hearts of Iron IV/history/states/ та /Hearts of Iron IV/localisation/ можуть бути створені користувачем як результати роботи Nudger. Звідси вони завантажуватимуться в гру при її відкритті, маючи пріоритет над файлами базової гри.
Логи гри створюються в /Hearts of Iron IV/logs/. Звідти їх можна використовувати для усунення несправностей або отримання корисної інформації. Див. також § Логи.
Файли збережень зберігаються в /Hearts of Iron IV/save games/.
Знімки екрана гри зберігаються в /Hearts of Iron IV/screenshots/. Це включає як звичайні знімки екрана F11, так і карту, згенеровану за допомогою F10, яка є піксельно точним представленням всієї карти світу, що бере межі провінцій з /Hearts of Iron IV/map/provinces.bmp.
/Hearts of Iron IV/settings.txt модифікується меню налаштувань гри та включає деякі налаштування, які неможливо змінити там. Зокрема, save_as_binary=no неможливо змінити ніде інде, як і зміну стандартного текстового редактора, що використовується грою.

Якщо в шляху до каталогу користувача є символи, що не належать до ASCII, він може не працювати належним чином. Зокрема, гра не зможе відкрити error.log (але все одно змінить його) або моди, що зберігаються там. Щоб обійти це, можна або перемістити лише моди в іншу папку, змінивши шлях у дескрипторі, специфічному для користувача, або перемістити весь каталог користувача, відредагувавши /Hearts of Iron IV/launcher-settings.json та перемістивши файли відповідно.

4.2. Завантаження файлів

Після створення папки мода в лаунчері, кожен файл у ній завантажуватиметься в тому ж місці, що й у базовій грі. На прикладі мода з назвою "yourmod", кожен файл у mod/yourmod/common/national_focus завантажуватиметься разом з файлами базової гри в /Hearts of Iron IV/common/national_focus, припускаючи стандартний шлях. Однак, вставка ще однієї папки, як у mod/yourmod/test/common/national_focus, призведе до того, що файли в цій папці не завантажуватимуться як файли національних фокусів, ігноруючись.

Коренева папка мода, яка вважається такою ж, як папка /Hearts of Iron IV/ у базовій грі, буде визначена у файлі /Hearts of Iron IV/mod/yourmod.mod каталогу користувача, який відкривається текстовим редактором. Це встановлюється через path = "" у цьому файлі, за замовчуванням це /Hearts of Iron IV/mod/yourmod каталогу користувача.

Базова гра завантажується першою, тоді як моди завантажуються пізніше. Порядок завантаження файлів в основному використовується для визначення двох речей:

У випадку файлів з однаковою назвою в одному місці, порядок завантаження вирішує, який з них буде використаний. Наприклад, якщо мод та базова гра редагують ../events/Generic.txt, гра прочитає версію мода. Це стосується лише окремих файлів, а не цілих папок. Ніколи неможливо, щоб кілька файлів з однаковою назвою в одному місці були завантажені: гра вибере лише пізніше завантажений файл і проігнорує старіші.
У випадку використання replace_path у дескрипторі мода, порядок завантаження вирішує, які файли будуть вивантажені з вказаної папки.

Крім replace_path, немає способу повністю вивантажити файл, хоча його можна перезаписати, якщо є файл з такою ж назвою.^[a] Наприклад, якщо єдиним файлом у моді є ../common/national_focus/generic.txt, то він перезапише лише загальне дерево національних фокусів базової гри, але інші дерева національних фокусів залишаться такими ж, як у базовій грі. Якщо інший мод редагує лише інше дерево фокусів (наприклад, новий malta.txt), то гра прочитає зміни до загального дерева національних фокусів, прочитає malta.txt, а решта залишиться як у базовій грі.

Порядок завантаження в грі такий:

Базова гра. Через те, що вона найраніша в порядку завантаження, вона має найнижчий пріоритет у випадку збігу.
DLC, у порядку їх внутрішнього ID (відповідає даті випуску). Наприклад, якщо базова гра, DLC018 та DLC20 містять ../interface/frontendmainviewbg.gfx, гра прочитає лише версію з DLC020 та проігнорує решту. Через обмеження контрольної суми, папки DLC зазвичай містять лише графіку та аудіо, пов'язані з DLC, тоді як код завжди зберігається в самій базовій грі, заблокований перевіркою has_dlc.
Каталог користувача. Хоча зазвичай він обмежений результатами роботи Nudger, будь-яка інша папка також тут працює.
Моди, впорядковані за іменами файлів дескрипторів, специфічних для користувача. Наприклад, якщо моди з дескрипторами mod/abc_mod.mod та mod/xyz_mod.mod обидва перезаписують ../events/my_events.txt, буде прочитана лише версія з мода з дескриптором mod/xyz_mod.mod.

Це можна перезаписати за допомогою dependencies = { ... } у вмісті дескриптора. replace_path не змінює порядок, але використовується для повного вивантаження всього раніше завантаженого з певної папки.

Через те, що DLC є власним джерелом завантажуваних файлів, папка modname/dlc/ та її підпапки не матимуть ефекту. Натомість файл повинен відповідати фактичному місцю завантаження: наприклад, щоб відредагувати ../dlc/dlc023_man_the_guns/music/mtg_music.txt, мод повинен містити modname/music/mtg_music.txt.

Під час процесу завантаження файли залишаються чистим текстом і не інтерпретуються негайно. Винятками є файли, необхідні для роботи екрана завантаження, та локалізація. Після цього відбувається процес інтерпретації/оцінки, який читає текстові файли та створює вміст (наприклад, національні фокуси, країни або штати) відповідно. Імена файлів не мають значення для того, як файл інтерпретується, за невеликими винятками.^[b] Для переважної більшості файлів вони або читаються лише через те, що знаходяться в певній папці (наприклад, національні фокуси), або за прямим посиланням в іншому файлі (наприклад, oob = "TAG_1936" у файлі історії країни завантажує файл /Hearts of Iron IV/history/units/TAG_1936.txt для розташування підрозділів). Це дозволяє у багатьох випадках уникати перезапису файлів базової гри, що полегшує сумісність вмісту мода з наступним великим оновленням.

Для переважної більшості папок, таких як файли /Hearts of Iron IV/interface/*.gfx, для сортування їх за назвою файлу для інтерпретації використовуються ідентифікатори символів ASCII. Це відрізняється від алфавітного сортування, що використовується файловим провідником, оскільки великі літери вважаються такими, що йдуть перед малими літерами, і між ними є кілька символів (наприклад, підкреслення). Щоб розмістити файл особливо високо в порядку оцінки, можна використовувати префікс з пізніми ідентифікаторами символів, такими як zz_, і навпаки для іншого напрямку, причому базова гра зазвичай використовує для цього 00_.

Порядок завантаження не має значення під час оцінки: якщо є збіг записів між різними файлами, гра зазвичай використовує порядок оцінки, щоб визначити, який з них повинен мати пріоритет. Наприклад, якщо базова гра містить штат з ID 123 у файлі 123-ABC.txt, а мод містить інформацію для штату 123 у файлі 123-XYZ.txt, гра надасть пріоритет штату, створеному першим, тобто визначенню базової гри. І навпаки, між 321-WWW.txt у базовій грі та 321-DEF.txt у файлах мода, буде обрано 321-DEF.txt мода. Як саме обробляються дублікати, залежить від конкретного файлу: деякі не обробляють їх добре і їх слід уникати (наприклад, дублікати національних фокусів порушують генерацію ліній передумов), деякі надають перевагу першому створеному запису, деякі — останньому створеному запису.

Зміна порядку інтерпретації має дуже обмежене застосування, але воно існує. Деякі примітні випадки цього включають:

Файли /Hearts of Iron IV/interface/*.gfx, які створюють спрайти, що призначають інформацію зображенням, наприклад, прив'язуючи унікальну назву. Якщо є кілька визначень одного спрайта, використовується лише пізніше оцінений спрайт, а раніший ігнорується. Базова гра помітно використовує це для DLC: якщо персонаж має портрет лише в DLC, то йому буде встановлено використання спрайта як портрета. У базовій грі спрайт встановлено так, щоб він вів до загального портрета, оскільки інакше персонаж може виглядати пошкодженим, що можливо в багатокористувацькій грі. Однак у файлах DLC спрайт, який використовується для портрета, визначається ще раз в окремому файлі пізніше в порядку оцінки, щоб забезпечити використання портрета, доданого DLC, для власників DLC.
Файли /Hearts of Iron IV/common/country_tags/*.txt: порядок визначення тегів країн має значення. Хоча базова гра розміщує порядок оцінки переважно в порядку всередині файлів тут, це все ще актуально. Це вирішує такі речі, як порядок оцінки файлів /Hearts of Iron IV/history/countries/, що може призвести до пошкодження популярності суб'єктів в іншому випадку, порядок оцінки подій/рішень/фокусів/тощо (чи то тригери для їх запуску, чи то вибір ШІ), або порядок, коли область вибирає кілька країн: як оцінених, так і в підказці.

Контрольна сума, 4-символьний буквено-цифровий код, який можна побачити поруч з версією в головному меню, наприклад, a2b4, визначає сумісність для багатокористувацької гри та досягнень: до серверів можна приєднатися лише якщо контрольна сума ідентична контрольній сумі хоста, тоді як досягнення вмикаються лише якщо контрольна сума ідентична контрольній сумі базової гри, яку можна побачити в лаунчері. Список того, що її змінює, можна побачити у файлі /Hearts of Iron IV/checksum_manifest.txt базової гри, який включає цілі папки common/, events/ та history/, а також більшу частину папки map/, крім map/terrain/. Будь-яка зміна файлів у цій папці змінить контрольну суму, тоді як будь-який мод, який їх не змінює, не змінить її.

4.3. Структура папок

Ці папки часто редагуються в модах:

/Hearts of Iron IV/common/: Це основна папка, в якій визначаються майже всі записи бази даних: країни, технології, фокуси тощо.
/Hearts of Iron IV/events/: Папка, яка визначає події.
/Hearts of Iron IV/history/: Ця папка в основному визначає початкову історичну інформацію: які штати належать яким країнам, початкові політичні та дипломатичні ситуації, позиції армій, початкові будівлі тощо. Зазвичай, якщо щось відбувається до вибору будь-якої країни, це визначається тут. Однак початкові залізниці та вузли постачання визначаються в папці /Hearts of Iron IV/map/.
/Hearts of Iron IV/map/: Ця папка використовується для редагування зовнішнього вигляду карти, такого як провінції, показаний рельєф, карта висот тощо. Це також включає стратегічні регіони та початкові вузли постачання та залізниці. Однак межі штатів визначаються в папці /Hearts of Iron IV/history/states/.
/Hearts of Iron IV/localisation/: Ця папка використовується для визначення того, як відображається текст, залежно від поточної увімкненої мови.
/Hearts of Iron IV/gfx/: Ця папка використовується для зберігання зображень. Однак здебільшого ці зображення не завантажуються автоматично, а повинні бути пов'язані в спрайтах. Часто редаговані винятки включають /Hearts of Iron IV/gfx/loadingscreens, де кожен файл завжди завантажується, /Hearts of Iron IV/gfx/flags та підпапки, де країна намагається завантажити прапор при зміні ідеології або косметичного тегу, та файли /Hearts of Iron IV/gfx/interface/equipmentdesigner/graphic_db/*.txt, які призначають спрайти пулам зображень, показаних у дизайнері обладнання. Все інше вимагає спрайта.
/Hearts of Iron IV/interface/ (не плутати з /Hearts of Iron IV/gfx/interface/): Ця папка переважно заповнена файлами *.gfx та *.gui, обидва з яких можна відкрити в текстовому редакторі. Перші визначають графічні записи, що відображаються в грі: спрайти, які призначають назву та властивості (такі як анімація, кількість кадрів або тип завантаження) файлу зображення, шрифти, кольори тексту, стрілки на карті тощо. Останні визначають сам графічний користувацький інтерфейс: як розташовані кнопки та іконки, який GFX використовується де, де писати текст тощо. Це визначає лише зовнішній вигляд GUI, атрибути, такі як ефекти, повинні бути визначені в іншому місці.
/Hearts of Iron IV/music/: Ця папка використовується для визначення пісень, що відтворюються на радіостанціях, та можливостей у зваженому перемішуванні.
/Hearts of Iron IV/sound/: Ця папка використовується для визначення звуків, що відтворюються в іншому місці, зазвичай пов'язаних з елементом GUI. Це також включає такі записи, як голосові репліки дивізій.
/Hearts of Iron IV/portraits/: Ця папка використовується для призначення спрайтів як портретів для випадково згенерованих загальних персонажів.

4.4. Структура коду

Мова скриптів, якою побудований код, завжди має спільну структуру: <атрибут> = <аргумент> (іноді використовуючи знаки нерівності у випадку тригерів), наприклад, add_political_power = 100, за невеликими винятками, де аргумент можна опустити. Кожен атрибут та аргумент є одним словом (символ слова включає групу [a-zA-Z0-9_.,\-/]), а пробільні символи служать роздільниками. Однак існує два типи аргументів, які можуть містити більше одного слова:

Рядки позначаються лапками (лише ") з обох боків. Пробіл не перерве рядок, але прямий перехід на новий рядок перерве. Якщо всередині немає пробільних символів, пропуск лапок не змінить результат (наприклад, date > "1936.1.1" та date > 1936.1.1). У рядках дозволено використовувати два спеціальні символи: \" використовується для написання лапки, а \\ — для написання зворотної косої риски; зворотна коса риска не може використовуватися іншим чином. Неможливо включити перехід на новий рядок безпосередньо всередину рядка. Іноді сам атрибут може бути укладений в лапки, наприклад, "TAG" = { has_political_power > 100 }. Рядок може містити щонайбільше 255 символів, не враховуючи нуль-термінатор.
Там, де текст призначений для відображення гравцеві, наприклад, у підказках, атрибути зазвичай приймають ключ локалізації як аргумент. Це дозволяє відображуваному тексту змінюватися залежно від увімкненої мови та містить більше можливостей, таких як відсутність обмеження в 255 символів або можливості для налаштування тексту (наприклад, кольоровий текст, нові рядки або динамічні зміни). Якщо гра не виявляє визначеного ключа локалізації в базі даних увімкненої мови, вона за замовчуванням відображатиме аргумент безпосередньо.

У певних типах атрибутів фігурні дужки використовуються для приєднання цілого блоку коду як аргументу, який зазвичай складається з іншого коду у тому ж форматі <атрибут> = <аргумент>. Наприклад, random_country = { add_stability = 0.1 } (як ефект) — це атрибут random_country з аргументом { add_stability = 0.1 }; цей аргумент сам складається з атрибута add_stability з аргументом 0.1. Зокрема, це перейде в область випадкової існуючої країни та додасть 10% стабільності.

Якщо атрибут не підтримує групування атрибутів, то використання відкриваючої дужки буде інтерпретовано як сам аргумент. Наприклад, гра інтерпретує transfer_state = { 123 321 } як спробу передати штат з ID {. Після цього гра зустрічає 123, що буде інтерпретовано як перехід в область штату, який буде передчасно перерваний закриваючою дужкою. В результаті з'являється ще одна закриваюча дужка, яка не має відповідної відкриваючої дужки, що, ймовірно, призведе до помилки області видимості, порушуючи решту файлу.

Пропуск аргументу/знака рівності майже завжди є помилковим. Наприклад, це завжди обов'язково там, де очікуються ефекти або тригери, що робить це неправильним: GER = { leave_faction }. Натомість, там, де не очікується аргумент, зазвичай використовується yes, як у GER = { leave_faction = yes }. Існує кілька винятків, де аргумент слід опускати, наприклад, у розширеній формі add_ideas.

Коментарі позначаються символом #: все після цього символу до нового рядка буде повністю проігноровано грою. Наприклад:

completion_reward = {
    add_political_power = 100 #TODO: Перевірити, чи збалансовано
}

Не існує багаторядкового блоку коментарів.

Крім коментарів та рядків, нові рядки розглядаються абсолютно ідентично пробілам як роздільники. В результаті, відступи не мають значення: більшість файлів можна написати в один рядок без будь-яких змін в їх інтерпретації. Однак правильне використання відступів може значно полегшити виявлення проблем з дужками без використання підсвічування дужок текстовим редактором і загалом полегшує швидке розуміння того, що кожен блок містить у собі, а що ні.

Це також означає, що аргумент атрибута ніколи не повинен залишатися порожнім, оскільки гра інтерпретуватиме наступний атрибут як аргумент. Наприклад:

focus = {
    id = TAG_focusname
    icon = 
    x = 2 # Не працюватиме в грі.
}

У цьому випадку атрибут icon фокуса встановлюється як icon = x, і далі гра не знає, як інтерпретувати = 2. На практиці це призведе до того, що фокус не буде в очікуваному місці.

Ось ці типи блоків аргументів особливо поширені:

Ефекти використовуються в таких обставинах, як нагороди за завершення фокусів, опції подій, ефекти рішень, дії "on actions", файли історії країн тощо. Вони використовуються для внесення одноразової зміни в стан гри.
Тригери використовуються в таких обставинах, як перевірки доступності фокусів та рішень, тригери подій або оператори if. Вони повертають строго булеве значення (істина або хиба), не змінюючи нічого в стані гри.
Області видимості (Scopes) — це певна підмножина тригерів та ефектів, які можна використовувати для зміни країни/штату/персонажа/дивізії, для яких виконуються ефекти або перевіряються тригери.
Модифікатори використовуються для застосування постійної числової зміни, такої як щоденний приріст політичної влади. Зазвичай ідеї, такі як "духи", використовуються для застосування їх до країн.

Порядок розміщення атрибутів може мати значення або ні, залежно від контексту. Зокрема, ось загальні правила:

Порядок ефектів та тригерів має найбільше значення: вони виконуються в тому порядку, в якому розміщені, і це визначає їх розміщення в підказці, що відображається гравцеві. Наприклад, якщо блок ефектів спочатку містить annex_country, а потім оператор if, що перевіряє, чи анексована країна володіє штатом, оператор if завжди буде хибним, оскільки країна вже анексована. У тригерах порядок виконання має значення для тимчасових змінних.
Порядок модифікаторів взагалі не має значення, а їх порядок у підказці жорстко закодований.^[d]
Порядок різних атрибутів одного запису не змінює інтерпретацію. Наприклад, якщо нагорода національного фокуса визначена перед його позицією, а не навпаки, як зазвичай, це не буде розглядатися по-іншому.
Для одного типу записів бази даних позиція у файлі використовується для порядку їх створення. Приклади, де цей порядок особливо помітний гравцеві, — це рішення (якщо не перевизначено пріоритетом), будівлі або ідеології.
Цей порядок створення може мати значення в інших посиланнях. Наприклад, в обладнанні тип обладнання повинен бути призначений існуючому архетипу. Якщо архетип не існує під час створення типу обладнання, гра аварійно завершить роботу, навіть якщо визначення є пізніше у файлі.
Там, де це застосовно, назва файлу в основному використовується для оцінки, а порядок всередині файлів є вторинним. Оскільки для цього використовується порядок ASCII, назва файлу, що починається з 00_, зазвичай використовується для забезпечення того, щоб він оцінювався на початку, тоді як початок з zz_ використовується навпаки.
Для одного типу атрибута в записі бази даних інтерпретація варіюється. Якщо підтримується кілька, позиція в коді визначає порядок (наприклад, кожна prerequisite = { ... } у національному фокусі повинна бути виконана, щоб його можна було завершити, або кожна immediate = { ... } у події буде виконана при запуску події). В іншому випадку гра може вибрати найраніше або найпізніше визначення атрибута, ігноруючи інші (наприклад, у скриптованій локалізації буде використано перший дійсний text = { ... }, де тригер виконаний).
Часто один і той же атрибут навмисно дублюється з різними аргументами. Обробка дубльованих атрибутів варіюється і не призначена скрізь. Наприклад, кожен екземпляр focus = { ... } всередині дерева національних фокусів розглядається як окремий національний фокус. Зазвичай, якщо блок ефектів дублюється (наприклад, immediate = { ... } події), кожен виконується в порядку їх розміщення.
Іноді назва атрибута є довільною. Наприклад, в ідеях кожна ідея (розміщена всередині категорії ідей) назва атрибута буде розглядатися як назва ідеї.

4.5. Режим налагодження

Режим налагодження активується за допомогою параметра запуску -debug. Зокрема, є два способи його застосування:

Властивості гри в Steam включають параметри запуску. Клацання правою кнопкою миші по запису гри в списку придбаних ігор викликає меню. Внизу меню знаходиться "Властивості...", що відкриє окреме вікно. Внизу розділу "Загальні" (відкритого за замовчуванням) знаходяться параметри запуску. Кожен параметр запуску вводиться через пробіл, наприклад, -checksum -debug.
У Windows можна застосувати параметр запуску через ярлик до файлу hoi4.exe або dowser.exe у каталозі гри. Після створення ярлика, клацання правою кнопкою миші по ньому та переходу до властивостей, відкриється меню властивостей ярлика. У розділі "Ярлик" властивостей (відкритого за замовчуванням), розділ "Об'єкт" містить шлях до файлу. Параметри запуску вставляються після закриваючої лапки, розташованої після назви файлу. Між лапкою та початком параметра запуску повинен бути щонайменше один пробіл, а подальші параметри запуску також розділяються пробілами. Приклад розділу "Об'єкт": "C:\Program Files (x86)\Steam\steamapps\common\Hearts of Iron IV\hoi4.exe" -debug -start_tag=ALB.

Режим налагодження дуже корисний для Модингу, надаючи такі переваги:

Автоматичне завантаження - Зміни у файлах, зроблені всередині папки мода, відображатимуться в грі без необхідності використовувати консольну команду 'reload'. Це також автоматично додасть помилки у файлах до логу помилок. Це стосується лише файлів, які існували під час запуску гри, за одним винятком: якщо прямий шлях до файлу згадується деінде всередині мода, то він все ще може бути завантажений для цього конкретного використання. Приклади цього включають накази про бойовий порядок, оскільки load_oob = "TAG_my_oob" функціонує як пряме посилання на /Hearts of Iron IV/history/units/TAG_my_oob.txt; або GFX, оскільки спрайти безпосередньо посилаються на розташування зображення. Хоча, зокрема, завантаження зображень у грі не розпаковує їх належним чином, що призводить до видимих спотворень або чорних фонів, які виправляються після перезапуску. Хоча зміни до більшості файлів працюють, це не працює з /Hearts of Iron IV/history/countries/, /Hearts of Iron IV/history/states/ та /Hearts of Iron IV/map/, хоча nudge частково може використовуватися для останніх двох.
Відсутність аварійного завершення через визначення карти - Якщо карта відредагована, є ймовірність появи помилок. Будь-які помилки, пов'язані з картою, призведуть до аварійного завершення гри під час завантаження з повідомленням 'Some errors are present in the map defition[sic] and have been logged to error.log'. Якщо режим налагодження увімкнено, гра продовжить завантажуватися належним чином. Визначення карти відбувається, коли в лозі помилок після завантаження в країну є будь-яка помилка, що містить MAP_ERROR, оскільки певні помилки карти ще не реєструються, коли параметр запуску налагодження відкриває лог під час завантаження головного меню.^[c]
Розширений лог помилок - Певні помилки не реєструються в лозі, якщо режим налагодження не увімкнено. Прикладом можуть бути помилки визначення карти, згадані вище, оскільки гра аварійно завершується, перш ніж встигнути їх зареєструвати. Увімкнення режиму налагодження забезпечить реєстрацію всіх помилок, які можуть бути зареєстровані в лозі помилок.
Легкість відкриття логу помилок - Поки в лозі є будь-які помилки, лог автоматично відкриватиметься під час завантаження гри або після вибору країни. До логу також можна буде отримати доступ, клацнувши на собаку помилок у нижньому правому куті після завантаження в країну, яка з'являється щоразу, коли в лозі з'являється нова помилка (оскільки файли автоматично завантажуються). Якщо повний шлях до каталогу користувача, після розширення gameDataPath у /Hearts of Iron IV/launcher-settings.json, містить будь-які символи, що не належать до ASCII, такі як нелатинський шрифт або діакритичні знаки, то він не зможе відкритися з повідомленням "The system cannot find the path specified", що можна виправити, змінивши папку, що використовується для даних гри, перемістивши файли за потреби.
Легкість доступу до Nudge - З увімкненим режимом налагодження в головному меню з'явиться опція відкриття Nudge. Це може бути корисно для економії часу або для можливості відкрити Nudge, якщо гра аварійно завершується під час спроби завантажитися в країну (це може статися, якщо файл /Hearts of Iron IV/tutorial/tutorial.txt посилається на недійсні штати, якщо цей файл не містить щонайменше одного tutorial = {}, навіть якщо він нічого не містить, якщо вузли постачання та залізниці налаштовані неправильно, або з інших причин).
Інформація про графічний інтерфейс у головному меню - Поки режим налагодження увімкнено, натискання клавіші ` (зазвичай у верхньому лівому куті клавіатур QWERTY, що використовується для відкриття консолі за замовчуванням) у головному меню надасть інформацію про використаний графічний інтерфейс, надаючи назви елементів, їх позиції та спрайти, що використовуються ними. Це еквівалентно використанню консольної команди "gui", але режим налагодження дозволяє робити це в головному меню.
Розширена інформація - З увімкненим режимом налагодження при наведенні курсора на провінцію з'явиться додаткова інформація, включаючи її ID та ID штату, в якому вона знаходиться, теги власника та контролера тощо. Ця налагоджувальна інформація також надається для цілих країн при наведенні курсора на їхній прапор у вікні політики/дипломатії країни, наприклад, тег, оригінальний тег (для динамічних країн) та косметичний тег.
Доступ до більшої кількості консольних команд - Певні консольні команди заблоковані лише для розробників, і режим налагодження дозволяє гравцеві їх використовувати. Однак зауважте, що не всі консольні команди стануть доступними.
Легкість доступу до файлів GUI - При наведенні курсора на елемент GUI, Ctrl+Alt+Правий клік можна використовувати для відкриття меню налагодження, яке дозволить перейти до файлу GUI, де визначено елемент.
Автоматичне збереження при мирних угодах - Гра автоматично створює файл збереження щоразу, коли відбувається мирна конференція з увімкненим налагодженням.

Якщо використовується консольна команда 'debug', доступними будуть лише останні 4 переваги. Якщо налагодження увімкнено через параметри запуску, чи то -debug, чи -crash_data_log (не вмикає автоматичне завантаження), усі переваги будуть надані. Однак багатокористувацька гра буде вимкнена, а продуктивність гри знизиться порівняно з вимкненим налагодженням.

4.5.1. Логи

Логи знаходяться в папці /Hearts of Iron IV/logs/ каталогу користувача та можуть використовуватися для усунення несправностей гри. Зокрема, ці особливо корисні при роботі з неочікуваною поведінкою:

text.log використовується для дублікатів визначень значень локалізації.
game.log — це інформація, яка реєструється посеред гри. Зокрема, "log" (або як ефект, або як тригер) виводить свої логи в цей файл.
error.log реєструє те, що розробники гри передбачили як потенційні помилки, які можуть виникнути під час Модингу гри. Таким чином, він зазвичай опускає помилки, що спричиняють аварійне завершення, деталізуючи натомість потенційну неочікувану поведінку. Однак він може бути корисним для усунення несправностей, що спричиняють аварійне завершення, оскільки ця неочікувана поведінка іноді може призвести до аварійного завершення (наприклад, помилка "invalid event target" може призвести до передачі неконтрольованого штату, спричиняючи аварійне завершення). Кожна помилка, позначена MAP_ERROR, вимагає режиму налагодження для появи, інакше гра не зможе відкритися.^[c] Деякі помилки MAP_ERROR з'являються лише після вибору країни та початку гри.
system.log деталізує системно згенеровану інформацію, зазвичай пов'язану з графікою. З параметром запуску -checksum він також генерує вивід для контрольної суми, який можна порівняти з контрольною сумою іншого користувача, щоб з'ясувати, де саме різниця.

4.6. Локалізація

Основна стаття: Локалізація

Назви, що залежать від мови, визначаються в локалізації. Беручи до уваги лише англійську мову, використовується папка /Hearts of Iron IV/localisation/english. Файл у ній повинен закінчуватися на _l_english.yml в назві файлу, щоб працювати належним чином, включаючи розширення, яке за замовчуванням приховане в Провіднику Windows. Файл повинен бути закодований у кодуванні UTF-8 з включеною позначкою порядку байтів, зазвичай це називається UTF-8-BOM. Точні деталі конвертації залежать від текстового редактора. Перший рядок у файлі — l_english:, щоб призначити його цій базі даних.

Запис локалізації структурований як localisation_key:0 "Value of the key". Тут перша частина перед двокрапкою називається ключем локалізації, кінцева частина в лапках — значенням ключа локалізації, а число посередині — номером версії. Номер версії є суто коментарем і не читається грою, і його можна повністю опустити. Будь-який файл локалізації можна використовувати для будь-якої локалізації, і краще використовувати нові файли, а не копіювати файли базової гри.

Хоча теоретично можливо уникнути використання локалізації у багатьох випадках, локалізація має переваги над прямим використанням рядків:

Підтримка налаштування тексту. Це обов'язково включає нові рядки та кольоровий текст, які ніколи не працюють всередині рядків. У деяких випадках динамічна локалізація, позначена квадратними дужками, наприклад, [TAG.GetName], працюватиме з локалізацією, але не в рядках.
Підтримка кількох мов. Навіть якщо мод призначений лише для англійської або іншої мови, краще залишити можливість для потенційних субмодів. Хоча все ще можливо створювати субмоди-переклади для модів, які не використовують локалізацію, стає набагато складніше підтримувати їх в актуальному стані (оскільки в цьому випадку потрібно змінювати не лише файли локалізації) і це змінює контрольну суму (унеможливлюючи багатокористувацьку сесію між тими, хто має субмод-переклад, і тими, хто його не має).
Рядки мають обмеження символів щонайбільше 255 видимих символів, що робить їх непрактичними для використання на великих шматках тексту, таких як описи.
Символи, що не належать до ASCII, такі як умлаути та інші діакритичні знаки, не підтримуються рядками в кількох файлах, таких як риси лідерів країн або правила суміжності. Підтримка символів, що не належать до ASCII, зазвичай позначається тим, що файл має позначку порядку байтів (зазвичай зазначається як окреме кодування UTF-8-BOM), що призводить до того, що гра не може завантажити файл, якщо він безпосередньо не підтримується.

4.7. GFX

Основна стаття: Модинг графічних ресурсів

Здебільшого зображення зберігаються у форматі DDS, зазвичай ARGB8 (або A8R8G8B8, залежно від редактора зображень) без міпмапів. Точний формат не має суворого значення, однак: більшість файлів зображень можна зберегти у форматах DDS, TGA, PNG або BMP; доки інформація у спрайті правильна. Основними винятками з цього є прапори, що представляють країни, які повинні бути 32-бітними файлами TGA без кодування RLE та з точкою початку координат у нижньому лівому куті, а також файли в папці карти.

Спрайт використовується для додавання додаткової інформації до файлу зображення (наприклад, назва спрайта, тип завантаження, кількість кадрів або анімація) і потрібен для відображення зображення в графічному користувацькому інтерфейсі. Спрайти визначаються у файлах /Hearts of Iron IV/interface/*.gfx, які відкриваються текстовим редактором. Зауважте, що папка не пов'язана з /Hearts of Iron IV/gfx/interface/.

Спрайти визначаються всередині блоку spriteTypes = { ... } і мають різні визначення, такі як простий spriteType, corneredTileSpriteType, який можна використовувати з довільним розміром, розтягуючись для відповідності з урахуванням кутів, frameAnimatedSpriteType, який дозволяє створювати послідовність анімації, а не обмежуватися скриптованими, які можна зробити в spriteTypes, тощо. Найпростіший можливий файл спрайта складається з наступного:

spriteTypes = {
    spriteType = {
        name = GFX_my_sprite_name
        texturefile = gfx/interface/folder/filename.dds # Повинен використовувати / для розділення папок
    }
    spriteType = {
        name = GFX_my_second_sprite
        texturefile = gfx/anotherfolder/filename.dds
    }
}

Це призначає файлу /Hearts of Iron IV/gfx/interface/folder/filename.dds спрайт GFX_my_sprite_name у грі. Цей спрайт потім можна використовувати в графічному користувацькому інтерфейсі, наприклад, як іконку рішення або фокуса (зауважте, що іконки фокусів також повинні мати окремий спрайт для анімації блиску). Єдині зображення, які не мають жодного визначення у файлах інтерфейсу, це:

Прапори, що використовуються для країн у /Hearts of Iron IV/gfx/flags/ та її підпапках.
Екрани завантаження в /Hearts of Iron IV/gfx/loadingscreens/. Зауважте, однак, що фон головного меню, який зазвичай зберігається в цій папці, визначається як спрайт.
Портрети персонажів. Вони можуть використовувати спрайт як визначення, але це єдине місце в грі, де це не є обов'язковою вимогою, приймаючи прямі посилання на файл як альтернативу.

Також існують потенційні помилки, пов'язані зі спрайтами:

Спрайт повністю прозорий: Це ознака того, що спрайт існує, але зображення всередині не може бути завантажене. Це трапляється, якщо texturefile визначено для файлу, який не існує (шлях до папки або назва файлу можуть не відповідати самому файлу), або якщо саме зображення пошкоджене. Це зазвичай супроводжується помилкою Texture Handler encountered missing texture file.
Спрайт замінено стандартним зображенням: Це ознака того, що щось не так із самим спрайтом, а не із зображенням: гра посилається на неіснуючий спрайт десь. Зазвичай це друкарська помилка в назві спрайта або недотримання формату назви (наприклад, пропуск _shine в кінці спрайта блиску іконки національного фокуса). Переконайтеся, що спрайт існує та має правильну назву.^[e]
Персонаж використовує випадково згенерований портрет: Це ознака однієї з двох попередніх проблем: персонаж з недійсним спрайтом або відсутнім файлом матиме випадковий портрет.

5. Структура мода

Розширення файлу .mod за замовчуванням не відображається в Провіднику Windows, що може ускладнити пошук згаданих тут файлів. Переконайтеся, що розширення файлів налаштовані на відображення.
Якщо не зазначено інше, цей розділ передбачає, що файли знаходяться в каталозі користувача.

З кожним модом пов'язані два файли-дескриптори з розширенням .mod:

Файл-дескриптор, специфічний для користувача, який призначає інформацію, що використовується для завантаження мода. Зокрема, шлях до папки, що зберігає мод, повинен бути визначений лише тут, оскільки він може відрізнятися залежно від користувача. Вони зберігаються в папці /Hearts of Iron IV/mod/ каталогу користувача, де назва файлу визначає порядок їх завантаження (якщо не перевизначено залежностями). Назва файлу не може містити пробілів. Наприклад, /Hearts of Iron IV/mod/ugc_1234567890.mod або /Hearts of Iron IV/mod/modname.mod є дескрипторами, специфічними для користувача.
Файл-дескриптор, специфічний для мода, який призначає інформацію, яку має мод і яка повинна бути спільною незалежно від користувача. Цей файл повинен називатися descriptor.mod і знаходиться в основній папці шляху, тобто в папці, вказаній у шляху у файлі вище. Наприклад, /Hearts of Iron IV/mod/my mod/descriptor.mod або ../steam/steamapps/workshop/content/394360/1234567890/descriptor.mod є дескрипторами, специфічними для мода.

Два дескриптори призначені для того, щоб мати переважно ідентичну інформацію, за винятком того, що лише файл, специфічний для користувача, повинен мати запис path у своєму визначенні, оскільки це не є спільним для різних користувачів і може значно відрізнятися. Лаунчер забезпечує це для аргументів, які можна визначити в лаунчері, однак інші аргументи, такі як replace_path, не будуть автоматично перенесені.

Лаунчер можна використовувати для створення пари дескрипторів: для цього використовується меню, доступне через "Усі встановлені моди" -> "Завантажити мод" -> "Створити мод". Це не дає свободи у виборі розташування папки, що використовується як папка мода, і не надає всіх можливих аргументів для включення в дескриптор мода, тому може знадобитися ручне редагування дескрипторів у результаті для додавання інших атрибутів мода або зміни розташування папки.

Крім того, ці файли в каталозі користувача також використовуються під час завантаження модів:

/Hearts of Iron IV/dlc_load.json надає список увімкнених модів (у вигляді списку скорочених шляхів до файлів .mod, як-от "mod/modname.mod") та вимкнених DLC під час відкриття гри. Хоча це автоматично змінюється лаунчером перед запуском гри, це дозволяє вмикати та вимикати різні моди без використання лаунчера. Якщо є кілька визначень enabled_mods, гра використовуватиме перше визначене визначення, дозволяючи набір плейлистів без використання лаунчера.
/Hearts of Iron IV/launcher-v2.sqlite або /Hearts of Iron IV/launcher-v2_openbeta.sqlite — це база даних SQLite, яка використовується для генерації інформації про моди та плейсети в лаунчері. Іноді лаунчер може не оновити існуючі моди (наприклад, помилка "invalid path" може залишатися вічно навіть після виправлення шляху, або новий дескриптор мода, специфічний для користувача, може не бути виявлений), і видалення цього файлу дозволяє перегенерувати плейсети. Після видалення файлу гра підхопить кожен дескриптор мода, специфічний для користувача, і відтворить список модів, використовуючи кожен з них. Моди, розміщені в Steam Workshop та Paradox mods, будуть автоматично додані до стандартного плейсету; локальні моди залишаться в списку "Усі встановлені моди", але за замовчуванням не будуть призначені жодному плейсету.

5.1. Зміст дескриптора

Більшість файлів .mod містять вміст, подібний до цього, який можна налаштувати в лаунчері:

name = "Average mod"
path = "mod/modname"
picture = "thumbnail.png"
version = "v1"
supported_version = "1.13.*"
tags={
    "Gameplay"
    "Historical"
}
remote_file_id="1678247250"

Ось такі аргументи:

name — назва мода, як вона відображається в лаунчері. Це також використовується в атрибуті dependencies модів. Назва повинна бути унікальною порівняно з іншими встановленими модами.
path — використовується для визначення розташування папки мода. Для локальних модів введення path = "mod/modname/" як скороченого розташування автоматично додасть розташування каталогу користувача після відкриття лаунчера. Будь-яка папка може використовуватися для зберігання мода, однак у шляху можна використовувати лише символи ASCII. Якщо шлях містить символи, що не належать до ASCII, такі як діакритичні знаки або нелатинські шрифти, мод не зможе бути завантажений. Роздільником папок є виключно пряма коса риска "/". Це повинно бути присутнім лише у файлі, специфічному для користувача.
picture — назва файлу зображення, призначеного моду. Воно відображатиметься в лаунчері для модів Steam та Paradox, а також як мініатюра в Steam Workshop та Paradox Mods. Зображення повинно міститися в кореневому каталозі мода (визначеному через path) і мати розмір менше 1 МБ. Це повинно бути визначено після назви мода. Локальні моди не матимуть зображення в лаунчері, навіть якщо це визначено.
version — рядок, що відображається біля назви мода в лаунчері як версія мода. Приймається будь-який рядок і не дає жодних змін.
supported_version — використовується для визначення, для якої версії гри призначений мод, інакше надає позначку 'застарілий' у лаунчері. Останнє число версії можна замінити зірочкою, що означатиме, що мод працюватиме на будь-якому незначному оновленні в межах цього основного оновлення.
tags — список тегів, які використовуються в Steam Workshop та Paradox Mods.
remote_file_id — використовується для приєднання елемента Steam Workshop або Paradox Mods до мода, щоб увімкнути його оновлення в лаунчері.

Ці аргументи неможливо встановити в лаунчері, їх можна додати лише безпосередньо:

user_dir = "NewSaveFolder"
dependencies = { "Major Mod" "Major Mod 2" }
replace_path = "history/states" 
replace_path = "map/strategicregions"

user_dir змінює папку, де гра зберігає збереження. Це запобігає завантаженню збереження, зробленого в базовій грі та модах з іншим записом user_dir, і, навпаки, запобігає завантаженню збережень, зроблених у цьому моді, в базовій грі або модах з іншим записом user_dir.
dependencies змінює порядок завантаження модів, зокрема, змушуючи цей мод завантажуватися після кожного мода, переліченого в цьому атрибуті. Це не робить цей мод залежним від перелічених модів для роботи. Зміна порядку завантаження забезпечить, що будь-який replace_path у моді-залежності залишить файли цього мода недоторканими, і що файли цього мода перезапишуть файли мода-залежності у випадку збігу імен файлів. Необхідно для правильної роботи субмодів.

5.1.1. replace_path

replace_path використовується для вивантаження кожного раніше завантаженого файлу під час завантаження головного меню у вказаній папці. Це стосується лише файлів безпосередньо в цій папці, будь-які підпапки залишаться недоторканими.

Це не змушує мод замінювати вміст папки: все, що вище в порядку завантаження, ніж мод, буде завантажено точно так само, все, що нижче мода, спочатку завантажиться, а потім вивантажиться (наприклад, помилка, коли файл завантажується двічі, якщо є файл з назвою, що відрізняється лише регістром, все ще буде присутня, навіть якщо один з файлів призначений для заміни за допомогою replace_path), все, що завантажується після головного меню, все одно завантажуватиметься із "замінених" папок. Це не змінює порядок завантаження: якщо файл не може перезаписати файл іншого мода, він все одно не зробить цього з використанням цього атрибута; натомість, dependencies використовується в атрибутах мода для зміни порядку завантаження. У випадку, якщо мод не може перезаписати файли базової гри, це ніколи не вирішить проблему: переконайтеся, що папка, в яку ви пишете, дійсно є папкою мода, а не, наприклад, каталогом користувача або резервною копією мода; у випадку прапорів гра іноді може не перезаписати папку /Hearts of Iron IV/gfx/flags/ базової гри модом, що можна вирішити, створивши інший мод і перемістивши файли туди.

Наприклад, replace_path = "history/states" забезпечить, що жодні файли штатів з базової гри або каталогу користувача не будуть завантажені під час запуску гри з модом. Це можна використовувати в капітальних ремонтах карти, щоб забезпечити, що жоден вміст базової гри не буде прочитаний з неочікуваними результатами. Оскільки каталог користувача знаходиться раніше в порядку завантаження, ніж файли мода, це також, здавалося б, запобігатиме будь-якому впливу Nudger на штати, однак файли все одно виводитимуться в папку, навіть якщо їх негайно вивантажать після збереження.

Оскільки це вивантажує лише індексовані файли, пряме посилання на файл не зміниться незалежно від наявності replace_path. Наприклад, replace_path = "history/units" нічого не змінить, оскільки файли в цій папці не перевіряються під час завантаження головного меню, а завантажуються за прямим посиланням на назву файлу, наприклад, oob = "TAG_1936" у файлі історії країни. Аналогічно, replace_path = "gfx/flags" нічого не змінить, оскільки прапори, що ідентифікують країну, завантажуються лише тоді, коли країна змінює правлячу групу ідеологій.

Це особливо очевидно з екранами завантаження: replace_path = "gfx/loadingscreens" запобігатиме появі будь-якого екрана завантаження базової гри або DLC під час завантаження, однак фон головного меню залишиться таким самим, ніби replace_path не було. Це тому, що фон головного меню визначається як спрайт з прямим посиланням на зображення, за замовчуванням у /Hearts of Iron IV/interface/frontendmainviewbg.gfx.

Цю опцію потрібно додати до обох файлів .mod: якщо її пропустити в дескрипторі, специфічному для мода, лаунчер видалить її з дескриптора, специфічного для користувача, тоді як якщо її пропустити в дескрипторі, специфічному для користувача, вона не матиме ефекту, замість того, щоб копіюватися з дескриптора, специфічного для мода, як більшість інших атрибутів.

Це часто спричиняє аварійне завершення гри та неінтуїтивні помилки, якщо використовується необережно. У деяких папках гра не розрахована на відсутність записів бази даних, таких як національні фокуси, що призводить до аварійного завершення; в інших, таких як скриптовані тригери, є кілька способів використання записів, крім очевидних, що може спричинити неінтуїтивні помилки, наприклад, система опору спрацьовує ненавмисно. Тому атрибут replace_path не слід використовувати необережно: у файлах мода завжди повинен бути щонайменше один файл із вмістом у заміненій папці, а вміст базової гри в папці слід перевіряти вручну, щоб побачити, чи щось корисне краще залишити в моді.

6. Ігрові дані

Консольні команди, корисні для налагодження модів.
Області видимості (Scopes), Тригери та Ефекти, що використовуються для скриптингу.
Модифікатори, що використовуються для впливу на розрахунки, які виконує гра.
Локалізація, що використовується для тексту, який відображається гравцеві залежно від поточної увімкненої мови.
Модинг графічних ресурсів для створення спрайтів, що використовуються майже для кожного 2-вимірного зображення, яке може з'явитися в грі.
Defines, які дозволяють змінювати константи, що використовуються в деяких жорстко закодованих розрахунках, таких як дата початку або необхідна кількість переможних очок для відображення певного значка над провінцією.
Статичні модифікатори також включають модифікатори, що застосовуються у жорстко закодованих випадках, таких як штраф за некорінний штат або вартість політичної влади при виборі національного фокуса.

7. Інструменти та утиліти

Офіційний форум Paradox для модів
Maya exporter - Clausewitz Maya Exporter для створення власних 3D-моделей.
Steam Workshop - Місце, де ви можете ділитися своїми творіннями з іншими гравцями.

8. Поширені помилки

Кілька модів з однаковою назвою в лаунчері (Мод не завантажується) – Це часто трапляється при підписці на власний мод у Steam Workshop. Якщо є два моди з однаковою назвою, які можна вибрати в лаунчері, лише той, що завантажується раніше, матиме виявлені файли; інший мод відображатиметься як такий, що нічого не змінює в грі. Це виправляється зміною атрибута name у дескрипторах одного з модів.
- Загалом, немає причин підписуватися на власний мод у Steam Workshop: він майже ніколи не функціонуватиме інакше, ніж локальний мод, і це також іноді може порушити оновлення мода через дублікати атрибутів remote_file_id у різних модах.
Неправильний шлях (replace_paths застосовуються, але мод не завантажується) – У цьому випадку потрібно налаштувати файл /Hearts of Iron IV/mod/modname.mod каталогу користувача, відкривши його безпосередньо в текстовому редакторі. Існує два основних варіанти цієї проблеми:
- Неправильний шлях – Це часто є причиною, якщо гра відображає розмір файлу мода, але не завантажує його. Мод не спрямовує безпосередньо до файлу. Іноді це може бути причиною подальшого вкладення папок, наприклад, якщо мод знаходиться в mod/my_mod/cool_mod, але файл .mod, специфічний для користувача, містить path = "mod/my_mod". У цьому випадку файли все ще існують і завантажуються. Однак гра, наприклад, очікує дерева фокусів у папці /Hearts of Iron IV/common/national_focus/. mod/my_mod/cool_mod/common/national_focus/ сприймається як /Hearts of Iron IV/cool_mod/common/national_focus/, оскільки path = "mod/my_mod" не "відкидає" папку /cool_mod/. Це виправляється простою зміною шляху на правильну папку.
- Недійсний шлях – Призначена папка правильна, але вказана таким чином, що гра не може її розпізнати.
  - Один із способів зробити це — використання зворотних косих рисок для розділення папок, наприклад, path = "mod\my_mod". Це неправильно, оскільки одна зворотна коса риска сприймається як керуючий символ. Правильним є використання прямих косих рисок, як у path = "mod/my_mod".
  - Інший спосіб — використання спеціальних символів у назві, наприклад, path = "C:/Users/Приклад кирилиці/Documents/Paradox Interactive/Hearts of Iron IV/mod/my_mod". У цьому випадку спеціальний символ визначається як той, що займає більше 1 байта для запису в UTF-8 і не присутній у друкованих символах ASCII. Це часто назви папок не англійською мовою, такі як діакритичні знаки або нелатинські алфавіти. У цьому випадку його можна перенаправити до папки, яка не містить спеціальних символів у назві, наприклад, path = "D:/Hearts of Iron IV modding/my_mod".
Якщо шлях до самого каталогу користувача містить спеціальні символи, краще перенаправити весь каталог до іншої папки. Для цього відредагуйте файл /Hearts of Iron IV/launcher-settings.json базової гри та змініть папку, вказану в gameDataPath. Після цього перемістіть вміст каталогу користувача до цієї папки, щоб не втратити збережені ігри та іншу інформацію. Шлях мода також потрібно належним чином скоригувати.
Якщо каталог користувача має символи, що не належать до ASCII, у шляху до нього, то всі локальні моди, що зберігаються там (як стандартне місце для їх зберігання), не завантажуватимуться, а вбудовані засоби не зможуть відкрити лог помилок, з'явиться спливаюче вікно з повідомленням, що система не може отримати доступ до файлу. Стандартна папка встановлення Steam має шлях, який міститиме лише символи ASCII, що робить моди Steam працездатними, навіть якщо каталог користувача має в ньому символи, що не належать до ASCII.
Якщо лаунчер показує, що мод має недійсний шлях навіть після виправлення проблеми, переконайтеся, що файл дескриптора мода, специфічний для користувача, безпосередньо в каталозі /Hearts of Iron IV/mod/ користувача існує, і спробуйте примусово оновити інформацію про мод, видаливши базу даних SQLite, що зберігає інформацію про мод, розташовану або в /Hearts of Iron IV/launcher-v2.sqlite, або в /Hearts of Iron IV/launcher-v2_openbeta.sqlite.
Неправильна назва залежності (Мод не завантажується при увімкненні з основним модом) – Якщо мод призначений бути субмодом до більшого мода або кількох, у більшості випадків обов'язково включати dependencies = { "Main mod 1" "Main mod 2" }, що розмістить його вище в порядку завантаження. У цьому випадку назва мода повинна бути точно такою ж, як у файлі .mod мода, також відображаючись у лаунчері. Це може включати спеціальні символи (наприклад, name = "Main mod – Subtitle" в основному моді вимагатиме dependencies = { "Main mod — Subtitle" } у субмоді з тире em dash, а не дефісом). З цієї причини краще копіювати назву з файлу .mod основного мода, а не вручну переписувати її з лаунчера: деякі спеціальні символи можуть бути важко помітити або відрізнити від інших символів.
Не копіювання записів інформації про мод (Записи, такі як replace_path, не застосовуються) – Гра зберігає файл modname/descriptor.mod мода як інформацію для мода загалом, а /Hearts of Iron IV/mod/modname.mod — як інформацію для мода, що читається для машини. Хоча лаунчер зазвичай намагається підтримувати файл, специфічний для машини, в актуальному стані з загальним файлом інформації про мод, іноді це не вдається, наприклад, для replace_paths, де він успішно видаляє непотрібні записи, але не копіює потрібні. У цьому випадку обидва файли потрібно редагувати вручну, щоб replace_path застосувався. Це також може знадобитися для інших записів у файлі.
Файли зі схожими назвами (Файл завантажується двічі) – У цьому випадку "схожі" визначається як пара файлів у одній папці, назви яких складаються з різних символів, але вважалися б такими, що мають однакову назву при перевірці без урахування регістру, наприклад, /Hearts of Iron IV/events/Generic.txt та /Hearts of Iron IV/events/GENERIC.txt. Якщо файли мода містять файл, назва якого схожа на назву файлу базової гри, файл мода завантажиться двічі. Зміна назви файлу на точну таку ж, як у файлі базової гри, або на повністю відмінну, виправить цю проблему. Це застосовується навіть якщо папка, в якій знаходиться файл базової гри, вивантажена за допомогою replace_path.
Зайва закриваюча дужка (Файл передчасно припиняє виконання) – Якщо під час інтерпретації файлу гра зустрічає закриваючу дужку, яка не відповідає жодній іншій відкриваючій дужці, файл передчасно припинить інтерпретацію в точці закриваючої дужки. Це призведе до того, що нічого після цієї закриваючої дужки не буде виконано. Це найчастіше є проблемою у файлах, які не змушують використовувати блок кореневого рівня, таких як /Hearts of Iron IV/history/countries, оскільки одна зайва закриваюча дужка там зазвичай достатня для миттєвого завершення інтерпретації, замість створення записів про несподівані токени в error.log до кінця файлу.
```
capital = 123
set_convoys = 321
recruit_character = TAG_countryleader

set_technology = {
    infantry_weapons = 1
}
} // Зайва закриваюча дужка

set_politics = { // Буде проігноровано
    ideology = neutrality
    elections_allowed = no
}
```

9. Корисні знання

Великі англомовні спільноти моддерів включають HOI4 Modding Coop та HOI4 Modding Den, до яких можна приєднатися в Discord. Корисно приєднатися до однієї або кількох з них, оскільки вони містять посилання на ресурси для Модингу, і ви можете ставити питання щодо Модингу в них.

Файл settings.txt, розташований у каталозі користувача, що також містить папку мода, можна змінити, щоб змінити програму, яку гра використовує для відкриття файлів, з Microsoft Notepad, якщо шлях до редактора правильний. Ось приклади з двома часто використовуваними текстовими редакторами:

Notepad++:

editor="C:\\Program Files\\Notepad++\\notepad++.exe"
editor_postfix=" -n$"

Sublime Text:

editor="C:\\Program Files\\Sublime Text 3\\sublime_text.exe"
editor_postfix=":$:1"

10. Див. також

11. Примітки

^[a] Встановлення порожнього файлу для перезапису файлу загалом ідентичне його вивантаженню на практиці, оскільки гра зазвичай не використовує ні поділ на кілька файлів, ні назву файлів для їх інтерпретації. Це стосується лише текстових файлів, а не зображень, таких як екрани завантаження.

^[b] Ці винятки, які можна розумно змінити в моді, такі:

/Hearts of Iron IV/gfx/flags/ та її підпапки, де назва повинна відповідати суворому форматуванню, щоб автоматично завантажуватися для країни.
/Hearts of Iron IV/history/countries/, де перші 3 літери призначають її країні.
Файли .txt безпосередньо всередині /Hearts of Iron IV/common/ (найважливіші achievements.txt, combat_tactics.txt та graphicalculturetype.txt)
/Hearts of Iron IV/common/countries/colors.txt та /Hearts of Iron IV/common/countries/cosmetic.txt повинні залишатися з тією ж назвою. Решта безпосередньо пов'язані у файлах /Hearts of Iron IV/common/country_tags/*.txt.
Різноманітні елементи всередині gfx, такі як /Hearts of Iron IV/gfx/maparrows/maparrow.txt або /Hearts of Iron IV/gfx/HOI4_icon.bmp. Це не включає /Hearts of Iron IV/gfx/loadingscreens (кожен файл у ньому завантажується незалежно від назви файлу) або більшість файлів шрифтів/зображень (оскільки вони завантажуються за посиланням в іншому файлі).
Файли всередині папок /Hearts of Iron IV/map/ та /Hearts of Iron IV/map/terrain/, за винятком /Hearts of Iron IV/map/strategicregions та тих, що визначені в /Hearts of Iron IV/default.map.
/Hearts of Iron IV/tutorial/tutorial.txt

^[c] Єдиним винятком, який розглядається як звичайна помилка, є MAP_ERROR: Palette in rivers.bmp is probably not correct, спричинена тим, що палітра у файлі має ненульову кількість кольорів, зазвичай продукт збереження поверх неї в GIMP. На відміну від інших записів у error.log, позначених MAP_ERROR, це дозволяє відкривати гру без режиму налагодження та не виводить попередження при спробі перейти в одиночну гру.

^[d] У динамічних модифікаторах, і лише в них, порядок модифікаторів у підказці не є жорстко закодованим. Натомість гра розміщує їх у тому ж порядку, в якому вони були написані в коді динамічного модифікатора. Однак порядок модифікаторів всередині динамічних модифікаторів не може призвести до жодної різниці в їх інтерпретації.

^[e] У рідкісних випадках немає зображення, встановленого як заповнювач, що призводить до того, що використання неіснуючого спрайта також не призводить до появи нічого. Прикладом цього є баланси сил, де вказівка неіснуючого спрайта для представлення сторони призведе до того, що сторона не матиме іконки. Це особливо рідко, оскільки існує стандартне резервне зображення GFX_default, що показує собаку помилок у базовій грі.