Эмулятор
Сборки L2J: что внутри
Слово «сборка» в разговорах про L2J значит сразу три разные вещи: репозиторий с кодом, конкретную его ревизию и архив, который кто-то выложил на форум. Путаница между ними — причина половины неработающих серверов.
Ядро и датапак
L2J исторически разделён на две части, и это разделение видно в любом форке.
- Ядро — собственно серверный код на Java: сеть, протокол, игровой цикл, движок навыков и предметов. Два процесса, логин-сервер и игровой сервер, собираются отсюда.
- Датапак — содержимое мира: XML с описаниями предметов, навыков, мобов, зон, SQL-дампы таблиц, скрипты квестов и инстансов, конфигурационные файлы.
Практический смысл разделения такой: 90% того, что обычно хочет поменять владелец сервера, лежит в датапаке, а не в ядре. Шанс заточки, состав дропа, награда за квест, рейты — это XML и конфиги. Трогать Java приходится, когда нужна механика, которой в игре нет вообще.
В части форков ядро и датапак лежат в одном репозитории, в части — в двух. На устройство это не влияет, но влияет на обновление: две отдельные истории изменений обновляются независимо, и рассогласовать их проще, чем кажется.
Форки и ревизии
Единого «L2J» давно нет. Есть исходный проект и десятки ответвлений: кто-то отделился ради конкретной хроники, кто-то ради другой архитектуры, кто-то потому что не сошёлся с остальными в том, как считать урон. Называть «правильный» форк мы не будем — список живых меняется быстрее, чем обновляется справочная страница.
Выбирать форк стоит по трём признакам, и все они проверяются за десять минут:
- Ваша хроника поддерживается в основной ветке, а не в чьём-то заброшенном ответвлении.
- Коммиты есть за последние месяцы. Мёртвый форк означает, что все ошибки в нём вы будете править сами.
- Есть место, где отвечают на вопросы. Трекер, форум, чат — что угодно живое.
Ревизия — номер конкретного состояния репозитория. Когда в объявлении сборки пишут «rev 1234», имеют в виду именно это. Для вас ревизия важна по одной причине: правки, написанные под одну ревизию, на другую могут не встать, и чем больше разрыв, тем вероятнее конфликт.
Готовый архив или сборка из исходников
Разница не в сложности, а в том, знаете ли вы, что у вас внутри.
Готовый архив — это чьи-то скомпилированные файлы плюс чей-то датапак, уже правленый неизвестным образом. Запускается быстрее. Дальше начинаются вопросы: какая это ревизия, что в ней изменено, почему вот эта механика ведёт себя не как в документации. Ответов нет, потому что сравнивать не с чем.
Сборка из исходников — клонировать репозиторий, собрать, получить те же файлы, но со знанием, из чего они получились. Нужен JDK и сборочный инструмент: у разных форков это Ant, Maven или Gradle, смотреть надо в их собственную инструкцию. Версия Java тоже зависит от форка: старые ревизии под старые хроники собираются только на Java 8, свежие требуют заметно новее.
Для первого локального запуска годится и архив. Для сервера, который вы собираетесь держать и править, — только исходники.
Про «паблик-сборки» и бэкдоры
Это не страшилка, а самая обычная история на частных серверах. Сборка выкладывается на форум или файлообменник, в неё добавлен код, который даёт автору доступ к серверу: админская команда под чужим именем, скрытый аккаунт, выдача предметов по внешнему запросу. Владелец узнаёт об этом, когда у игроков уже появились вещи из ниоткуда.
Защита тут простая и работает только целиком:
- Брать код из репозитория проекта, а не архивом по ссылке.
- Сторонние правки ставить по одной, патчем, который можно прочитать, — а не папкой «заменить всё».
- Смотреть, что вообще слушает порты на машине с сервером, и держать открытыми только нужные.
- Не держать базу доступной извне. Ей достаточно локального доступа.
Отдельно: админский аккаунт из комплекта сборки нужно переименовать и сменить ему пароль до того, как сервер станет доступен снаружи. Логин и пароль по умолчанию знают все, кто читал ту же инструкцию, что и вы.