Глава 4.6: Упаковка PBO

Главная | << Предыдущая: Рабочий процесс DayZ Tools | Упаковка PBO | Следующая: Руководство по Workbench >>

Введение

PBO (Packed Bank of Objects) --- это архивный формат DayZ -- эквивалент .zip файла для игрового контента. Каждый мод, который загружает игра, поставляется в виде одного или нескольких PBO-файлов. Когда игрок подписывается на мод в Steam Workshop, он скачивает PBO. Когда сервер загружает моды, он читает PBO. PBO --- это конечный продукт всего конвейера моддинга.

Понимание того, как правильно создавать PBO --- когда бинаризировать, как устанавливать префиксы, как структурировать вывод и как автоматизировать процесс --- это последний шаг между вашими исходными файлами и работающим модом. Эта глава охватывает всё: от базовой концепции до продвинутых автоматизированных рабочих процессов сборки.

Содержание

Что такое PBO?
Внутренняя структура PBO
AddonBuilder: инструмент упаковки
Флаг -packonly
Флаг -prefix
Бинаризация: когда нужна, а когда нет
Подписание ключами
Структура папки @mod
Автоматизированные скрипты сборки
Сборка модов с несколькими PBO
Распространённые ошибки сборки и решения
Тестирование: патчинг файлов vs загрузка PBO
Лучшие практики

Что такое PBO?

PBO --- это плоский архивный файл, содержащий дерево директорий с игровыми ассетами. Он не использует сжатие (в отличие от ZIP) -- файлы внутри хранятся в оригинальном размере. «Упаковка» чисто организационная: множество файлов становятся одним файлом с внутренней структурой путей.

Ключевые характеристики

Без сжатия: Файлы хранятся как есть. Размер PBO равен сумме его содержимого плюс небольшой заголовок.
Плоский заголовок: Список записей файлов с путями, размерами и смещениями.
Метаданные префикса: Каждый PBO объявляет внутренний префикс пути, который отображает его содержимое в виртуальную файловую систему движка.
Только для чтения во время выполнения: Движок читает из PBO, но никогда не записывает в них.
Подписание для мультиплеера: PBO могут быть подписаны парой ключей в стиле Bohemia для проверки подписей сервером.

Почему PBO, а не отдельные файлы

Распространение: Один файл на компонент мода проще, чем тысячи отдельных файлов.
Целостность: Подписание ключами гарантирует, что мод не был изменён.
Производительность: Файловый ввод-вывод движка оптимизирован для чтения из PBO.
Организация: Система префиксов исключает конфликты путей между модами.

Внутренняя структура PBO

Когда вы открываете PBO (используя инструмент вроде PBO Manager или MikeroTools), вы видите дерево директорий:

MyMod.pbo
  $PBOPREFIX$                    <-- Текстовый файл, содержащий путь префикса
  config.bin                      <-- Бинаризированный config.cpp (или config.cpp при -packonly)
  Scripts/
    3_Game/
      MyConstants.c
    4_World/
      MyManager.c
    5_Mission/
      MyUI.c
  data/
    models/
      my_item.p3d                 <-- Бинаризированный ODOL (или MLOD при -packonly)
    textures/
      my_item_co.paa
      my_item_nohq.paa
      my_item_smdi.paa
    materials/
      my_item.rvmat
  sound/
    gunshot_01.ogg
  GUI/
    layouts/
      my_panel.layout

$PBOPREFIX$

Файл $PBOPREFIX$ --- это маленький текстовый файл в корне PBO, который объявляет префикс пути мода. Например:

MyMod

Это сообщает движку: «Когда что-то ссылается на MyMod\data\textures\my_item_co.paa, ищи внутри этого PBO по пути data\textures\my_item_co.paa.»

config.bin vs. config.cpp

config.bin: Бинаризированная (двоичная) версия config.cpp, создаваемая Binarize. Быстрее парсится при загрузке.
config.cpp: Оригинальная текстовая конфигурация. Работает в движке, но парсится немного медленнее.

При сборке с бинаризацией config.cpp становится config.bin. При использовании -packonly config.cpp включается как есть.

AddonBuilder: инструмент упаковки

AddonBuilder --- это официальный инструмент упаковки PBO от Bohemia, входящий в состав DayZ Tools. Он может работать в режиме GUI или из командной строки.

Режим GUI

Запустите AddonBuilder из DayZ Tools Launcher.
Source directory: Укажите папку вашего мода на P: (например, P:\MyMod).
Output directory: Укажите выходную папку (например, P:\output).
Options:
- Binarize: Отметьте для запуска Binarize по контенту (конвертирует P3D, текстуры, конфиги).
- Sign: Отметьте и выберите ключ для подписания PBO.
- Prefix: Введите префикс мода (например, MyMod).
Нажмите Pack.

Режим командной строки

Режим командной строки предпочтителен для автоматизированных сборок:

bash

AddonBuilder.exe [source_path] [output_path] [options]

Полный пример:

bash

"P:\DayZ Tools\Bin\AddonBuilder\AddonBuilder.exe" ^
    "P:\MyMod" ^
    "P:\output" ^
    -prefix="MyMod" ^
    -sign="P:\keys\MyKey"

Параметры командной строки

Флаг	Описание
`-prefix=<path>`	Установить внутренний префикс PBO (критически важен для разрешения путей)
`-packonly`	Пропустить бинаризацию, упаковать файлы как есть
`-sign=<key_path>`	Подписать PBO указанным BI-ключом (путь к приватному ключу, без расширения)
`-include=<path>`	Список включения файлов -- упаковать только файлы, соответствующие фильтру
`-exclude=<path>`	Список исключения файлов -- пропустить файлы, соответствующие фильтру
`-binarize=<path>`	Путь к Binarize.exe (если не в стандартном расположении)
`-temp=<path>`	Временная директория для вывода Binarize
`-clear`	Очистить выходную директорию перед упаковкой
`-project=<path>`	Путь к диску проекта (обычно `P:\`)

Флаг -packonly

Флаг -packonly --- один из важнейших параметров AddonBuilder. Он указывает инструменту пропустить всю бинаризацию и упаковать исходные файлы точно как есть.

Когда использовать -packonly

Содержимое мода	Использовать -packonly?	Причина
Только скрипты (.c файлы)	Да	Скрипты никогда не бинаризируются
UI-макеты (.layout)	Да	Макеты никогда не бинаризируются
Только аудио (.ogg)	Да	OGG уже в готовом для игры формате
Предварительно конвертированные текстуры (.paa)	Да	Уже в финальном формате
Config.cpp (без CfgVehicles)	Да	Простые конфиги работают без бинаризации
Config.cpp (с CfgVehicles)	Нет	Определения предметов требуют бинаризированного конфига
P3D-модели (MLOD)	Нет	Должны быть бинаризированы в ODOL для производительности
TGA/PNG текстуры (требуют конвертации)	Нет	Должны быть конвертированы в PAA

Практическое руководство

Для мода только со скриптами (фреймворк или утилитарный мод без пользовательских предметов):

bash

AddonBuilder.exe "P:\MyScriptMod" "P:\output" -prefix="MyScriptMod" -packonly

Для мода с предметами (оружие, одежда, транспорт с моделями и текстурами):

bash

AddonBuilder.exe "P:\MyItemMod" "P:\output" -prefix="MyItemMod" -sign="P:\keys\MyKey"

Совет: Многие моды разделяются на несколько PBO именно для оптимизации процесса сборки. Скриптовые PBO используют -packonly (быстро), тогда как PBO с данными (модели и текстуры) проходят полную бинаризацию (медленнее, но необходимо).

Флаг -prefix

Флаг -prefix устанавливает внутренний префикс пути PBO, который записывается в файл $PBOPREFIX$ внутри PBO. Этот префикс критически важен -- он определяет, как движок разрешает пути к содержимому внутри PBO.

Как работает префикс

Исходник: P:\MyMod\data\textures\item_co.paa
Префикс: MyMod
Внутренний путь PBO: data\textures\item_co.paa

Разрешение движком: MyMod\data\textures\item_co.paa
  --> Ищет в MyMod.pbo: data\textures\item_co.paa
  --> Найдено!

Многоуровневые префиксы

Для модов с подпапочной структурой префикс может включать несколько уровней:

bash

# Исходник на диске P:
P:\MyMod\MyMod\Scripts\3_Game\MyClass.c

# Если префикс "MyMod\MyMod\Scripts"
# Внутри PBO: 3_Game\MyClass.c
# Путь движка: MyMod\MyMod\Scripts\3_Game\MyClass.c

Префикс должен совпадать со ссылками

Если ваш config.cpp ссылается на MyMod\data\texture_co.paa, то PBO, содержащий эту текстуру, должен иметь префикс MyMod, а файл должен находиться по пути data\texture_co.paa внутри PBO. Несовпадение приводит к тому, что движок не может найти файл.

Распространённые паттерны префиксов

Структура мода	Исходный путь	Префикс	Ссылка в конфиге
Простой мод	`P:\MyMod\`	`MyMod`	`MyMod\data\item.p3d`
Мод с пространством имён	`P:\MyMod_Weapons\`	`MyMod_Weapons`	`MyMod_Weapons\data\rifle.p3d`
Скриптовый подпакет	`P:\MyFramework\MyMod\Scripts\`	`MyFramework\MyMod\Scripts`	(ссылка через config.cpp `CfgMods`)

Бинаризация: когда нужна, а когда нет

Бинаризация --- это преобразование человекочитаемых исходных форматов в оптимизированные для движка бинарные форматы. Это самый времязатратный шаг в процессе сборки и самый частый источник ошибок.

Что бинаризируется

Тип файла	Бинаризируется в	Обязательно?
`config.cpp`	`config.bin`	Обязательно для модов, определяющих предметы (CfgVehicles, CfgWeapons)
`.p3d` (MLOD)	`.p3d` (ODOL)	Рекомендуется -- ODOL загружается быстрее и меньше по размеру
`.tga` / `.png`	`.paa`	Обязательно -- движку нужен PAA во время выполнения
`.edds`	`.paa`	Обязательно -- то же, что выше
`.rvmat`	`.rvmat` (обработанный)	Разрешение путей, минимальная оптимизация
`.wrp`	`.wrp` (оптимизированный)	Обязательно для модов ландшафта/карт

Что НЕ бинаризируется

Тип файла	Причина
`.c` скрипты	Скрипты загружаются движком как текст
`.ogg` аудио	Уже в готовом для игры формате
`.layout` файлы	Уже в готовом для игры формате
`.paa` текстуры	Уже в финальном формате (предварительно конвертированы)
`.json` данные	Читаются как текст скриптовым кодом

Детали бинаризации config.cpp

Бинаризация config.cpp --- это этап, на котором у большинства моддеров возникают проблемы. Бинаризатор парсит текст config.cpp, проверяет его структуру, разрешает цепочки наследования и выводит бинарный config.bin.

Когда бинаризация обязательна для config.cpp:

Конфиг определяет записи CfgVehicles (предметы, оружие, транспорт, здания).
Конфиг определяет записи CfgWeapons.
Конфиг определяет записи, ссылающиеся на модели или текстуры.

Когда бинаризация НЕ обязательна:

Конфиг определяет только CfgPatches и CfgMods (регистрация мода).
Конфиг определяет только звуковые конфигурации.
Моды только со скриптами с минимальным конфигом.

Правило большого пальца: Если ваш config.cpp добавляет физические предметы в игровой мир, вам нужна бинаризация. Если он только регистрирует скрипты и определяет данные, не связанные с предметами, -packonly работает нормально.

Подписание ключами

PBO могут быть подписаны криптографической парой ключей. Серверы используют проверку подписей, чтобы убедиться, что у всех подключённых клиентов одинаковые (неизменённые) файлы мода.

Компоненты пары ключей

Файл	Расширение	Назначение	Кто имеет
Приватный ключ	`.biprivatekey`	Подписывает PBO при сборке	Только автор мода (ХРАНИТЕ В СЕКРЕТЕ)
Публичный ключ	`.bikey`	Проверяет подписи	Администраторы серверов, распространяется с модом

Генерация ключей

Используйте утилиты DSSignFile или DSCreateKey из DayZ Tools:

bash

# Генерация пары ключей
DSCreateKey.exe MyModKey

# Создаёт:
#   MyModKey.biprivatekey   (храните в секрете, не распространяйте)
#   MyModKey.bikey          (распространяйте администраторам серверов)

Подписание при сборке

bash

AddonBuilder.exe "P:\MyMod" "P:\output" ^
    -prefix="MyMod" ^
    -sign="P:\keys\MyModKey"

Результат:

P:\output\
  MyMod.pbo
  MyMod.pbo.MyModKey.bisign    <-- Файл подписи

Установка ключей на сервере

Администраторы серверов размещают публичный ключ (.bikey) в директории keys/ сервера:

DayZServer/
  keys/
    MyModKey.bikey             <-- Позволяет клиентам с этим модом подключаться

Структура папки @mod

DayZ ожидает, что моды организованы в определённой структуре директорий с использованием соглашения о префиксе @:

@MyMod/
  addons/
    MyMod.pbo                  <-- Упакованный контент мода
    MyMod.pbo.MyKey.bisign     <-- Подпись PBO (опционально)
  keys/
    MyKey.bikey                <-- Публичный ключ для серверов (опционально)
  mod.cpp                      <-- Метаданные мода

mod.cpp

Файл mod.cpp предоставляет метаданные, отображаемые в лаунчере DayZ:

cpp

name = "My Awesome Mod";
author = "ModAuthor";
version = "1.0.0";
url = "https://steamcommunity.com/sharedfiles/filedetails/?id=XXXXXXXXX";

Моды с несколькими PBO

Крупные моды часто разделяются на несколько PBO внутри одной папки @mod:

@MyFramework/
  addons/
    MyMod_Core_Scripts.pbo        <-- Слой скриптов
    MyMod_Core_Data.pbo           <-- Текстуры, модели, материалы
    MyMod_Core_GUI.pbo            <-- Файлы макетов, наборы изображений
  keys/
    MyMod.bikey
  mod.cpp

Загрузка модов

Моды загружаются через параметр -mod:

bash

# Один мод
DayZDiag_x64.exe -mod="@MyMod"

# Несколько модов (через точку с запятой)
DayZDiag_x64.exe -mod="@MyFramework;@MyMod_Weapons;@MyMod_Missions"

Папка @ должна находиться в корневой директории игры, или необходимо указать абсолютный путь.

Автоматизированные скрипты сборки

Ручная упаковка PBO через GUI AddonBuilder допустима для маленьких, простых модов. Для крупных проектов с несколькими PBO автоматизированные скрипты сборки необходимы.

Паттерн Batch-скрипта

Типичный build_pbos.bat:

batch

@echo off
setlocal

set TOOLS="P:\DayZ Tools\Bin\AddonBuilder\AddonBuilder.exe"
set OUTPUT="P:\@MyMod\addons"
set KEY="P:\keys\MyKey"

echo === Building Scripts PBO ===
%TOOLS% "P:\MyMod\Scripts" %OUTPUT% -prefix="MyMod\Scripts" -packonly -clear

echo === Building Data PBO ===
%TOOLS% "P:\MyMod\Data" %OUTPUT% -prefix="MyMod\Data" -sign=%KEY% -clear

echo === Build Complete ===
pause

Паттерн Python-скрипта сборки (dev.py)

Для более сложных сборок Python-скрипт обеспечивает лучшую обработку ошибок, логирование и условную логику:

python

import subprocess
import os
import sys

ADDON_BUILDER = r"P:\DayZ Tools\Bin\AddonBuilder\AddonBuilder.exe"
OUTPUT_DIR = r"P:\@MyMod\addons"
KEY_PATH = r"P:\keys\MyKey"

PBOS = [
    {
        "name": "Scripts",
        "source": r"P:\MyMod\Scripts",
        "prefix": r"MyMod\Scripts",
        "packonly": True,
    },
    {
        "name": "Data",
        "source": r"P:\MyMod\Data",
        "prefix": r"MyMod\Data",
        "packonly": False,
    },
]

def build_pbo(pbo_config):
    """Build a single PBO."""
    cmd = [
        ADDON_BUILDER,
        pbo_config["source"],
        OUTPUT_DIR,
        f"-prefix={pbo_config['prefix']}",
    ]

    if pbo_config.get("packonly"):
        cmd.append("-packonly")
    else:
        cmd.append(f"-sign={KEY_PATH}")

    print(f"Building {pbo_config['name']}...")
    result = subprocess.run(cmd, capture_output=True, text=True)

    if result.returncode != 0:
        print(f"ERROR building {pbo_config['name']}:")
        print(result.stderr)
        return False

    print(f"  {pbo_config['name']} built successfully.")
    return True

def main():
    os.makedirs(OUTPUT_DIR, exist_ok=True)

    success = True
    for pbo in PBOS:
        if not build_pbo(pbo):
            success = False

    if success:
        print("\nAll PBOs built successfully.")
    else:
        print("\nBuild completed with errors.")
        sys.exit(1)

if __name__ == "__main__":
    main()

Интеграция с dev.py

Проект MyMod использует dev.py как центральный оркестратор сборки:

bash

python dev.py build          # Собрать все PBO
python dev.py server         # Собрать + запустить сервер + мониторинг логов
python dev.py full           # Собрать + сервер + клиент

Этот паттерн рекомендуется для любого мульти-мод рабочего пространства. Одна команда собирает всё, запускает сервер и начинает мониторинг -- устраняя ручные шаги и уменьшая человеческие ошибки.

Сборка модов с несколькими PBO

Крупные моды выигрывают от разделения на несколько PBO. У этого есть несколько преимуществ:

Зачем разделять на несколько PBO

Быстрая пересборка. Если вы изменили только скрипт, пересоберите только скриптовый PBO (с -packonly, что занимает секунды). PBO с данными (с бинаризацией) занимает минуты и не требует пересборки.
Модульная загрузка. Серверные PBO могут быть исключены из загрузок клиента.
Более чистая организация. Скрипты, данные и GUI чётко разделены.
Параллельная сборка. Независимые PBO могут собираться одновременно.

Типичный паттерн разделения

@MyMod/
  addons/
    MyMod_Core.pbo           <-- config.cpp, CfgPatches (бинаризированный)
    MyMod_Scripts.pbo         <-- Все .c скриптовые файлы (-packonly)
    MyMod_Data.pbo            <-- Модели, текстуры, материалы (бинаризированный)
    MyMod_GUI.pbo             <-- Макеты, наборы изображений (-packonly)
    MyMod_Sounds.pbo          <-- OGG аудиофайлы (-packonly)

Зависимости между PBO

Когда один PBO зависит от другого (например, скрипты ссылаются на предметы, определённые в конфигурационном PBO), requiredAddons[] в CfgPatches обеспечивает правильный порядок загрузки:

cpp

// В config.cpp MyMod_Scripts
class CfgPatches
{
    class MyMod_Scripts
    {
        requiredAddons[] = {"MyMod_Core"};   // Загружать после core PBO
    };
};

Распространённые ошибки сборки и решения

Ошибка: «Include file not found»

Причина: Config.cpp ссылается на файл (модель, текстуру), который не существует по ожидаемому пути. Решение: Убедитесь, что файл существует на P: по точному указанному пути. Проверьте правописание и регистр.

Ошибка: «Binarize failed» без подробностей

Причина: Binarize аварийно завершился на повреждённом или невалидном исходном файле. Решение:

Проверьте, какой файл обрабатывал Binarize (посмотрите в логе вывода).
Откройте проблемный файл в соответствующем инструменте (Object Builder для P3D, TexView2 для текстур).
Проверьте валидность файла.
Частые виновники: текстуры не степени 2, повреждённые P3D-файлы, невалидный синтаксис config.cpp.

Ошибка: «Addon requires addon X»

Причина: requiredAddons[] в CfgPatches указывает аддон, который отсутствует. Решение: Либо установите требуемый аддон, добавьте его в сборку, либо удалите требование, если оно на самом деле не нужно.

Ошибка: ошибка парсинга config.cpp (строка X)

Причина: Синтаксическая ошибка в config.cpp. Решение: Откройте config.cpp в текстовом редакторе и проверьте строку X. Частые проблемы:

Отсутствующие точки с запятой после определений классов.
Незакрытые фигурные скобки {}.
Отсутствующие кавычки вокруг строковых значений.
Обратный слэш в конце строки (продолжение строк не поддерживается).

Ошибка: несовпадение префикса PBO

Причина: Префикс в PBO не совпадает с путями, используемыми в config.cpp или материалах. Решение: Убедитесь, что -prefix совпадает со структурой путей, ожидаемой всеми ссылками. Если config.cpp ссылается на MyMod\data\item.p3d, префикс PBO должен быть MyMod, а файл должен находиться по пути data\item.p3d внутри PBO.

Ошибка: «Signature check failed» на сервере

Причина: PBO клиента не совпадает с ожидаемой сервером подписью. Решение:

Убедитесь, что и сервер, и клиент имеют одну и ту же версию PBO.
При необходимости повторно подпишите PBO свежим ключом.
Обновите .bikey на сервере.

Ошибка: «Cannot open file» при бинаризации

Причина: Диск P: не смонтирован или путь к файлу неверен. Решение: Смонтируйте диск P: и убедитесь, что исходный путь существует.

Тестирование: патчинг файлов vs загрузка PBO

Разработка включает два режима тестирования. Выбор правильного для каждой ситуации экономит значительное время.

Патчинг файлов (разработка)

Аспект	Детали
Скорость	Мгновенно -- редактируем файл, перезапускаем игру
Настройка	Смонтировать диск P:, запустить с флагом `-filePatching`
Исполняемый файл	`DayZDiag_x64.exe` (требуется Diag-сборка)
Подписание	Не применимо (нет PBO для подписания)
Ограничения	Нет бинаризированных конфигов, только Diag-сборка
Лучше всего для	Разработка скриптов, итерация UI, быстрое прототипирование

Загрузка PBO (тестирование релиза)

Аспект	Детали
Скорость	Медленнее -- необходимо пересобирать PBO при каждом изменении
Настройка	Собрать PBO, поместить в `@mod/addons/`
Исполняемый файл	`DayZDiag_x64.exe` или розничный `DayZ_x64.exe`
Подписание	Поддерживается (обязательно для мультиплеера)
Ограничения	Пересборка необходима при каждом изменении
Лучше всего для	Финальное тестирование, мультиплеерное тестирование, валидация релиза

Лучшие практики

Используйте -packonly для скриптовых PBO. Скрипты никогда не бинаризируются, поэтому -packonly всегда корректен и намного быстрее.
Всегда устанавливайте префикс. Без префикса движок не может разрешить пути к содержимому вашего мода. Каждый PBO должен иметь корректный -prefix.
Автоматизируйте сборки. Создайте скрипт сборки (batch или Python) с первого дня. Ручная упаковка не масштабируется и подвержена ошибкам.
Храните исходники и вывод отдельно. Исходники на P:, собранные PBO в отдельной выходной директории или @mod/addons/. Никогда не упаковывайте из выходной директории.
Подписывайте PBO для любого мультиплеерного тестирования. Неподписанные PBO отклоняются серверами с включённой проверкой подписей. Подписывайте во время разработки, даже если это кажется ненужным -- это предотвращает проблемы «у меня работает», когда другие тестируют.
Версионируйте ключи. При внесении критических изменений генерируйте новую пару ключей. Это заставляет всех клиентов и серверы обновляться одновременно.
Тестируйте оба режима: патчинг файлов и PBO. Некоторые баги проявляются только в одном из режимов. Бинаризированные конфиги ведут себя иначе, чем текстовые, в граничных случаях.
Регулярно очищайте выходную директорию. Устаревшие PBO от предыдущих сборок могут вызывать путаницу. Используйте флаг -clear или очищайте вручную перед сборкой.
Разделяйте крупные моды на несколько PBO. Время, сэкономленное на инкрементальных пересборках, окупается в первый же день разработки.
Читайте логи сборки. Binarize и AddonBuilder создают файлы логов. Когда что-то идёт не так, ответ почти всегда в логах. Проверяйте %TEMP%\AddonBuilder\ и %TEMP%\Binarize\ для подробного вывода.

Наблюдения из реальных модов

Паттерн	Мод	Детали
20+ PBO на мод с мелкоструктурным разделением	Expansion (все модули)	Разделение на отдельные PBO для Scripts, Data, GUI, Vehicles, Book, Market и т.д., обеспечивающее независимые пересборки и опциональное разделение клиент/сервер
Тройное разделение Scripts/Data/GUI	StarDZ (Core, Missions, AI)	Каждый мод производит 2-3 PBO: `_Scripts.pbo` (packonly), `_Data.pbo` (бинаризированные модели/текстуры), `_GUI.pbo` (packonly макеты)
Один монолитный PBO	Простые моды ретекстура	Маленькие моды с только config.cpp и несколькими PAA-текстурами упаковывают всё в один PBO с бинаризацией
Версионирование ключей при каждом крупном релизе	Expansion	Генерирует новые пары ключей при критических обновлениях, заставляя всех клиентов и серверы обновляться синхронно

Совместимость и влияние

Мульти-мод: Коллизии префиксов PBO заставляют движок загружать файлы одного мода вместо другого. Каждый мод должен использовать уникальный префикс. Внимательно проверяйте $PBOPREFIX$ при отладке ошибок «file not found» в мульти-мод окружениях.
Производительность: Загрузка PBO быстрая (последовательное чтение файлов), но моды с множеством крупных PBO увеличивают время запуска сервера. Бинаризированный контент загружается быстрее небинаризированного. Используйте ODOL-модели и PAA-текстуры для релизных сборок.
Версия: Сам формат PBO не менялся. AddonBuilder получает периодические исправления через обновления DayZ Tools, но флаги командной строки и поведение упаковки стабильны со времён DayZ 1.0.

Глава 4.6: Упаковка PBO ​

Введение ​

Содержание ​

Что такое PBO? ​

Ключевые характеристики ​

Почему PBO, а не отдельные файлы ​

Внутренняя структура PBO ​

$PBOPREFIX$ ​

config.bin vs. config.cpp ​

AddonBuilder: инструмент упаковки ​

Режим GUI ​

Режим командной строки ​

Параметры командной строки ​

Флаг -packonly ​

Когда использовать -packonly ​

Практическое руководство ​

Флаг -prefix ​

Как работает префикс ​

Многоуровневые префиксы ​

Префикс должен совпадать со ссылками ​

Распространённые паттерны префиксов ​

Бинаризация: когда нужна, а когда нет ​

Что бинаризируется ​

Что НЕ бинаризируется ​

Детали бинаризации config.cpp ​

Подписание ключами ​

Компоненты пары ключей ​

Генерация ключей ​

Подписание при сборке ​

Установка ключей на сервере ​

Структура папки @mod ​

mod.cpp ​

Моды с несколькими PBO ​

Загрузка модов ​

Автоматизированные скрипты сборки ​

Паттерн Batch-скрипта ​

Паттерн Python-скрипта сборки (dev.py) ​

Интеграция с dev.py ​

Сборка модов с несколькими PBO ​

Зачем разделять на несколько PBO ​

Типичный паттерн разделения ​

Зависимости между PBO ​

Распространённые ошибки сборки и решения ​

Ошибка: «Include file not found» ​

Ошибка: «Binarize failed» без подробностей ​

Ошибка: «Addon requires addon X» ​

Ошибка: ошибка парсинга config.cpp (строка X) ​

Ошибка: несовпадение префикса PBO ​

Ошибка: «Signature check failed» на сервере ​

Ошибка: «Cannot open file» при бинаризации ​

Тестирование: патчинг файлов vs загрузка PBO ​

Патчинг файлов (разработка) ​

Загрузка PBO (тестирование релиза) ​

Рекомендуемый рабочий процесс ​

Лучшие практики ​

Наблюдения из реальных модов ​

Совместимость и влияние ​

Навигация ​

Глава 4.6: Упаковка PBO

Введение

Содержание

Что такое PBO?

Ключевые характеристики

Почему PBO, а не отдельные файлы

Внутренняя структура PBO

$PBOPREFIX$

config.bin vs. config.cpp

AddonBuilder: инструмент упаковки

Режим GUI

Режим командной строки

Параметры командной строки

Флаг -packonly

Когда использовать -packonly

Практическое руководство

Флаг -prefix

Как работает префикс

Многоуровневые префиксы

Префикс должен совпадать со ссылками

Распространённые паттерны префиксов

Бинаризация: когда нужна, а когда нет

Что бинаризируется

Что НЕ бинаризируется

Детали бинаризации config.cpp

Подписание ключами

Компоненты пары ключей

Генерация ключей

Подписание при сборке

Установка ключей на сервере

Структура папки @mod

mod.cpp

Моды с несколькими PBO

Загрузка модов

Автоматизированные скрипты сборки

Паттерн Batch-скрипта

Паттерн Python-скрипта сборки (dev.py)

Интеграция с dev.py

Сборка модов с несколькими PBO

Зачем разделять на несколько PBO

Типичный паттерн разделения

Зависимости между PBO

Распространённые ошибки сборки и решения

Ошибка: «Include file not found»

Ошибка: «Binarize failed» без подробностей

Ошибка: «Addon requires addon X»

Ошибка: ошибка парсинга config.cpp (строка X)

Ошибка: несовпадение префикса PBO

Ошибка: «Signature check failed» на сервере

Ошибка: «Cannot open file» при бинаризации

Тестирование: патчинг файлов vs загрузка PBO

Патчинг файлов (разработка)

Загрузка PBO (тестирование релиза)

Рекомендуемый рабочий процесс

Лучшие практики

Наблюдения из реальных модов

Совместимость и влияние

Навигация