- StatusSession: ответ на ванильный статус на том же порту.
Первый байт потока различает наш протокол и гостей: R - наш кадр,
иначе старый пинг (FE) или новый handshake + request + ping.
Логин в старом стиле получает вежливый отказ словами.
- Reader: первый байт, уже прочитанный вручную, теперь правильно
исключается из головы - раньше счётчик дважды пропускал его.
- TokenAuth: точные причины отказа (не подписано, другой сервер,
не тот вид, истёк, не тот игрок) и Verdict для каждой сессии.
- ClientSession: первое чтение смотрит на байт и отдаёт гостей статусу;
остальное идёт через прежнее расщепление.
- StatusTest: 5 проверок (json, modern, pong, legacy, отказ). Легаси-пинг
читался как знаковый байт; исправлено на беззнаковый.
- StatusRouteTest: 3 проверки через настоящий сервер и настоящие порты.
- watch-game.ps1: удаляет устаревший dev-token перед стартом сервера.
- Новый пакет LOD_REGION: сервер отдаёт участок дальнего вида — сетку высот
и цветов, по одной пробе каждые 4 блока.
- LodGenerator на сервере считает участки от начала мира, держит их в
памяти и пишет на диск рядом с миром, чтобы считать один раз.
- Клиент строит из участка сетку и рисует своим шейдером (#version 330) до
обычных чанков: чанки ближе и подробнее, поэтому закрывают дальний вид.
- Дальний вид приходит по мере того, как игрок ходит по миру: сервер шлёт
участки вокруг него раз в тик.
Проверки в сервере 96, в протоколе 24, в клиенте 128.
- PlayerData: файл на игрока в world/players/<аккаунт>.json. Позиция, рыскание и
тангаж, 30 слотов инвентаря, 7 мест брони по два слоя, здоровье, режим игры,
выученные рецепты и открытые узлы тех-дерева.
- Запись: при выходе игрока, раз в 30 секунд и при остановке сервера. Чтение:
при входе, так что игра продолжается с того места, где игрок остановился.
- В Json добавлен писатель: quote, number, numbers, texts.
- Файл пишется через временный файл и подменяется, так что оборванная запись
не портит прошлую.
Тесты: сервер 92 (было 88), добавлен PlayerDataTest.
- Протокол: 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 классов.
Протокол:
- ItemData читает таблицу items/items.csv (218 предметов ремейка) и отдает
числа: урон, дальность, темп, прочность, сколько ресурса за удар.
- ItemType: поля rid, researchScrap, techTreeBench, techTreeScrap,
techTreeParent, admin. Урон по частям тела делится как в ремейке: голова
вдвое, руки и ноги четыре пятых. Число в исходнике главнее таблицы.
- ItemRegistry: 218 предметов с рецептами, ценой исследования и веткой
дерева. Новые вещи: salvage-тесак, бронедвери, гаражи, взрывчатка,
компоненты, еда, мусор, верстаки и печи.
- NodeType: узлы с запасом (дерево 500/750/1000, камень 750, металл 500,
сера 200) и меткой: крестик на дереве до двух, горячая точка на руде до
трех.
- TechTree: ветки верстаков с предками, 125/250/500 скрапа.
- Новые пакеты: Dig, BreakProgress, CraftStart, CraftUpdate, ResearchStart,
ResearchUpdate, TechTreeUnlock, KnownRecipes, TechTreeState, ContainerOpen,
ContainerTake, LearnBlueprint.
Сервер:
- Knowledge: что игрок знает - рецепты и открытые узлы деревьев.
- Crafter: проверка рецепта, уровня верстака и ингредиентов; время крафта
по формуле плана.
- ResearchTable: предмет плюс скрап, десять секунд, предмет превращается в
чертёж; чертёж изучается и открывает рецепт.
- ResourceNode: запас, метка, последний удар отдает остаток.
- JunkPile: две-четыре бочки (серая - скрап и мусор, синяя - компонент,
красная - нефть и топливо) и ящик с едой; пустая мусорка исчезает через
60-180 секунд.
- RoadNetwork: сетка дорог и кольцо, точки спавна мусорки; генератор кладет
асфальт и ровняет дорогу по ширине.
- Проверка досягаемости вынесена из changeBlock, игрок получил benchLevel.
- Сессия отвечает на новые пакеты, при входе шлет известные рецепты и
открытые узлы.
Тесты: протокол 24 + 10, сервер 74 (было 57). Форк собирается чисто.
Фундамент предметов по данным плана (срез 11.2025) и серверный инвентарь.
В протоколе (общий словарь для клиента и сервера):
- ToolClass, ResourceClass - что чем ломается и что где лежит.
- ItemType - определение предмета: класс инструмента, урон по четырем
частям тела, прочность, Gather Rates по каждому классу ресурса
(сколько снимает удар, разброс, сколько уходит прочности инструмента),
bench - требуемый уровень верстака, knownByDefault - открыт ли рецепт
с начала игры, admin - только ли админы сервера.
- ItemRegistry - таблица предметов. Числа из плана, каждое в одном
месте, чтобы игра и план не разъехались.
- Recipe - ингредиенты, количество, базовое время крафта.
- ItemStack - тип, количество, остаток прочности и свои данные на стеке
(как теги у плагина в Paper): стек - это то, что путешествует.
Пакеты: Inventory (весь инвентарь при входе) и SlotChange (один слот).
На сервере: Inventory - 30 слотов, хотбар 6, сервер владеет инвентарем и
сообщает клиенту, а не спрашивает. Стартовый набор - камень в первом
слоте и в руке.
Тесты: предметы закреплены числами из плана (камень бьёт в голову на 20,
снимает 10 дерева и 5 руды; кирка не рубит дерево; меч не ломает вообще),
инвентарь переживает провод, сумка наполняется и опустошается, полная
сумма говорит об этом.
Замечание: прогрессия крафта в Rust упирается в лутбоксы - скрап падает
только из них, а чертёж требует найденного предмета. Это отдельный
вопрос (п. 5.2 плана), он не блокирует предметы и инвентарь.
Сервер умел принимать игроков и не умел ничего, что можно увидеть. Мир
был не написан: ни чанков, ни генерации, ни сохранения, ни игровых
пакетов.
Сделано:
- Пакет world: ChunkPos, Chunk, Blocks (теперь в протоколе), WorldGenerator,
ChunkStorage, World. Генерация чистая функция от зерна и координат, без
java.util.Random и без общего состояния, потому что чанк может
появиться через месяц после соседнего, на другой машине, и обязан
совпасть с ним побайтово. Сохранение — файл на чанк, запись во временный
файл и перенос, версия и контрольная сумма: половина записанного файла
это мир, который молча испортился.
- Снимок чанка и запись блока теперь под одним замком. Раньше копия могла
сняться посреди записи блока, и на диск уходила половина изменения.
- Player: позиция, вид, список отправленных чанков, проверка досягаемости
блока. Клиент не может переписать блок, до которого не дотянулся.
- Сервер держит мир, крутит его по тику, выкидывает давно не тронутые
чанки, шлет чанки вокруг игрока и рассылает изменения блоков и передвижения
тем, кто их видит.
- Клиентский сетевой слой в игре еще не тронут: это следующий шаг.
Проверено: 45 тестов сервера. Из них 25 на мир (детерминизм, круг
сохранения, автосохранение, вытеснение, отказ битому файлу) и 9 сквозных
через настоящий сокет: игрок входит, получает 25 чанков, чанк совпадает с
террейном сервера, блок ломается и остаётся сломанным после перезапуска
сервера, два игрока видят друг друга.
Теперь можно зарегистрировать аккаунт, поднять сервер и зайти в него.
Пароль не ходит по сети и не хранится на сервере в обратимом виде. Клиент
называет аккаунт, сервер отдаёт его соль и одноразовый вызов для этого
соединения, клиент тянет из пароля ключ через PBKDF2-HMAC-SHA256 и
подписывает им вызов вместе с именем. Пароль пересекает сокет ноль раз, а
запись обрезать нельзя: сервер не знает исходного пароля.
Отсюда важное следствие, которое сразу отозвало одну ошибку в протоколе:
соль обязана прийти раньше, чем клиент что-то доказывает, поэтому аккаунт
называется в Hello, а не в Auth. Иначе клиент получает соль не того
аккаунта и не может вывести ключ.
Учётная запись хранится как PBKDF2 соль, счётчик раундов и хеш. Раунды
лежат рядом с записью, а не в исходниках: число, существующее только в
коде, однажды становится причиной того, что аккаунт невозможно проверить.
Имена уникальны независимо от регистра: Player и player — это один
аккаунт. Иначе игрок получает двух персонажей и не понимает, какой его.
Троттлинг двумя ведрами, по аккаунту и по адресу: одно не мешает
подбирать одно имя, другое не мешает перебирать много имён с разных
адресов. Ответ на несуществующий аккаунт выполняет ту же работу, что и на
неверный пароль, и занимает то же время.
Токены живут только в памяти. Записанный на диск токен пережил бы процесс,
который его выдал, а украденный каталог сервера стал бы набором живых
сессий.
Сессии различаются номером, а не адресом. Ключ по адресу вытеснял всех, кто
зашёл с одного IP, то есть всех игроков за одним NAT.
Тик-цикл: 20 раз в секунду, с ограничением догоняющих тиков. Мир, который
тикает по кадрам, тикает в зависимости от видеокарты — ровно то, от чего
мы уходим, перенося симуляцию на свой сервер.
Регистрация — команда оператора, а не функция у клиента. Открытая
саморегистрация превращает хранилище аккаунтов в спам-цель и в очередь
поддержки.
Проверено 12 сценариев, и главный из них — не юнит-тест, а настоящий
сокет: регистрация, вход, доказательство пароля, токен, его погашение и
появление игроком. Отдельно проверено, что неверный пароль отвергается, а
старое доказательство не принимается против нового вызова. Тик-цикл
замеряется числом тиков за секунду, а не наличием потока.
Всё одним JDK, без Gradle и без сети, как и весь проект.
sasheg dev