Управление файлами

Где всё лежит на прокси и как выдать одному серверу другой контент.

Всё, что вы редактируете, живёт в одной папке на прокси:

plugins/nexohub/nexo-data/
├── _shared/                    goes to every backend
│   ├── items/
│   ├── glyphs/
│   ├── recipes/
│   ├── pack/assets/
│   ├── pack/external_packs/
│   └── settings.yml
├── groups/
│   └── survival/               only the backends you list, wins over _shared
│       └── items/
└── servers/
    └── pvp/                    only this backend, wins over both
        └── items/

Всё, что лежит в _shared/, попадает в plugins/Nexo/ на каждом бэкенде. Всё, что в servers/<name>/, попадает только на этот бэкенд и переопределяет общую копию того же файла.

Имя сервера — это то, как вы назвали его в списке серверов вашего прокси: velocity.toml или config.yml у BungeeCord.

​

Как сделать один сервер другим

Положите файл, который хотите изменить, в servers/<name>/, повторяя путь, который он имеет в _shared/. Переопределяется только этот один файл, всё остальное по-прежнему приходит из _shared/.

_shared/settings.yml            most servers get this
servers/pvp/settings.yml        pvp gets this instead

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

Это для различия, которое вы намерены сохранить. Чтобы опробовать изменение на одном сервере, прежде чем его получит остальная сеть, используйте вместо этого /nexohub stage, которая удерживает все остальные бэкенды на тех файлах, что у них уже есть.

​

Группы

Если четыре сервера хотят одно и то же переопределение, размещение одного и того же файла в четырёх папках servers/ означает, что менять его придётся в четырёх местах. Группа — это промежуточный слой.

Назовите группу и перечислите её бэкенды в config.yml прокси:

groups:
  survival: [smp, smp2, smp3]
  minigames: [bedwars, skywars]

Затем положите файлы в nexo-data/groups/survival/, устроенную точно так же, как _shared/.

Порядок такой: _shared/, затем группы, к которым принадлежит сервер, затем servers/<name>/. Каждый слой побеждает предыдущий, поэтому одиночное переопределение всё равно берёт верх над своей группой:

_shared/settings.yml            everything else
groups/survival/settings.yml    smp, smp2 and smp3
servers/smp2/settings.yml       smp2, whatever its group says

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

Те же три слоя переносят не только файлы, но и настройки. Всё, что вы напишете рядом с servers: в группе, применяется к этим бэкендам:

groups:
  minigames:
    servers: [bedwars, skywars]
    poll_seconds: 30

Простой список выше — это сокращённая запись для группы, которая накладывает только файлы, и она продолжает работать.

/nexohub status называет слои, которые каждый сервер реально получил, — это самый быстрый способ проверить, что группа делает то, что вы думаете:

  smp2 [4p] bundle 5d935602 +groups/survival+servers/smp2 in sync

Редактирование groups: — это изменение конфига, поэтому после него выполните /nexohub reload. Группа без перечисленных бэкендов игнорируется с предупреждением, а /nexohub doctor указывает на участников группы, которых нет в списке серверов вашего прокси.

​

Совместное использование конфигов других плагинов

Плагинами, отличными от Nexo, можно управлять точно так же. Положите их под _plugins/:

_shared/
├── items/                      goes to plugins/Nexo/items/
└── _plugins/
    ├── BetterModel/            goes to plugins/BetterModel/
    └── CustomNameplates/       goes to plugins/CustomNameplates/

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

groups/survival/_plugins/BetterModel/models/boss.bbmodel
servers/pvp/_plugins/BetterModel/models/boss.bbmodel

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

​

Пак, который вы скачали

Пак, который вы купили или скачали, с MCModels или откуда угодно ещё, кладётся в _shared/pack/external_packs/ — либо распакованным в отдельную папку, либо в виде скачанного zip:

_shared/pack/external_packs/mcmodels/
_shared/pack/external_packs/mcmodels.zip

Nexo импортирует оба варианта. Zip обычно требует меньше работы, и у него есть одно практическое преимущество: файлы внутри него никогда не парсятся, тогда как в распакованной папке каждый .json и .mcmeta проверяется перед тем, как что-либо будет отправлено, и один повреждённый файл в купленном паке блокирует весь пуш, пока вы его не исправите. Распакуйте его, если хотите редактировать содержимое, и оставьте zip, если нет.

Он попадает в plugins/Nexo/pack/external_packs/ на каждом бэкенде, и Nexo включает его в пак. Удаление папки на прокси убирает её с каждого бэкенда при следующем пуше, и то же самое происходит при удалении отдельного файла внутри неё, пока у этого бэкенда включён prune.

Это противоположность тому, что BetterHUD и подобные плагины записывают в external_packs/ при каждой загрузке — папкой или zip, в зависимости от их pack-type. Их вы никогда не размещаете сами, и хаб их не удаляет; NexoHub отличает их от ваших паков, читая, куда каждый плагин заявляет, что он собирает. См. паки плагинов.

Не кладите собственный пак напрямую в plugins/Nexo/pack/external_packs/ бэкенда. Что произойдёт дальше, зависит от того, как вы его туда положили, и ни один из вариантов — не тот, что вам нужен:

• В виде zip он остаётся на этом одном бэкенде. Ничто не переносит его на остальные, и /nexohub adopt его тоже не забирает, так что он попадает в пак, который скачивают игроки, только пока пак этого бэкенда — тот, который раздаёт сеть.
• Распакованный в папку, он публикуется на всю сеть как собственный вывод этого бэкенда, потому что папка там — это то, как собираются плагины, генерирующие каталоги, и ничто не отличает вашу от их. Ваша копия остаётся на месте, и бэкенд об этом сообщает.

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

​

Настройки, которые остаются локальными

Некоторые настройки принадлежат отдельному серверу и должны пережить пуш. По умолчанию NexoHub защищает настройки пак-сервера Nexo — именно они направляют этот бэкенд на хаб в первую очередь:

sync:
  preserve:
    Nexo/settings.yml:
      - Pack.server

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

​

Файлы, которые вы никогда не хотите пушить

sync:
  exclude:
    - Nexo/pack/external_packs/BetterHud/

Запись, заканчивающаяся на /, исключает целую папку.

Это вам понадобится редко. Всё, что ваши другие плагины генерируют во время работы, уже в безопасности, как и исполняемый файл PackSquash в pack/packsquash/.

Обращайтесь к exclude, когда файл, которым NexoHub всё-таки управляет, должен пережить пуш, или когда устаревшая копия сгенерированного контента случайно оказалась в nexo-data/, например после копирования целой папки plugins/Nexo/ на прокси.

​

Что пропускается автоматически

Скрытые файлы, резервные копии редакторов, заканчивающиеся на ~, и всё, что больше 64 МБ, никогда не отправляются. Частичные загрузки, заканчивающиеся на .tmp или .swp, не вызывают перезагрузку, поэтому загрузка большой папки по SFTP приводит к одной перезагрузке после её завершения, а не к одной на каждый файл.

​

Перед отправкой чего-либо

Каждый .yml, .yaml, .json и .mcmeta сначала проверяется, и если в любом из них есть ошибка, ничего не отправляется. Копия ваших файлов сохраняется при каждом их изменении, так что правку можно отменить. См. как не сломать свою сеть.