Подготовка и запуск Minecraft

Лаунчер выполняет единый автоматический сценарий. Пользователь выбирает сервер, после чего отдельно нажимать «Запустить» не требуется: клиент и Java подготавливаются, проверяются, а затем Minecraft запускается автоматически.

Что возвращает API

POST /api/launcher/builds/profile возвращает четыре связанных объекта:

{
  "profile": {
    "title": "Create",
    "recommendJavaVersion": 17,
    "minJavaVersion": 17,
    "maxJavaVersion": 21,
    "mainClass": "net.minecraft.client.main.Main"
  },
  "build": {
    "serverId": 2,
    "revision": "sha256-derived-revision",
    "manifest": {}
  },
  "assets": {
    "id": "1.7.10",
    "manifest": {}
  },
  "runtime": {
    "id": "java-17-win32-x64",
    "version": 17,
    "executable": "bin/javaw.exe",
    "consoleExecutable": "bin/java.exe",
    "manifest": {}
  }
}

profile описывает правила запуска Minecraft. build описывает файлы конкретной сборки. runtime описывает доверенную Java, общую для всех профилей с той же рекомендуемой версией. Перед передачей build manifest в Rust scanner main process получает active release из launcher-server, проверяет Ed25519 envelope по pinned public key и сравнивает compatibility payload сайта с подписанным контрактом. Проверяются не только пути, размеры и SHA-256, но и mainClass, classpath, JVM/game args, asset index, Java runtime, категории файлов и policy managed/ replace-on-update. Частичное совпадение недостаточно: ослабленная файловая политика или подменённый параметр запуска завершают подготовку с CONTROL_PLANE_MANIFEST_MISMATCH. Новые release envelopes также содержат отдельные resources inventories для assets и Java runtime. В strict production-режиме оба обязательны: до запуска scanner лаунчер сравнивает их id, полный file set, total size, SHA-256, категории и optional-флаги с ответом site API. Старые envelopes без resources допускаются только пока выключен enforceSignedReleases. После проверки envelope main process выбирает mirror с наименьшим priority и переводит build/assets/runtime resolver на подписанные URL https://cdn.wraithbound.com/launcher/.... Renderer не получает control-plane token или S3 credentials; native downloader видит только конечные HTTPS URL и ожидаемые SHA-256. Сайт по-прежнему отвечает за пользовательскую авторизацию и адрес выбранного Minecraft-сервера. Критичные для исполнения поля он получает возможность передать launcher только тогда, когда они совпадают с envelope, подписанным CI. Перед непосредственным запуском Minecraft release проверяется повторно. Если его отозвали, заблокировали или переключили после загрузки, ранее подготовленный клиент не запускается. Пользователь должен получить и проверить актуальный release заново. Public bootstrap control-plane загружается параллельно с профилем и каталогом серверов, пока открыт preload. Свежий результат переиспользуется не дольше 15 секунд, поэтому открытие сборки не создаёт лишний сетевой запрос. Эта оптимизация не применяется к последней проверке перед запуском Minecraft: она всегда принудительно запрашивает актуальный active release. После preload main process обновляет public catalog каждые 30 секунд и передаёт renderer только типизированный snapshot. Страница сервера реагирует на locked и отсутствие active release без исчезновения основного содержимого; временная недоступность control plane показывается отдельно и не подменяет обязательную main-process проверку собственной логикой renderer-а. Тот же snapshot поступает внутреннему main-process подписчику. Если уже проверенный release отозван, заблокирован или заменён, его identity удаляется из кэша, активный scanner/downloader отменяется, а готовая сборка переходит в понятное состояние ошибки. Сетевой сбой сам по себе кэш не отзывает: перед следующим запуском всё равно выполняется строгая принудительная проверка. Signed maintenance проверяется тем же trust root. Main process блокирует подготовку в install-disabled/full и запуск в launch-disabled/full для затронутых build id. Renderer получает только проверенный policy snapshot; full maintenance отображается обязательным окном и обновляется раз в 30 секунд. Правила обслуживания не зависят от Electron API: отдельный адаптер рассылает копии проверенного snapshot по renderer-окнам, а polling останавливается перед завершением приложения. Поэтому доменные ограничения проверяются тестами без запуска BrowserWindow и не оставляют timer после выхода. Окно подготовки остаётся модальным слоем поверх настоящей страницы выбранного сервера, поэтому фон не исчезает во время запросов. Transport errors, недоступный control plane, обслуживание, блокировка и отзыв release преобразуются в разные пользовательские состояния с повтором запроса; внутренние коды остаются в логах.

Локальные каталоги

{storageRoot}/
├── common/{profile.dir}/          # файлы Minecraft и сборки
├── runtimes/{runtime.id}/         # распакованный Java runtime
└── metadata/
    ├── {serverId}-{revision}.manifest.json
    ├── {serverId}-{revision}.download.json
    ├── {runtimeId}-{revision}.manifest.json
    ├── {runtimeId}-{revision}.download.json
    └── {serverId}-{revision}.guardian.json

По умолчанию {storageRoot} равен {userData}/storage. Пользователь может перенести весь корень на другой диск в настройках лаунчера; клиент, assets, Java runtime, manifests, download plans и Guardian policy переезжают вместе. Java хранится отдельно от клиента. Поэтому, например, Java 17 загружается один раз и повторно используется несколькими сборками. Перед каждым запуском её целостность всё равно проверяется по манифесту.

Подготовка файлов клиента

Правила берутся из profile.json:

Поле	Поведение
`update`	Файлы всегда входят в план повторной загрузки
`updateVerify`	Файлы проверяются по размеру и SHA-256
`updateExclusions`	Файлы исключаются из проверки, загрузки и удаления
`updateOptional`	Метаданные опциональных компонентов; отсутствующие optional-файлы допустимы

managed вычисляется как объединение update + updateVerify. Лишний файл может быть удалён только внутри управляемой области и только если он не попадает в preserve/exclusions. Пользовательские saves, screenshots, resourcepacks, shaderpacks, logs, crash-reports и options.txt сохраняются по умолчанию. В периодическую Guardian-проверку входят только файлы из updateVerify. Файлы только из update восстанавливаются перед запуском, но могут штатно изменяться во время игры. Весь Java runtime всегда защищён.

Подготовка Java

Версия runtime равна recommendJavaVersion. Сейчас поддерживается desktop цель win32-x64. Сканер проверяет весь runtime; downloader получает только отсутствующие или изменённые файлы. После загрузки выполняется повторная проверка. Запуск запрещается, если:

bin/javaw.exe или bin/java.exe отсутствует в runtime-манифесте;
SHA-256 javaw.exe не совпадает;
версия Java находится вне minJavaVersion..maxJavaVersion;
финальная проверка runtime не прошла.

warnMissJavaVersion не разрешает запуск неподходящей Java. Лаунчер сам загружает точную рекомендуемую версию, поэтому обычному пользователю не нужно устанавливать Java вручную.

Формирование classpath

Лаунчер объединяет classPath и altClassPath. Если элемент указывает на каталог, все .jar внутри него находятся рекурсивно и сортируются для детерминированного запуска. Если элемент указывает на файл, он добавляется напрямую. mainClass добавляется после -cp. Пустой classpath и некорректный Java class name приводят к отказу до запуска. compatClasses пока должны быть пустыми: их последовательный запуск требует отдельного Java bootstrap-класса. При непустом массиве возвращается COMPAT_CLASSES_REQUIRE_BOOTSTRAP.

JVM и Minecraft arguments

Лаунчер использует jvmArgs из профиля. Если -Xmx и -Xms не заданы, они вычисляются автоматически:

settings.ram > 0 — точное значение в мегабайтах;
settings.ram = 0 — 50% системной памяти, минимум 2048 МБ и максимум 8192 МБ.

Поддерживаются стандартные placeholders:

Placeholder	Значение
`${auth_player_name}`	username активной launcher-сессии
`${version_name}`	`profile.version`
`${game_directory}`	абсолютный каталог клиента
`${assets_root}`	каталог `profile.assetDir`
`${assets_index_name}`	`profile.assetIndex`
`${auth_uuid}`	UUID игрока без дефисов
`${auth_access_token}`	access token, только в динамических game arguments
`${natives_directory}`	каталог `natives` клиента

Лаунчер всегда передаёт Minecraft как минимум:

--username <username>
--version <profile.version>
--gameDir <clientRoot>
--assetsDir <assetDir>
--assetIndex <assetIndex>
--uuid <uuidWithoutDashes>
--accessToken <token>
--userType mojang
--versionType Wraithbound
--userProperties {}

Если settings.fullScreen = true, добавляется --fullscreen. Если settings.autoEnter = true, добавляются --server и --port из сервера с isDefault = true.

Access token никогда не записывается в Guardian policy, electron-store или debug console. ${auth_access_token} запрещён внутри jvmArgs; он разрешён только в динамических аргументах, передаваемых процессу в памяти.

Authlib

Custom authlib является библиотекой самой Minecraft-сборки и должна входить в её manifest/classpath. Лаунчер не подключает authlib через -javaagent и не подменяет её код. Он передаёт валидные username, UUID и access token, а библиотека обращается к Wraithbound authlib endpoint’ам самостоятельно. Это важно для Guardian: сторонние -javaagent, Attach API и инструментация запрещены, но обычная authlib-библиотека в доверенном classpath работает.

Автоматический запуск и состояния

Main-процесс владеет состоянием игры:

idle → preparing → launching → running → exited
                                  ↘ stopping
          любая ошибка → error

Renderer получает состояния через typed preload IPC и не запускает процессы самостоятельно. Повторный запуск блокируется, пока активна подготовка, Guardian или Minecraft. При hideDuringGame = true главное окно скрывается после события guardianStarted и возвращается после завершения процесса. Discord Presence переключается между downloading/launching/playing и возвращается к launcher.

Отмена и остановка

во время загрузки отменяется HTTP-запрос и активный Rust-процесс;
до старта Guardian выставляется флаг отмены, поэтому Java не запустится;
после старта завершается Guardian; Job Object завершает всё дерево Minecraft;
окно лаунчера восстанавливается независимо от exit code.

Ограничения текущей реализации

runtime target пока win32-x64;
compatClasses требуют будущий Java bootstrap;
authlib должна уже находиться в сборке;
реальный запуск возможен только после загрузки runtime и build manifests в S3.

Устройство

Игровой контур

Выпуск лаунчера

Подготовка и запуск Minecraft

Что возвращает API

Локальные каталоги

Подготовка файлов клиента

Подготовка Java

Формирование classpath

JVM и Minecraft arguments

Authlib

Автоматический запуск и состояния

Отмена и остановка

Ограничения текущей реализации

​Что возвращает API

​Локальные каталоги

​Подготовка файлов клиента

​Подготовка Java

​Формирование classpath

​JVM и Minecraft arguments

​Authlib

​Автоматический запуск и состояния

​Отмена и остановка

​Ограничения текущей реализации

Что возвращает API

Локальные каталоги

Подготовка файлов клиента

Подготовка Java

Формирование classpath

JVM и Minecraft arguments

Authlib

Автоматический запуск и состояния

Отмена и остановка

Ограничения текущей реализации