moonwell-editor/docs/play.md

Проверка в игре

Кнопка Play открывает отдельное окно Benilla / MoonWell на локальном vMaNGOS. Редактор остаётся открытым. Стоп завершает только запущенный им клиент; обычное закрытие клиента также освобождает сессию. Закрытие редактора завершает принадлежащий ему клиент.

Первая настройка

1. Зарезервировать отдельный локальный аккаунт, например EDITORPLAY. Не использовать его для обычной игры. В консоли локального vMaNGOS создать аккаунт и выдать уровень GM 3:

   account create EDITORPLAY <свой-пароль>
   account set gmlevel EDITORPLAY 3
   

   Игровой уровень берётся из realmd.account_access для выбранного Realm ID (либо общей записи -1). Поле account.gmlevel не задаёт права игровой сессии в этом ядре. Проверка Play использует тот же приоритет, что WorldSocket::HandleAuthSession: запись конкретного реалма важнее общей.

   Консоль: в WSL из <папка-ядра>/deploy/local выполнить ./compose.sh attach --sig-proxy=false mangosd. Выход без остановки сервера — Ctrl+P, Ctrl+Q.

2. Один раз войти этим аккаунтом в клиент и создать персонажа, например Playtester. Затем выйти из аккаунта.

3. Заполнить «Настройки Play»: путь к клиенту, Realm ID, аккаунт, пароль и имя персонажа. Нажать «Сохранить настройки Play». Старый .env импортируется явно; см. установку.

4. Убедиться, что локальная БД запущена и EDITOR_WORLD_DB указывает на неё. У пользователя БД нужны права чтения mangos, realmd.account, characters.characters.

5. Для автоматического применения изменений указать EDITOR_PLAY_PREPARE на scripts/prepare-play.ps1, задать фактическую папку ядра в WSL и порт мира. Скрипт работает с локальным Compose project vmangos-local через deploy/local/compose.sh, применяет миграции и перезапускает mangosd. Он не собирает образы: локальный сервер должен быть подготовлен заранее.

Поддерживаются клиенты Benilla / MoonWell с автологином через WOW_USER, WOW_PASS, WOW_CHAR и загрузкой пользовательских аддонов из BENILLA_HOME/AddOns. Оригинальный WoW.exe этим способом не запускается. Dev-сборка клиента с .probe-identity разрешает только объявленный там аккаунт: использовать выделенный аккаунт этой сборки либо player-сборку. Редактор не отключает эту защиту и не меняет чужой .probe-identity.

Рабочий цикл

1. Расставить NPC.
2. Нажать «Поставить точку Play» и щёлкнуть по загруженной поверхности мира. Зелёное кольцо обозначает ноги персонажа, стрелка — направление камеры при выборе. Esc отменяет выбор.
3. При необходимости поправить карту, координаты и направление в «Настройках Play». Точка сохраняется в проекте, но не создаёт SQL-изменений. «Сбросить точку» оставляет персонажа на его последнем серверном месте.
4. Нажать Play. Проект сохраняется, аккаунт проверяется на занятость и права, а данные проекта сверяются с БД.
5. Если настроен скрипт подготовки, новые изменения экспортируются обычным механизмом миграций, проект сохраняется с новой baseline, скрипт применяет контент и перезапускает сервер. Интерфейс не блокируется; редактирование на время подготовки отключено.
6. После повторной проверки применённых миграций открывается клиент с автологином. Локальный аддон один раз после входа отключает GM-режим (.gm off, права остаются) и переносит нужного персонажа командой .go xyzo x y z orientation map.
7. Проверить контент вручную. Закрыть клиент или нажать «Стоп», затем продолжить редактирование.

Без скрипта подготовки нужно заранее экспортировать и применить миграции, перезапустить mangosd. При незавершённом экспорте или неприменённых миграциях Play откажет в запуске. Редактор читает серверные данные, но не может проверить содержимое уже загруженных grid сервера по SQL: перезапуск при ручной подготовке обязателен.

Состояние и ошибки

• Play разрешён только для локального адреса сервера и локальной БД.
• Аккаунт должен быть офлайн; персонаж должен принадлежать ему. Чужая активная сессия не вытесняется намеренно. Локальная файловая блокировка запрещает два одновременных Play из одного профиля пользователя и освобождается ОС при завершении процесса.
• Клиентское состояние и сгенерированный аддон находятся в state/play/ профиля данных, отдельно от обычных настроек игрока. В установку WoW ничего не записывается.
• Пароль передаётся дочернему клиенту в окружении. Он не входит в проект, аддон, аргументы командной строки или сообщения редактора. Постоянные настройки — в личном settings.json.
• client.log и prepare.log находятся в state/play/ профиля данных пользователя.
• Сбой подготовки оставляет уже экспортированную миграцию и baseline в проекте. Повторный Play применяет её повторно через штатный мигратор; новую копию миграции не создаёт.
• Смерть NPC и таймеры возрождения сохраняются сервером между запусками Play. «Сохранить» и перезапуск мира не воскрешают уже погибшего NPC: нужно дождаться его возрождения. Новые размещения получают новый guid даже после удаления всех старых спавнов и экспорта, чтобы не наследовать таймер умершего существа. Старый проект без истории выделения не позволяет восстановить guid удалённых ранее NPC; новый счётчик работает с этого сохранения.
• Ожидание порта мира в стандартном скрипте ограничено 120 секундами; запуск скрипта редактором ограничен 180 секундами.
• Эта версия проверяет серверный контент R1. Сборка и подключение ещё не реализованных клиентских MPQ/DBC не добавляются автоматически.

Приёмка

Поставить тестового NPC на земле и на этаже WMO, выбрать старт рядом, нажать Play и сравнить положение и направление с редактором. В игре проверить .gps. Повторить после перемещения NPC. Проверить отказ при занятом аккаунте, неверном персонаже и ошибке подготовки. Боевые проверки выполняются человеком.