- Новый пакет LOD_REGION: сервер отдаёт участок дальнего вида — сетку высот
и цветов, по одной пробе каждые 4 блока.
- LodGenerator на сервере считает участки от начала мира, держит их в
памяти и пишет на диск рядом с миром, чтобы считать один раз.
- Клиент строит из участка сетку и рисует своим шейдером (#version 330) до
обычных чанков: чанки ближе и подробнее, поэтому закрывают дальний вид.
- Дальний вид приходит по мере того, как игрок ходит по миру: сервер шлёт
участки вокруг него раз в тик.
Проверки в сервере 96, в протоколе 24, в клиенте 128.
Аутентификация переделана по схеме пользователя: лаунчер — единственный
источник токена, сервер проверяет его сам и лаунчера не спрашивает.
- rsx-auth/GameToken: токен это base64url(payload) + "." + base64url(HMAC-SHA256),
payload {uuid, nick, aud, exp, jti, typ}, typ = session или reload.
- Сессия живёт час, reload-токен полтора часа и только внутри игры. Пакет
SessionReload продлевает сессию и выдаёт новый reload-токен.
- Сервер проверяет подпись, аудиенс, срок и совпадение uuid. HTTP-запрос к
лаунчеру из сервера убран.
- Клиент: окно пароля убрано совсем, ник берётся из токена, клиент сам
продлевает сессию за 5 минут до конца.
- Для локальной разработки сервер с --dev-token пишет свой токен в
world/dev-token.txt, клиент берёт токен оттуда.
- Права админа: свой список world/admins.txt, перечитывается раз в 5 секунд,
поэтому право снимается на лету. Пакет AdminState.
- Ванильные блоки мира ломает только админ, режим игры прав не даёт.
- F3+B только для админов: без прав показываем отказ, с правом включаются и
ванильные хитбоксы, и наш отладочный рендер. Права сняли посреди просмотра —
гаснут сразу.
- run-game.ps1 умеет -Token.
Проверено на живом сервере: own session ok, player in, rights of Player given.
Тесты: протокол 34, сервер 88, форк собирается чисто.
- Протокол: Chat (что сказал сервер), ChatSend (что сказал клиент) и PlayerList
(весь список игроков с их режимами).
- Сервер: сообщения уходят всем, а имя отправителя ставит сервер, поэтому подделать
его нельзя. Список игроков уходит всем целиком, когда он меняется. Команды
сервера: /help и /players.
- Клиент: перевод наших пакетов в игровые (SPacketChat и SPacketPlayerListItem),
уходящий чат перехватывается патчем, список игроков обновляется по разнице
(ушедших убираем, пришедших добавляем).
- Тесты: два игрока, один пишет - второй слышит с правильным именем; список
игроков приходит обоим и меняется, когда кто-то выходит.
Попутно: run-server.ps1 теперь знает про rsx-plugin-api, иначе сервер не
запускался (нет класса Hitboxes в classpath).
Тесты: протокол 34, сервер 87. Форк собирается чисто.
- В реестр заведены 46 предметов одежды ремейка: слот, слой, какие части тела
закрывает и сколько снимает из каждого вида вреда. Данные выгружены в items.csv
(extract-items.py), в коде у каждого предмета armor(...).
- Семь мест: голова, лицо, грудь (2 слоя), ноги (2 слоя), руки, стопы, полный
костюм. Пояс не делали - в ремейке его нет, есть только быстрая панель.
- Inventory сервера: семь мест по два слоя, вещи надеваются и снимаются.
- Damage: зона урона по точке попадания (голова верхние 0.4, ноги нижние 0.4),
множители голова 2, тело 1, ноги 0.75; одежда снимает вред только там, где
закрывает.
- Пакет Attack (цель, точка попадания, рука) и клиентский патч, который его
шлёт. У игрока появилась жизнь.
- В items.csv добавлены колонки armor_slot, armor_layer, armor_zones.
Тесты: протокол 24 + 10, сервер 85. Форк собирается чисто, 3279 классов.
- RsxPlayerTuning: высота при подкрадывании 1.45 (ванилла 1.65), прыжок с
места 1.5, в движении ванильные 1.25, высота глаз в шифте 1.37.
- RsxPlayer: прыжок по наличию горизонтального ввода, глаза при подкрадывании.
- Патч в EntityPlayer.updateSize: высота при подкрадывании из нашего класса.
- Импульс прыжка считается обратным счетом по физике ваниллы.
AABB: редактор хитбоксов и их отрисовка
- Протокол: Hitbox (имя, зона, min/max, поворот), пакеты Hitboxes,
HitboxInstances и HitboxesReload.
- Сервер: HitboxRegistry читает JSON-файл (world/hitboxes.json, можно
указать --hitboxes), перечитывает его по запросу клиента и шлет наборы
игрокам. Сломанный файл не стирает рабочие коробки, а объясняет причину.
- Клиент: RsxHitboxDebug рисует коробки через RenderGlobal.drawBoundingBox
с подписями DebugRenderer, красит зоны (голова красная, тело желтое, ноги
синие). Команды: /rsx hitboxes on|off|reload|list|show NAME.
- Новый модуль rsx-plugin-api с интерфейсом Hitboxes: плагин может
зарегистрировать свои коробки. У сервера появился скрипт сборки.
Тесты: протокол 34, сервер 80 (было 74). Форк собирается чисто, 3279 классов.
Формула v = 0.42 * sqrt(h / 1.25) давала 1.48 вместо 1.5, потому что движение
каждый тик теряет часть на сопротивление воздуха. Теперь высота находится
обратным счетом по физике ваниллы (гравитация 0.08, сопротивление 0.98).
Высота -> импульс: 1.25 -> 0.41961, 1.35 -> 0.43713, 1.5 -> 0.46341,
1.6 -> 0.48093, 2.0 -> 0.54485.
Задаётся: run-game.ps1 -ExtraArgs "-Drsx.jumpHeight=1.5"
Игрок:
- RsxPlayer extends EntityPlayerSP: наш игрок с нашими числами движения.
- RsxMovementInput extends MovementInputFromOptions: отменяет ванильный
множитель подкрадывания 0.3 и ставит наш.
- RsxPlayerTuning: подкрадывание 1.5 блока/с (было ~1.3), прыжок 1.35 блока
(было 1.25). Прыжок считается по высоте: v = 0.42 * sqrt(h / 1.25) = 0.43713.
Правило пользователя: значение меньше заданного не принимается, остаётся 1.5.
Переопределяется из командной строки: -Drsx.sneakSpeed, -Drsx.jumpHeight.
- Мобы прыгают как в ванилле: переопределение в RsxPlayer, а не в
EntityLivingBase.
- Три строки патчей в ванильное дерево: PlayerControllerMP создаёт RsxPlayer,
Minecraft создаёт RsxMovementInput. Вся логика в нашем коде.
- Форк собирается чисто, 3278 классов.
Каталог:
- tools/catalog-remake.py собирает assets/rustex/CATALOG.md и catalog.json.
- Что нашли у ремейка: 218 предметов (46 одежды, 44 ресурса, 33 оружия, 31
медицина, 21 инструмент, 17 построек, 11 боеприпасов, 11 разных, 4 ловушки),
91 объект nextgen (бочки, ящики, двери, верстаки, печи, руда, модели
монументов), 553 модели .obj (384 оружия с перезарядкой, 128 деталей постройки,
36 мебели, 4 руды), 133 иконки предметов, 2004 звука, текстуры монументов и
животных, скины игрока (9 файлов 256x256 плюс 9 с моргающими глазами) в
assets/rustex/player/.
- Скины игрока - текстуры ремейка, модель тела ванильная.
Декомпил ремейка лежит на диске: G:\src-decoded (5207 файлов, строки
расшифрованы). Поведение клиента можно читать, а не угадывать: конфиг оружия с
отдачей, схема viewmodel, формат данных. Значения же приходят с сервера, в
клиенте только схема и значения по умолчанию.
План дополнен разделами 2.8 (игрок) и 2.9 (декомпил).
Пункт ноль плана: клиент теперь просит контекст 3.3 в режиме
совместимости, а не тот, что выпадал по умолчанию.
Зачем: дальний вид будет писаться шейдером GLSL 330, и контекст должен
гарантированно быть не ниже 3.3. В профиле совместимости работают и
шейдеры игры (#version 120, их 34 штуки), и наши 330-е. LWJGL 2.9.4 выше
3.3 контекст не заказывает - ограничение в его конструкторе, а не в
драйвере. Драйвер при этом дает 4.6, и расширение GL_EXT_gpu_shader4,
которое просит FXAA-шейдер игры, в этом контексте на месте.
Замер кадров теперь пишется в лог каждую секунду: средний, медиана,
1% и 0.1% low. Одного среднего мало: клиент, который идет со 60
кадрами и дважды в секунду проваливается в 10, в среднем остается 60 и
ощущается как slideshow. Медленные кадры - это то, что чувствует
игрок, поэтому окно держит все времена кадров и говорит про хвост.
Среднее и процентили видны и в HUD, так что их не надо вылавливать из
скриншотов.
Замер: 307 fps | med 2.9 ms | 1% 6.0 ms | 0.1% 18.1 ms.
Статтеры были не на сервере, а в клиенте, и стоили дорого.
Измерено: перевод чанка в игровой формат шел через setBlockState, а он
каждый раз обновляет карту высот и карту света. Чанк стоил 10-156 мс на
главном потоке, их было 208, и переход через границу чанка упирался в
325 мс за один тик.
Сделано:
- Секции чанка пишутся прямо в формате игры. Палитра и упакованные
индексы строятся игровым же классом, так что формат совпадает по
определению, а заливка по блокам и карты высот и света не нужны.
Чанк подешевел с 25 мс до 1-2 мс, это в 15-25 раз.
- Обработка входящих пакетов ограничена тремя миллисекундами на тик.
Колонка чанков, пришедшая за один раз, теперь размазывается по тикам:
не влезшее ждет следующего, это 0.2 секунды, и глазом не видно.
- Сгенерированный чанк больше не считается грязным. Террейн есть чистая
функция от зерна и координат, он и так восстановится за пару
миллисекунд, а писать его стоило 64 килобайта на чанк. Ходьба по миру
больше не гоняет двадцать мегабайт по диску. На диск пишется только то,
во что игрок построился.
Проверено: 169 чанков при заходе, медленных (больше 4 мс) три, остальные
быстрее; на диске ноль файлов, потому что игрок ничего не строил.
Раньше клиент умел только показывать меню. Теперь он заходит на сервер,
получает наш мир и рисует его.
Как это устроено:
- Наш сетевой слой (net/rustnotmc/client/net) читает наш протокол и
переводит его пакеты в пакеты игры. Игра остаётся игрой: у неё есть
мир, игрок, сущности и рендер, и все они работают. Не переписывать их
ради того, чтобы нарисовать тот же мир иначе, незачем.
- Пакеты игры, которые не имеют соответствия у нас, не отправляются, а
наоборот: перемещение игрока и ломание блока переводятся в наши.
- Экран входа игры (GuiConnecting) заменён наш: он спрашивает у лаунчера,
кем пришёл игрок, и подставляет это в рукопожатие.
- Соединение качается из тика игры, а не из экрана. Рукопожатие, которое
зависит от того, что экран ещё на экране, ломается alt-tab'ом.
Вход теперь через лаунчер, а не внутри игры:
- Лаунчер уже умеет логинить игрока и отдаёт игре имя, uuid и токен
(--username, --uuid, --accessToken). Это та же роль, что у Yggdrasil в
ванилле, только лаунчер наш.
- Сервер спрашивает лаунчер, один из ли наш этот игрок, и заодно получает
бан-лист. Токен используется один раз и не хранится.
- Свои аккаунты сервера, когда настроен лаунчер, закрыты: сервер с двумя
дверями не имеет дверей. Открыть их можно флагом, но намеренно.
- Если игру запустили без лаунчера, экран всё равно спрашивает имя и
пароль: это путь для своего сервера и для разработки.
Проверено живьём: клиент вошёл по токену лаунчера, сервер спросил
лаунчер, лаунчер сказал "свой", игрок получил мир, 210 чанков пришли и
лежат на диске, рельеф нарисован.
Что чинилось по дороге:
- Minecraft.setIngameFocus() возвращал на главное меню, когда окно
получало фокус. Игрок как раз кликает в окно, чтобы напечатать пароль, и
экран входа исчезал в этот самый момент.
- Ответ лаунчера разбирается, а не ищется подстрокой: {"valid": true} и
{"valid":true} это один и тот же ответ, и сервер, который понимает
только второй, ломает работающий лаунчер.
Тик. Моды тикали из покадрового хука, то есть получали столько тиков,
сколько кадров успевает нарисовать машина. На 200 fps это в семь раз
быстрее игры: таймер мода уезжал, а счётчик тиков модов расходился с
миром, поверх которого он нарисован. Теперь тик вызывается рядом с
runTick(), внутри того же цикла, так что у мода ровно двадцать шагов в
секунду независимо от частоты кадров.
HUD. Экран загрузки мира рисует сам, мимо хвоста кадра. Пока генерируется
ландшафт, LoadingScreenRenderer рисует в собственный framebuffer, блитит
его в окно и сам вызывает updateDisplay() — до десяти раз в секунду, из
потока, который занят генерацией. Всё, что нарисовано из покадрового хука,
стирается следующим таким выводом, поэтому оверлей пропадал на всю
загрузку и возвращался уже в мире. Добавлен отдельный вход в тот же код
рисования оверлеев, вызываемый после блита и до вывода в окно.
Заодно разделены две ошибки в RsxBootstrap: сбой тика и сбой отрисовки
больше не выключают друг друга, у каждого своя защита.
Проверено вживую: оверлей виден на экране генерации ландшафта.
struct_diff сравнивает классы по составу и показывает, каких не хватает.
Но он отвечает на вопрос «того же ли набора методов», а не «тот ли код».
Оба вопроса приходится задавать: прыжки и звуки шагов были сломаны именно
кодом, который компилировался без ошибок и состоял из правильных методов.
javap_diff сравнивает инструкции построчно, вызывая javap на обоих деревьях
классификации. Наивное сравнение текста здесь бесполезно: перекомпиляция
перенумеровывает constant pool, поэтому почти каждая строка отличается
номером #123, хотя код совпадает. Инструмент убирает номера пула, сдвиги
смещений от ldc/ldc_w и форму инструкций, после чего остаётся реальная
разница.
На звуке инструмент показал, что все аудио-классы совпадают с оригиналом.
Остатки объясняются версией компилятора, а не правками: javac 8 собирает
конкатенацию строк через StringBuilder, javac 17 через invokedynamic, а
$values() у enum появился в более новых версиях.
ogg_duration читает частоту дискретизации из заголовка Vorbis и число
отсчётов из granule position последней страницы OggS. Отсюда видно, что файл
сам по себе короче или что его просто обрывают при воспроизведении, —
вопрос, который иначе приходится решать на слух.
Проверено, что все 1085 ogg совпадают с индексом по SHA-1.
Клиент запрашивал звук, движок его принимал и запускал, а на выходе было
тихо. Причина оказалась не в коде игры.
Minecraft 1.12.2 не умеет читать ассеты по индексу и объектному хранилищу.
Он ждёт обычное дерево: <assetsDir>/minecraft/<путь>. А лаунчер хранит
ассеты по-современному — indexes/1.12.json со ссылками на objects/<aa>/<sha1>.
Мы передавали лаунчеру корень этого хранилища как --assetsDir. Игре это не
выглядит как поломка: язык и текстуры берутся из самого jar, поэтому клиент
выглядит полностью рабочим. Но звуки с 1.7.3 лежат только в ассетах, и их
просто не было на диске. Движок поднимался, play() вызывался, ogg не
находился, а paulscode на это молчит.
- materialize_assets.py разворачивает дерево из индекса и хранилища,
жёсткими ссылками где возможно, и идемпотентен
- run-game.ps1 материализует ассеты перед запуском и указывает клиенту на
развёрнутое дерево; --assetIndex больше не нужен
- проверено: 1305 объектов, из них 1085 ogg, sounds.json на месте, ошибок
загрузки в логе нет
Заодно убрана временная диагностика звука и движения, добавленная ради
поиска причины: она доказала, что запрос и воспроизведение доходят до
OpenAL, и свою задачу выполнила.
Полный prepare-game.ps1 после этого проходит целиком: 112 патчей,
FORK COMPILES CLEAN, 3268 классов, RsxDebug в дереве не осталось.
Проект начинается с двух вещей: клиент, который мы действительно собрали, и
загрузчик, который является его частью, а не чем-то рядом.
Форк
- prepare-game.ps1 пересобирает клиент целиком: ванильный jar, SRG и MCP,
SpecialSource, FernFlower, патчи, автофиксеры, javac. Идемпотентен.
- Свой код игры лежит в src-overlay, потому что src пересоздаётся при каждой
сборке и всё написанное вручную там погибает.
- 116 патчей в patches/decompiler-fixes.txt. Каждый сверялся с оригинальным
байткодом через javap: компиляция не ловит ошибки декомпиляции.
- struct_diff.py сравнивает исходный байткод с нашей сборкой по классам,
интерфейсам, суперклассам, методам и полям, и отдельно проверяет, что
пропавшие классы действительно никому не нужны.
Загрузчик
- Собирается и тестируется без игры: build.ps1 не использует classpath
вообще, поэтому SelfTest из 128 проверок проходит без запущенного форка.
- Клиентский API не содержит ни одного игрового типа, реализацию даёт игра.
- Политика: мод меняет то, что клиент показывает, но никогда то, что истинно
в мире. Мир, предметы, игроки и сеть принадлежат серверу.
- Capability приведены в соответствие с этой политикой: осталось шесть, и
за каждым стоит реальная проверка. Прежние WORLD, PLAYER, NETWORK, TEXT,
INPUT и COMMAND выдавались, но ничего не проверяли.
- Команды модов имеют область CLIENT, SERVER или BOTH. Серверные не
выполняются на клиенте никогда.
- Свой jar загрузчика лежит в classpath игры и сборки форка.
Инструменты
- add_patch.py, чтобы каждое исправление переживало передекомпиляцию
- find_self_comparisons.py, find_remove_index_bugs.py, find_callers.py
- stage_run.py и fetch_missing.py для запуска клиента
sasheg dev