Обновление скрипта

Найдите устаревшееCopy Anchor Link

Предупреждение в консоли охватывает только запущенные и не игнорируемые скрипты, поэтому проверьте каждую папку:

cd "resources/[ai]"
for n in ai-*; do
  repo=$(sed -n 's#.*"repository": *"\(github:\|https://github.com/\)\([^"]*\)".*#\2#p' "$n/package.json" | sed 's#\.git$##')
  cur=$(sed -n 's#^  "version": *"\([^"]*\)".*#\1#p' "$n/package.json")
  latest=$(gh release view --repo "$repo" --json tagName --jq .tagName 2>/dev/null | sed 's#^v##')
  echo "$n $cur ${latest:-no-release}"
done

• Сравнивайте версии как ai-core: уберите начальную v, сравните числа через точку, игнорируйте суффиксы pre-release. Нет релиза, значит, обновлять нечего.
• Без gh: curl -s -H "Accept: application/vnd.github+json" https://api.github.com/repos/<owner>/<name>/releases/latest (60 запросов в час с одного IP, общих с собственной проверкой ai-core).
• Скрипт из updates.ignore обновляется, только если владелец назвал его.
• Папка с версией выше последнего релиза или клон с коммитами после последнего тега не устарели: пропустите их, никогда не откатывайте папку назад.
• В packages/ нет строки repository: сравните версию каждого package.json с npm. Сначала обновите пакеты, если новому релизу скрипта нужна версия, которой нет в локальных копиях.

Прочитайте заметки к релизу и получите согласиеCopy Anchor Link

Прочитайте заметки каждой версии между текущей и последней (gh release view <tag> --repo <repo> --json body,assets,url): несовместимые изменения, нужные версии пакетов, миграции, новые строки cfg (ensure, add_convar_permission, ACE), новые имена provide, ручные шаги.

Покажите владельцу список и дождитесь согласия. Обновляйте в порядке зависимостей: пакеты, ai-mysql, ai-core, ai-lib, затем остальное.

Скачайте старый и новый upstreamCopy Anchor Link

Для каждого скрипта две новые пустые папки вне сервера (например, update/<name>/old и update/<name>/new):

gh release download <tag> --repo <owner>/<name> --archive zip --dir update/<name>/new     # исходники тега
gh release download <tag> --repo <owner>/<name> --pattern '*.zip' --dir update/<name>/new # asset релиза, если он есть
unzip -q update/<name>/new/*.zip -d update/<name>/new/x

• Если у релиза есть asset, берите его; иначе исходники тега (в них есть закоммиченные dist/ и fxmanifest.lua). Верхняя папка zip с исходниками называется <owner>-<name>-<sha>/.
• Старый upstream это тег версии, которая работает на сервере (стиль тегов видно через gh release list --repo <owner>/<name>). Его всегда можно скачать, поэтому у трёхстороннего сравнения всегда есть база.
• Ничего в этих папках не запускается, не устанавливается и не собирается.

Сделайте резервную копиюCopy Anchor Link

• Скопируйте всю папку скрипта, кроме node_modules, в update/<name>/ours (в Windows robocopy "<src>" "<dst>" /E /XD node_modules; коды выхода robocopy меньше 8 означают успех). Это «наше» для слияния и путь назад.
• Файлы, которые git игнорирует, есть только в этой копии: data/secrets.json, data/*.json.bak. В клоне git их перечисляет git ls-files --others --ignored --exclude-standard.
• Незакоммиченные изменения в клоне (git status --porcelain) тоже изменения сервера. Скажите о них владельцу; коммитьте их только по его просьбе.

Сливайте файл за файломCopy Anchor Link

Примените трёхстороннюю модель к старому, нашему и новому и запишите результат в папку скрипта:

Содержимое панели (data/*.json) это живое содержимое сервера, изменяемое в панели; релиз приносит только значения по умолчанию.

• Та же схема (новый schema.ts или loader читает те же поля): оставьте наше как есть. Файл, который добавляет новая версия: возьмите поставляемый.
• Схема изменилась: найдите собственную миграцию скрипта при старте (заметки к релизу, миграция, вызываемая при старте). Если она есть, оставьте наше на месте; она преобразует его при старте. Если нет, преобразуйте вручную по новому loader и схеме: те же имена полей, типы и формат id, что в поставляемом файле, каждое значение сохранено, новые поля со значением по умолчанию из поставки, удалённые поля убраны и указаны в отчёте. Проверьте, что каждый файл парсится.

База данных. Каждый скрипт создаёт свои таблицы из sql/main.sql при старте: создаёт недостающие таблицы и добавляет недостающие столбцы, но никогда не удаляет, не переименовывает и не меняет столбец и не добавляет ключи. Сравните старый и новый sql/main.sql:

• Новые таблицы и столбцы: их применит перезапуск.
• Изменённый тип столбца, новый индекс или ключ, переименованный или удалённый столбец: релиз должен принести свою миграцию (заметки к релизу, серверный код), она выполняется при старте; проверьте лог. Если её нет, напишите SQL, покажите владельцу, сделайте копию затронутых таблиц и выполните его только с его согласия.

Cfg-файлы вне папки.

• server.cfg: новый скрипт получает свою строку ensure в порядке зависимостей; удалённый её теряет (сначала спросите).
• env.cfg и env.example.cfg: скрипту, который начинает использовать базу данных, нужен add_convar_permission <resource> read mysql_connection_string.
• permission.cfg: строки ACE, которых требуют заметки к релизу.
• security.cfg: никогда не ослабляется.

Соберите, перезапустите, проверьтеCopy Anchor Link

1. bun install в корне сервера, если изменился какой-либо package.json.

2. В каждом обновлённом скрипте: bun run typecheck, bun run lint, bun run build (или bun tools/run.ts build ai-x ai-y из корня сервера). Собирайте всегда: dist/ должен получаться из слитых исходников. Исправляйте ошибки в перенесённых изменениях сервера; ошибка в нетронутом коде upstream попадает в отчёт, а не латается.

3. Сравните результат с новым upstream: diff -r --strip-trailing-cr -x node_modules -x dist -x data update/<name>/new/x/<top> "<script folder>". Каждое оставшееся различие должно быть одним из изменений сервера.

4. Сделайте refresh и перезапуск:

   Copy Text

   bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh"
   bun tools/restart.ts --from ai-inventory   # один скрипт
   bun tools/restart.ts                       # после обновления ai-core, ai-lib, ai-mysql или пакетов

   bun tools/restart.ts перезапускает ai-core, делает ensure для каждого ai-* после него и проверяет, что каждый запустился. Сторонние скрипты, зависящие от ai-mysql, останавливаются вместе с ним: снова сделайте им ensure по имени. Новая строка provide требует полного запуска сервера: bun tools/rcon.ts "quit \"<reason>\"".

5. Прочитайте лог консоли на SCRIPT ERROR, Failed to load script, [client error], ошибки загрузки или проверки панели и ошибки базы данных, а не только Started resource. Предупреждение is outdated должно пропасть после следующей проверки скрипта.

Сопоставьте поставку с установленнымCopy Anchor Link

• Каждая папка верхнего уровня с fxmanifest.lua (или __resource.lua) это ресурс; папка [category] содержит несколько. Распакуйте zip в новую пустую папку и ничего оттуда не запускайте.
• Найдите установленную копию по имени папки внутри resources/ (например, find resources -maxdepth 3 -type d -name <name>). Сохраняйте установленное расположение, а не категорию из поставки. Нет совпадений или их несколько: спросите владельца. Ещё не установленный скрипт устанавливается, только если так скажет владелец.
• Папка ai-* в поставке идёт не по этому пути: скрипты ai-* обновляются с GitHub (выше). Спросите владельца, что это за папка.
• Прочитайте оба манифеста: version, files, скрипты, dependencies, provide, escrow_ignore, ai_replaces. Версия, которая уменьшилась, или поставка без файлов, которые есть в установленной копии, может оказаться более старой сборкой: сравните и сообщите вместо установки.
• Новые зависимости: oxmysql обслуживает ai-mysql (никогда не ставьте oxmysql рядом); ox_lib и другие библиотеки устанавливает владелец; зависимость от того, что заменяет ai-core (es_extended, qb-core, qbx_core, pma-voice, ox_inventory...), уже выполнена.
• Покажите сопоставленный список (имя, путь, текущая -> новая версия) и дождитесь согласия.

Сделайте резервную копиюCopy Anchor Link

• Скопируйте всю установленную папку в папку резервной копии вне сервера (robocopy "<src>" "<dst>" /E). Для папки, которую не отслеживает ни один репозиторий git, эта копия единственная копия версии сервера.
• Если git отслеживает папку: git status --porcelain -- <path> показывает незакоммиченные изменения (они считаются нашими; скажите владельцу), а git ls-files --others --ignored --exclude-standard -- <path> показывает рабочие файлы, которые git игнорирует (сохранённый JSON, кэши), они есть в копии.

Найдите изменения сервераCopy Anchor Link

Получите старый upstream в таком порядке:

1. У владельца ещё есть старый zip или папка от поставщика.
2. Скрипт с открытым кодом на GitHub: релиз или тег установленной версии.
3. История git, если папка отслеживается: коммит, который выставил установленную version (git log -S"version '<old>'" -- <path>/fxmanifest.lua). Если этот коммит заодно заново применил прежние настройки, его config-файлы считаются нашими, а чистая поставка находится на коммит раньше.
4. Ничего из этого: сравните наше с новой версией напрямую и укажите это в отчёте.

Затем прочитайте каждое различие старый -> наше (правки сервера: конфиги, locales/* или languages/*, editable-файлы, data/*.json, fxmanifest.lua, SQL, изображения, звуки, stream-файлы, патчи кода) и старый -> новый (изменения поставщика: добавленные и удалённые файлы, переименованные ключи, перенесённые разделы, изменённые editable-функции). В скрипте с escrow (есть .fxap) читать и править можно только файлы из escrow_ignore; правку в файле, который новая версия закрыла escrow, перенести нельзя, она попадает в отчёт.

Установите новую версиюCopy Anchor Link

Полностью удалите установленную папку, затем скопируйте новую папку по тому же пути, включая скрытые файлы (.fxap). Старые остатки это ошибки; старая версия остаётся в резервной копии. Возвращайте рабочие файлы из копии, только если новая версия использует их в том же формате; иначе преобразуйте или отбросьте их и сообщите.

Перенесите изменения сервераCopy Anchor Link

Для каждой правки найдите, где эта настройка находится в новой версии, и впишите туда значение в новом формате:

• Тот же ключ, тот же файл: задайте значение в новом файле; сохраните его комментарии и разметку.
• Переименованный или перенесённый ключ: найдите новый ключ, читая код, который его использует (ищите старое имя, его комментарий, значение по умолчанию, текстовый ключ), и преобразуйте значение в новую форму.
• Конфиг перенесён в файл данных (JSON, который правит собственная панель скрипта): прочитайте новый loader и поставляемый файл, впишите старые значения ровно в эту схему (имена полей, типы, формат id, отступы) и проверьте, что он парсится. Не полагайтесь на конвертер, который скрипт может запустить.
• Существующие файлы данных сервера: перенесите их, преобразуйте поле за полем, если схема изменилась, никогда не заменяйте их примером поставщика.
• Удалённая опция: её больше не читает никакой код (поиск это подтверждает): уберите её и укажите в отчёте со старым значением.
• Editable-файлы (client/editable.lua, server/editable.lua...): начните с нового файла и заново примените каждое изменённое тело функции, подогнав его к изменённой сигнатуре или возвращаемому значению; новые функции остаются по умолчанию.
• Языки: сохраните формулировки сервера для каждого ключа, который ещё есть; добавьте новые ключи в каждый языковой файл, который использует сервер, в переводе в тоне существующих текстов; уберите удалённые ключи; следуйте изменённым плейсхолдерам.
• fxmanifest: новый, плюс только те собственные добавления сервера, которые ещё имеют смысл. Никогда не меняйте version.
• SQL (*.sql, папки установки): сравните старый и новый; новые таблицы, столбцы и индексы попадают в отчёт как SQL, который запускает владелец. Без его согласия ничего не выполняется.
• Учётные данные (токены ботов, ключи API, адреса вебхуков в конфигах): никогда не выводите их. Перенесите их из копии; если это невозможно, оставьте новое значение по умолчанию и укажите владельцу файл и ключ.
• Ассеты (stream/, изображения, звуки): поставщика плюс файлы, добавленные сервером и всё ещё используемые.
• Координаты, предметы, цены, тексты и поведение переносятся в точности; кроме собственных правок сервера ничего не меняется.

Проверьте совместимость с ai-coreCopy Anchor Link

Скрипт может быть одним из тех, с кем общается ai-core. Найдите каждое место, где он упоминается:

grep -rln "<name>" "resources/[ai]/ai-core/resource" "resources/[ai]/ai-core/bridge" docs/compat

• Для каждого export, event и callback, которые использует адаптер, проверьте новую версию: всё ещё есть, те же аргументы, та же форма результата, тот же момент вызова. В коде с escrow проверьте читаемые файлы и документацию поставщика и перечислите то, что проверить нельзя.
• Несовпадение исправляется только в файле адаптера (тонкий перевод), с повышением его проверенной версии; затем typecheck, lint и build ai-core и его перезапуск (bun tools/restart.ts).
• Новая строка ai_replaces или provide может заставить ai-core отклонять подключения, пока ещё работает заменитель ai-* (см. Замена скрипта ai-*): назовите папку, которую владелец должен удалить.
• Обновите docs/compat/<script>.md (проверенная версия, статус, точный конфиг или патч, известные ограничения); поддерживаемый скрипт без заметки получает её.

Проверьте и перезапуститеCopy Anchor Link

• Сравните установленный результат с новой версией: каждое различие это изменение сервера, и не осталось ни одного старого файла, которого нет в новой версии (кроме восстановленных рабочих файлов).
• Изменённый Lua парсится, JSON парсится, каждый заданный ключ конфига существует в новом коде.
• Если никакой SQL не ждёт владельца: bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh", затем то же с "ensure <name>", и прочитайте лог на SCRIPT ERROR, Failed to load script и собственные ошибки скрипта. Зависящие от него скрипты, которые остановились, запускаются снова.