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

Прежде чем использовать один из вариантов создания шаблонов, вероятно, не менее важной частью будет ознакомиться с их содержимым. В первую очередь, мод — это папка с конфигурационным файлом build.config, именно он описывает весь процесс загрузки, сборки и построения вашего мода. Давайте рассмотрим содержимое всей папки, и прежде разберем другие, но не менее важные аспекты.

А что если я хочу использовать тулчейн?

Даже если использовать тулчейн с другой структурой сборки, изучить содержимое собранного им мода не будет лишним.

Что в шаблоне

.
├─ .dex (используется для хранения файлов релизной сборки)
├─ dev (основная папка со скриптами, сюда будет помещен весь код)
│  ├─ .includes (список файлов для сборки файлов в main.js)
│  └─ header.js (один из скриптов, обычно заголовок содержит копирайт)
├─ assets (общая папка с ресурсами, их описание будет представлено позже)
│  ├─ resources
│  │  ├─ terrain-atlas
│  │  └─ items-opaque
│  └─ gui
├─ launcher.js (скрипт, который будет запущен на этапе загрузки, выполняет main.js)
├─ build.config (основной сборочный файл, добавляющий в мод файлы выше)
├─ mod.info (описание основной информации о моде)
├─ mod_icon.png (иконка для отображения в браузере)
├─ config.json (конфигурация для хранения различных настроек)
└─ config.info.json (описание для конфигурации настроек в интерфейсе)

Визуальная часть

В первую очередь состоит из представления вашего мода в браузере. За это отвечают сразу два файла — mod.info и mod_icon.png.

mod.info

Содержит в себе основную информацию, которая будет использована для отображения: название, авторство, версию и описание соответственно. Фактически, это JSON, обычно представляемый в одном и том же варианте:

mod.info

{
    "name": "Назови меня",
    "author": "ICDocs",
    "version": "1.0",
    "description": "Краткое описание, показывается лишь в списке модов, иначе загружается полное из браузера."
}

Любые свойства здесь опциональны, однако рекомендуется использовать их все. Единственное стандартное для мода — это его название, если в этом файле его нет, используется название папки. Потратьте на описание не больше 10-15 слов. Иначе оно просто не влезет в интерфейс браузера модов.

mod_icon.png

Иконка, предпочтительный размер 192x192 пикселя, именно в нем собрано большинство модов и сборок от других авторов. Однако, вы можете использовать любой другой или изменить его перед публикацией.

Конфигурация свойств

Основана на двух файлах. Это сам config.json для описания свойств и опциональный config.info.json для описания отображения конфигурации в интерфейсе. Фактически, конфигурация свойств это настройки. Вы сможете использовать их из любого места вашего кода.

config.json

Будет создан самим лаунчером если его еще нет. По умолчанию содержит лишь одно свойство:

config.json

{
  "enabled": true
}

Свойство enabled определяет, включен ли мод и нужно ли выполнять его код. Даже в случае если мод отключен, его ресурсы все равно будут загружены. Подробнее вы сможете узнать в статье Жизненный цикл мода.

Но зачем нужен файл для одного свойства?

Что же, давайте рассмотрим реальный пример. Вот так выглядит конфигурация мода Gravitation Suite от Mine Explorer:

config.json

{
    "enabled": true,
    "change_quantum_suit_recipe": true,
    "change_iridium_drill_recipe": true,
    "energy_text": {
        "pos": "right",
        "scale": 135,
        "y": 30
    }
}

Каждое свойство запрашивается самим модом, а настройки производятся через интерфейс мод браузера. Удобно, не правда ли? Мы подробнее разберем использование конфигураций уже очень скоро.

config.info.json

Файл описывает визуализацию конфигурации в интерфейсе, каждое свойство может быть скрыто, переведено на различные языки, ограничено или дополнено описанием. Для примера, можно создать файл следующего содержания:

config.info.json

{
    "properties": {
        "enabled": {
            "name": {
                "en": "Launch",
                "ru": "Запуск"
            },
            "description": "Должен ли мод быть запущен"
        }
    }
}

Использование этого файла и конфигураций представлено в другой статье.

Построение и сборка

Конфигурационный файл build.config подразделяется на иерархию объектов внутри себя. Вот комплексный пример из мода Vampirism от redbad:

• Структура мода
• build.config

Vampirism
├─ assets
│  ├─ res
│  │  ├─ ...
│  │  ├─ items-opaque
│  │  └─ terrain-atlas
│  └─ gui
├─ dev
│  ├─ ...
│  ├─ translation.js
│  └─ .includes
├─ lib
├─ minecraft_packs
│  ├─ resource
│  │  └─ vampirism
│  │     └─ ...
│  └─ behavior
├─ java
│  └─ scales
│     ├─ classes.dex
│     └─ manifest
├─ native
│  └─ scales
│     ├─ so
│     │  └─ armeabi-v7
│     │     └─ libscales.so
│     └─ manifest
├─ ...
├─ launcher.js
└─ build.config

Далее описано большинство доступных свойств. Каждое из них служит для описания построения и сборки, пути к ресурсам и коду, запуска и компиляции. Рассмотрим каждое из них.

resources

Массив, содержащий объекты-описания с типом ресурса и путем до него. На самом деле, описание представляется таким прототипом:

{
    "path": "относительный путь от папки, в которой расположен build.config",
    "resourceType": "gui для интерфейсов либо resource в остальных случаях"
}

Относительный путь во всех случаях выстраивается на основе того, где находится ваш build.config. Например, если он лежит в папке mods/Super Stick/build.config, относительным путем до папки ресурсов mods/Super Stick/assets/resource/ будет assets/resource/.

defaultConfig

Наиболее важные свойства, от них зависит построение остальных папок со скриптами и их компиляции. Также, здесь указываются пути до не менее важных папок:

{
    "buildType": "develop, меняется на release в случае компиляции мода; не изменяйте вручную",
    "api": "давайте остановимся на том, что основным для модов остается CoreEngine",
    "libraryDir": "относительный путь до папки с собранными библиотеками, еще будет рассмотрено отдельно",
    "resourcePacksDir": "относительный путь до папки с пакетами ресурсов, именно в виде папок, а не архивов",
    "behaviorPacksDir": "относительный путь до папки с пакетами поведения, именно в виде папок, а не архивов"
}

Обычно изменяется лишь при создании мода, так как задает основные свойства для всей сборки.

compile

Непосредственно скрипты, которые должны быть загружены или "скомпилированы". Что значит скомпилированы? Приведены к читаемому для устройства виду, в байткоде. Остановимся на том, что здесь можно задать два основных скрипта: запуска и самого мода. Описание склоняется к следующему виду:

{
    "path": "относительный путь от папки, в которой расположен build.config",
    "sourceType": "launcher для запуска, main для самого мода, или, например, custom"
}

buildDirs

Папки со скриптами, которые необходимо "собрать" из нескольких файлов в один. В выбранной папке должен располагаться файл .includes, именно он описывает порядок и список файлов для сборки. Объект описания папки:

{
    "dir": "относительный путь от папки, в которой расположен build.config",
    "targetSource": "выходной файл собранного скрипта, например, main.js"
}

Выходной файл может быть впоследствии использован в compile, конечно, можно просто собрать файл и более ничего не делать с ним, однако имеет ли этот смысл. Сборочные файлы будут описаны в следующих статьях.

native- и javaDirs

Исключительно пути до папок, откуда будет загружен (опционально и собран) C++ и Java код соответственно. Единственное доступное свойство представляется в таком виде:

{
    "path": "относительный путь от папки, в которой расположен build.config"
}