Как настроить лаунчер сашка

sashok724’s Launcher v15.4

Почти обогнали Firefox!

Разработка лаунчера была прекращена. Используйте один из поддерживаемых форков.

Основная информация

Лаунчер написан на Java 8 с использованием технологии JavaFX и Nashorn, за счёт чего обладает широкими возможностями кастомизации и безупречной производительностью. С помощью умной обвязки, Вы можете скачать клиенты и настроить сервера всего в несколько команд, не компилируя исходники и не меняя классы клиента!

Новый функционал можно добавить через JS API, возможно так же добавление функционала в стандартную конфигурацию по запросу.

Установка на VDS

Запустите скрипт установки в удобной для Вас директории (для работы скрипта нужен curl):

Запустите лаунчсервер как любое другое Java-приложение:

Для работы лаунчера и лаунчсервера нужна Java 8 и выше

Настройка LaunchServer.cfg

При первом запуске Вас попросят указать адрес VDS (IP или домен), на котором находится лаунчсервер — лаунчеры будут подключаться именно по этому адресу. После этого будет создан основной файл конфигурации — LaunchServer.cfg — в нём настраивается авторизация, обработка UUID, система скинов и сборка EXE-файла через Launch4J. Вы можете использовать локальный адрес для тестирования (localhost):

Способы авторизации (authProvider)

По умолчанию используется способ авторизации accept, который принимает любые пары логин-пароль за верные, и имя пользователя соответствует логину. Такой способ хорошо подходит для тестирования, но для использования в production рекомендуется сменить его на один из других: reject, file, request, или mysql. В отличие от accept, все эти способы требуют дополнительной конфигурации в блоке authProviderConfig:

Способ reject

Этот способ авторизации — полная противоположность accept — он принимает любые пары логин-пароль за неверные. Этот способ можно использовать во время проведения технических работ. Пример конфигурации:

Способ file

Для проверки правильности логина и пароля, этот способ обращается к указанному файлу. Этот способ рекомендуется для приватных серверов с небольшим количеством игроков. Пример конфигурации:

Способ request

Для проверки правильности логина и пароля, этот способ обращается к указанному URL. Этот способ рекомендуется для больших проектов с CMS, которые используют нестандартные алгоритмы хеширования. Пример конфигурации:

Вы можете загрузить уже готовые скрипты авторизации для WordPress, XenForo, IPB и PHPBB (Они должны находиться в корне сайта)

Способ mysql

Для проверки правильности логина и пароля, этот способ обращается к MySQL-базе данных. Этот способ рекомендуется для больших проектов со стандартными алгоритмами хеширования. Пример конфигурации (DLE):

Проверка авторизации

Проверить авторизацию можно с помощью команды auth:

Обработка UUID и авторизаций (authHandler)

Для управления авторизациями (joinServer, checkServer) и UUID игроков существуют несколько возможных обработчиков. Пока что их всего три, отличающихся только местом хранения: binaryFile, textFile и mysql.

Обработчик textFile

Этот обработчик хранит все данные об авторизациях в текстовом файле, генерирует случайные UUID, но есть опция для генерации UUID из MD5 имени пользователя. Этот обработчик рекомендуется использовать небольшим проектам. Пример конфигурации:

Обработчик binaryFile

Этот обработчик хранит все данные об авторизациях в бинарном файле, в остальном идентичен обработчику textFile. Этот обработчик существует для обратной совместимости и будет удалён в следующей версии.

Обработчик mysql

Этот обработчик хранит все данные об авторизациях в MySQL-базе данных, использует UUID готовые. Этот обработчик рекомендуется использовать всем проектам по мере возможности. Пример конфигурации:

Для того чтобы добавить недостающие поля и сгеренерировать UUID, можно использовать SQL-запрос:

Система скинов и плащей

Скины и плащи настраиваются всего двумя параметрами — маской URL на PNG-файл. Пример конфигурации:

%username%, %uuid%, %hash% заменяются на имя пользователя, UUID и UUID без тире соответственно

Не забудьте поменять textureProvider с mojang на request

Сборка EXE с помощью Launch4J

Лаунчсервер так же может автоматически собирать EXE из JAR-файла — для этого требуется поставить параметр launch4J на true. Для того чтобы у EXE-файла была иконка, положите файл favicon.ico рядом с лаунчсервером. Пример конфигурации:

В случае возникновения ошибок на 64-битных системах, может помочь установка 32-битного пакета glibc (Debian: lib32z1 | CentOS: glibc.i686).

Загрузка клиентов и настройка профилей

Клиенты, ресурсы и другие файлы для загрузки лаунчером хранятся в виде субдиректорий в директории updates, а профили, в которых указываются имя директорий, адрес сервера для автозахода, исключения при обновлении и другие сведения, необходимые для запуска клиента хранятся в директории profiles

Загрузка ресурсов

Для загрузки ресурсов существует команда downloadAsset. Первым аргументом передаётся версия клиента, для которого загружаются ресурсы, вторым аргументом имя субдиректории в updates:

Синхронизация (см. ниже) сделается автоматически, отдельно набирать команду не требуется

Загрузка клиентов

Для загрузки клиентов существует команда downloadClient. Первым аргументом передаётся версия клиента, вторым аргументом имя субдиректории в updates:

Эта команда так же автоматически создаст файл профиля в директории profiles. Пример файла profile.cfg:

Синхронизация (см. ниже) сделается автоматически, отдельно набирать команду не требуется

Синхронизация директорий updates и profiles

Для обеспечения высокой производительности, лаунчсервер кэширует содержимое директорий updates и profiles. При внесении изменений в эти директории, лаунчсервер о них не осведомлён, и при следующем обновлении скорее всего будет ошибка. Для того чтобы синхронизировать содержимое этих директорий, существует две команды — syncUpdates и syncProfiles:

Эти команды надо обязательно выполнять после изменений! Иначе у Вас и Ваших игроков будут ошибки при обновлениях!

Сборка и использование, настройка сервера

Перед сборкой рекомендуется настроить стандартный интерфейс лаунчера в файле runtime/config.js:

Настройки находятся только в этой части файла, остальная часть используется самим лаунчером и менять её не нужно!

Сборка лаунчера

Для сборки лаунчера существует команда build. Она автоматически упакует runtime, запишет Launcher.jar, соберёт Launcher.exe (если включена интеграция с Launch4J), и автоматически их синхронизирует. Данная команда используется после модификации директории runtime:

Сразу после сборки, лаунчер можно отправлять игрокам. Если сайт и лаунчсервер на одной VDS, можно сделать symlink на лаунчер с сайта:

Сборка сервера

На данный момент поддерживаются MCPC 1.5.2, Cauldron 1.6.4, Cauldron 1.7.2, KCauldron 1.7.10, Thermos 1.7.10, Spigot 1.8.8, Spigot 1.9.4, Spigot 1.10.2, Spigot 1.11.2, Spigot 1.12.2 и Sponge 1.12.2. Патчи на авторизацию в них уже добавлены, и всё, что Вам требуется сделать, это заменить Launcher.jar.

Сборка сервера BungeeCord

Доступны патченные серверы BungeeCord (1.8.9-1.13.2, #afef0ec), его legacy-версия (1.7.2-1.8.9, #219819b), Waterfall (1.8.9-1.13.2, #bea8aac), Waterfall-Old (1.7.2-1.9.4, #f62f290). Патчи на авторизацию в них уже добавлены, и всё, что Вам требуется сделать, это заменить Launcher.jar. Не забудьте включить ip-forwarding и bungeecord в файлах config.yml и spigot.yml, соответственно. На серверы, стоящие ЗА BungeeCord патчи НЕ ставятся и online-mode НЕ включается. Желательно поставить server-ip на localhost

Часто задаваемые вопросы (FAQ)

Q: Поддерживаются ли Послотовые/Игровые/Shared-хостинги?

A: Если на них можно запускать сторонние Java-приложения, то да, но найти такой Послотовый/Игровой/Shared-хостинг — большая удача. Лаунчер гарантированно поддерживает любые VDS и Dedicated-серверы с возможностью установки Java 8 и открытым 7240 портом.

Источник

KeeperJerry Mirror Launcher*

Зеркало переделанного лаунчера sashok724’s Launcher v15.4

* Официальным разработчиком лаунчера является sashok724

Актуальная версия переделанного лаунчера: 1.7.4.0

Документация скоро перейдет на другой домен! Этот будет как зеркало оригинального лаунчера!

Основная информация

Лаунчер написан на Java 8 с использованием технологии JavaFX, за счёт чего обладает широкими возможностями кастомизации, безупречной производительностью. С помощью умной обвязки, Вы можете скачать клиенты и настроить сервера всего в несколько команд, не компилируя исходники и не меняя классы клиента!

Новый функционал можно добавить через JS API, возможно так же добавление функционала в стандартную конфигурацию по запросу.

СИСЬКИ

А теперь, когда вы обратили внимание, стоит запомнить:

Для работы сервера лаунчера требуется OpenJDK 8 версии (не 9, не 10, не 11 и не даже 15, ТОЛЬКО 8)

НИКТО ВАМ НЕ БУДЕТ ПОМОГАТЬ С УСТАНОВКОЙ GRAVIT LAUNCHER’А НА НАШЕМ DISCORD СЕРВЕРЕ

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

Установка на VDS

Запустите скрипт установки в удобной для Вас директории (для работы скрипта нужен curl):

Запустите лаунчсервер как любое другое Java-приложение:

Для работы лаунчера и лаунчсервера нужна Java 8 и выше

Рекомендации

До этого я рекомендовал MineSocial.NET — мой сайт эмуляции сервисов Mojang. Вопреки всем ожиданиям, сервис начал набирать актуальность. Однако мне пришлось его увести на тех.работы (уйти от PHP, закончить realms и т.д.). Когда сервис будет готов — я оглашу это публично.

Особенности серверов (обновлено)

Я постарался, чтобы данный сервис максимально облегчил процесс установки серверов. Вручную привязать к сервису можно абсолютно любое ядро! (достаточно скачать authlib-injector). Далее, нужно просто положить его в папку с игровым сервером (допустим это будет paper.jar) и запустить следующую команду:

Так же, по такому же принципу можно привязать сервера к сервису Ely.By:

Данная система не должна вызвать каких-либо затруднений в привязке к системе. Authlib-injector автоматически пропатчит ваше ядро.

Настройка LaunchServer.cfg

При первом запуске Вас попросят указать адрес VDS (IP или домен), на котором находится лаунчсервер — лаунчеры будут подключаться именно по этому адресу. После этого будет создан основной файл конфигурации — LaunchServer.cfg — в нём настраивается авторизация, обработка UUID, система скинов и сборка EXE-файла через Launch4J. Вы можете использовать локальный адрес для тестирования (localhost):

Проверка актуальных обновлений

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

Выбор зеркала

В свете последних событий, сашок уже не один раз забил на web-сервер своего лаунчера. Поэтому было принято решение добавить в лаунчер выбор и возможность поднять свое зеркало. Чтобы его поднять — необходимо создать директории assets и clients в целевой папке. До версии 1.7.0.0+ можно было указать только одну ссылку!

Так же, вы можете найти прочие (неофициальные) зеркала на нашем дискорд канале. Учтите, что разработчик данного форка не несет ответственность за другие зеркала!

Лимит на авторизацию и ограничения по IP (+1.7.4.0)

Данная функция частично разгружает сервер авторизации, защищая его от подбора паролей. С версии 1.7.3.0 данный функционал был переписан под управления IP. Пока что основной функционал работает только после перезагрузки LaunchServer’a.

Так же, стоит отметить, что с версии 1.7.4.0 в лаунчере присутствует файл ListIpConnection.json, который хранит в себе белый список (allowIp) и черный список (blockIp). Выглядит он так:

Белый список (allowIp) предназначен для игровых серверов, чтобы не попадать под проверку (authRateLimit) и не ждать окончания лимита. Черный список (blockIp) предназначен для блоировки IP нежелательных пользователей.

В новой системе динамической подгрузки были добавлены команды для операциями с IP адресами:

P.S. НЕ НАДО РУКАМИ СТАВИТЬ IP АДРЕСА БЕЗ ПЕРЕЗАГРУЗКИ И ГОВОРИТЬ МНЕ, ЧТО ОНО НЕ РАБОТАЕТ

Параметр blockOnConnect позволяет управлять подключением с заблокированными IP адресами: если установлено значение false — клиенты увидят сообщение о том, что их IP забанен, если установлено значение true — заблокированные адреса не смогут вовсе подключится к вашему LaunchServer’у, просто отклоняя любое соединение с указанными IP.

Параметр onlyAllowIp позволяет настроить подключение только для IP, которые указанны в белом списке (allowIp), так что не забудьте включить его!

Способы авторизации (authProvider)

По умолчанию используется способ авторизации accept, который принимает любые пары логин-пароль за верные, и имя пользователя соответствует логину. Такой способ хорошо подходит для тестирования, но для использования в production рекомендуется сменить его на один из других: reject, file, request, или mysql. В отличие от accept, все эти способы требуют дополнительной конфигурации в блоке authProviderConfig:

Способ reject

Этот способ авторизации — полная противоположность accept — он принимает любые пары логин-пароль за неверные. Этот способ можно использовать во время проведения технических работ. Пример конфигурации:

Способ mojang

Для того, чтобы авторизовать пользователя, LaunchServer берет данные с официального сервера Mojang. Пример конфигурации:

Способ minesocial (+1.7.3.1) [Временно отключен]

Этот способ рекомендуется для приватных серверов с небольшим количеством игроков. Пример конфигурации:

Способ elyby (+1.7.4.0)

Я хз нужно ли вообще кому нидубь кроме TLauncher’a, но раз попросили сделать из коробки — значит нужен. Пример конфигурации:

Чтобы пользоваться данной авторизацией, необходимо зарегестрироваться на сайте Ely.by! Я не уверен, сливают они данные или нет, поэтому сделал свой сервис.

Способ authlib (+1.7.2.3)

Способ аналогичен Mojang, за исключением того, что все запросы LaunchServer берет из вашего эмулятора MojangAPI. Документация: authUrl. Пример конфигурации:

Способ file

Для проверки правильности логина и пароля, этот способ обращается к указанному файлу. Пример конфигурации:

Пример файла авторизации

Пример демонстрационного файла users.cfg в формате plain (без хеша)

Пример демонстрационного файла users.cfg в формате MD5

Я надеюсь как применять остальные хеши обьяснять не надо.

Способ request

ДА НЕ ИСПОЛЬЗУЙТЕ ВЫ ЕГО ДЛЯ DLE! ХВАТИТ СЛУШАТЬ ДОЛБАЕБОВ С ЮТУБА! ИСПОЛЬЗУЙТЕ ГОТОВЫЙ СПОСОБ mysql-bcrypt

Для проверки правильности логина и пароля, этот способ обращается к указанному URL. Этот способ рекомендуется для больших проектов с CMS, которые используют нестандартные алгоритмы хеширования. Пример конфигурации:

Вы можете загрузить уже готовые скрипты авторизации для DLE, WordPress, XenForo, IPB и PHPBB (Они должны находиться в корне сайта)

Способ mysql / mariadb (DLE ДО v11.1)

Для проверки правильности логина и пароля, этот способ обращается к MySQL-базе данных. Этот способ рекомендуется для больших проектов со стандартными алгоритмами хеширования. Пример конфигурации (DLE до 11.1):

Способ mysql-8 (DLE ДО v11.1) (+1.6.2.0)

Для проверки правильности логина и пароля, этот способ обращается к MySQL-базе данных. Этот способ рекомендуется для больших проектов со стандартными алгоритмами хеширования. Пример конфигурации (DLE до 11.1):

Способ mysql-bcrypt / mariadb-bcrypt (DLE ОТ 11.2) (+1.2.0.0)

Для проверки правильности логина и пароля, этот способ обращается к MySQL-базе данных и сравнивает hash пароля. Этот способ рекомендуется для больших проектов с алгоритмом хеширования BCrypt. Пример конфигурации (DLE от 11.2):

Способ mysql-8-bcrypt (DLE ОТ 11.2) (+1.6.2.0)

Для проверки правильности логина и пароля, этот способ обращается к MySQL-базе данных и сравнивает hash пароля. Этот способ рекомендуется для больших проектов с алгоритмом хеширования BCrypt. Пример конфигурации (DLE от 11.2):

Способ sqlite (+1.6.0.0)

Для проверки правильности логина и пароля, этот способ обращается к SQLite-базе данных. Этот способ рекомендуется для администраторов с психическими отклонениями. Пример конфигурации:

Способ postgresql (+1.5.0.0)

Для проверки правильности логина и пароля, этот способ обращается к PostgreSQL-базе данных. Этот способ рекомендуется для больших проектов. Пример конфигурации:

Способ json (+1.5.0.0)

Для проверки правильности логина и пароля, этот способ обращается по URL с передачей POST. Я вообще не рекомендую данный способ, если вы не используете headless cms.
Пример конфигурации:

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

Проверка авторизации

Проверить авторизацию можно с помощью команды auth:

Обработка UUID и авторизаций (authHandler)

Для управления авторизациями (joinServer, checkServer) и UUID игроков существуют несколько возможных обработчиков. Пока что их всего три, отличающихся только местом хранения: binaryFile, textFile и mysql.

Обработчик mojang (+1.7.3.1)

Для того, чтобы получить необходимые данные пользователя, LaunchServer берет данные с официального сервера Mojang. Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/mojang!

Обработчик minesocial (+1.7.3.1) [Временно отключен]

LaunchServer берет данные с сервера MineSocial.NET. Этот обработчик рекомендуется использовать небольшим проектам, т.к. весь процесс автоматизирован. Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/minesocial!

Обработчик elyby (+1.7.4.0)

LaunchServer берет данные с сервера Ely.by. Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/elyby!

Обработчик authlib (+1.7.3.1)

Способ аналогичен Mojang, за исключением того, что все запросы LaunchServer берет из вашего эмулятора MojangAPI. Документация: joinUrl, hasJoinUrl (+1.7.3.2). Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/authlib!

Обработчик textFile

Этот обработчик хранит все данные об авторизациях в текстовом файле, генерирует случайные UUID, но есть опция для генерации UUID из MD5 имени пользователя. Пример конфигурации:

Обработчик binaryFile

Этот обработчик хранит все данные об авторизациях в бинарном файле, в остальном идентичен обработчику textFile. Этот обработчик существует для обратной совместимости и будет удалён в следующей версии.

Обработчик mysql / mariadb

Этот обработчик хранит все данные об авторизациях в MySQL-базе данных, использует UUID готовые. Этот обработчик рекомендуется использовать всем проектам по мере возможности. Пример конфигурации:

Для того чтобы добавить недостающие поля и сгеренерировать UUID, можно использовать SQL-запрос:

Обработчик mysql-8 (+1.6.2.0)

Этот обработчик хранит все данные об авторизациях в MySQL-базе данных, использует UUID готовые. Этот обработчик рекомендуется использовать всем проектам по мере возможности. Пример конфигурации:

Обработчик sqlite (+1.6.0.0)

Этот обработчик хранит все данные об авторизациях в SQLite-базе данных, использует UUID готовые. Этот обработчик рекомендуется использовать администраторам проектов с психическими отклонениями. Пример конфигурации:

Обработчик postgresql (+1.5.0.0)

Этот обработчик хранит все данные об авторизациях в PostgreSQL-базе данных, использует UUID готовые. Этот обработчик рекомендуется использовать всем проектам по мере возможности. Пример конфигурации:

Способ json (+1.5.0.0)

Этот обработчик хранит все данные об авторизациях в указанной вами базе данных, к которой идет подключение

Сорян, но я это еще делаю.

Система скинов и плащей

Обработчик void

Скины и плащи полностью отключены. Пример конфигурации:

Обработчик mojang

Скины и плащи LaunchServer берет с официального сервера Mojang. Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/mojang и authHandler/mojang!

Обработчик minesocial (+1.7.3.1) [Временно отключен]

Скины и плащи LaunchServer берет с cервера MineSocial.NET. Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/minesocial и authHandler/minesocial!

Обработчик elyby (+1.7.4.0)

Скины и плащи LaunchServer берет с cервера Ely.by. Пример конфигурации:

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

Обработчик authlib (+1.7.2.3)

Скины и плащи LaunchServer берет из вашего эмулятора MojangAPI. Документацию можно найти здесь: usersURL, profileURL. Пример конфигурации:

Для правильной работоспособности, данный способ необходимо использовать в связке с authProvider/authlib и authHandler/authlib!

Обработчик request

Скины и плащи настраиваются всего двумя параметрами — маской URL на PNG-файл. Пример конфигурации:

%username%, %uuid%, %hash% заменяются на имя пользователя, UUID и UUID без тире соответственно.

Сборка EXE с помощью Launch4J (+1.6.1.0)

Лаунчсервер так же может автоматически собирать EXE из JAR-файла — для этого требуется поставить параметр launch4J на true. Для того чтобы у EXE-файла была иконка, положите файл favicon.ico в корневую папку, где находится LaunchServer. Пример конфигурации:

В случае возникновения ошибок на 64-битных системах, может помочь установка 32-битного пакета glibc (Debian: lib32z1 | CentOS: glibc.i686).

Загрузка клиентов и настройка профилей

Клиенты, ресурсы и другие файлы для загрузки лаунчером хранятся в виде субдиректорий в директории updates, а профили, в которых указываются имя директорий, адрес сервера для автозахода, исключения при обновлении и другие сведения, необходимые для запуска клиента хранятся в директории profiles

Загрузка ресурсов

Для загрузки ресурсов существует команда downloadAsset. Первым аргументом передаётся версия клиента, для которого загружаются ресурсы, вторым аргументом имя субдиректории в updates:

Синхронизация (см. ниже) сделается автоматически, отдельно набирать команду не требуется

Загрузка клиентов

Для загрузки клиентов существует команда downloadClient. Первым аргументом передаётся версия клиента, вторым аргументом имя субдиректории в updates:

Обновление 1.7.0.0+

В данном обновлении была измена функция скачки клиентов: теперь все .cfg файлы скачиваются с зеркала сайта. Так же, сборки разделены на категории через разделитель «-» (тире).

Эти команды так же автоматически сделают файл профиля в директории profiles. Пример файла profile.cfg:

Синхронизация (см. ниже) сделается автоматически, отдельно набирать команду не требуется

Синхронизация директорий updates и profiles

Для обеспечения высокой производительности, лаунчсервер кэширует содержимое директорий updates и profiles. При внесении изменений в эти директории, лаунчсервер о них не осведомлён, и при следующем обновлении скорее всего будет ошибка. Для того чтобы синхронизировать содержимое этих директорий, существует две команды — syncUpdates и syncProfiles:

Эти команды надо обязательно выполнять после изменений! Иначе у Вас и Ваших игроков будут ошибки при обновлениях!

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

Обработчик accept

Отключает данную систему и не ведет учет железа игроков

Сборка и использование, настройка сервера

Перед сборкой рекомендуется настроить стандартный интерфейс лаунчера в файле runtime/config.js:

Настройки находятся только в этой части файла, остальная часть используется самим лаунчером и менять её не нужно!

Сборка лаунчера

Для сборки лаунчера существует команда build. Она автоматически упакует runtime, запишет Launcher.jar, соберёт Launcher.exe (если включена интеграция с Launch4J), и автоматически их синхронизирует. Данная команда используется после модификации директории runtime:

Сразу после сборки, лаунчер можно отправлять игрокам. Если сайт и лаунчсервер на одной VDS, можно сделать symlink на лаунчер с сайта:

Сборка сервера

На данный момент поддерживаются MCPC 1.5.2, Cauldron 1.6.4, Cauldron 1.7.2, KCauldron 1.7.10, Thermos 1.7.10, Spigot 1.8.8, Spigot 1.9.4, Spigot 1.10.2, Spigot 1.11.2, Spigot 1.12.2 и PaperSpigot 1.15.2. Патчи на авторизацию в них уже добавлены, и всё, что Вам требуется сделать, это заменить Launcher.jar. Если вы не можете найти нужное ядро — посмотрите на зеркале, возможно там вы найдете нужную сборку.

Сборка сервера BungeeCord

Доступны патченные серверы BungeeCord (1.8.9-1.12.2, #8d49424), его legacy-версия (1.7.2-1.8.9, #219819b), Waterfall (1.8.9-1.12.2, #4c87152), Waterfall-Old (1.7.2-1.9.4, #f62f290). Патчи на авторизацию в них уже добавлены, и всё, что Вам требуется сделать, это заменить Launcher.jar. Не забудьте включить ip-forwarding и bungeecord в файлах config.yml и spigot.yml, соответственно. На серверы, стоящие ЗА BungeeCord патчи НЕ ставятся и online-mode НЕ включается. Желательно поставить server-ip на localhost

Часто задаваемые вопросы (FAQ)

Q: Сколько стоит лаунчер? Как мне его купить? Будет ли техподдержка?

A: Этот лаунчер — OpenSource проект, соответственно, Вы можете скачивать, использовать и распространять его бесплатно. Но техническую поддержку по вопросам установки и настройки лаунчера от разработчика можно написать автору зеркала. Напишите разработчику для получения всех необходимых инструкций. Приблизительное время работы техподдержки: 9:00-23:00 по московскому времени. VK: keeperjerry.

Q: У кого можно заказать вёрстку дизайна?

A: Есть достаточно много людей, которые за довольно скромную плату сверстают дизайн. Можно заказать вёрстку напрямую у разработчика, но стоить это будет дороже (в цену входит адаптация на последующие версии лаунчера, исправление недочётов и расширенная поддержка).

Q: Возможно ли добавление недостающего функционала в лаунчер?

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

Q: Поддерживаются ли Послотовые/Игровые/Shared-хостинги?

A: Если на них можно запускать сторонние Java-приложения, то да, но найти такой Послотовый/Игровой/Shared-хостинг — большая удача. Лаунчер гарантированно поддерживает любые VDS и Dedicated-серверы с возможностью установки Java 8 и открытым 7240 портом.

Источник