Улучшение работы LIVE-серверов

Улучшение работы LIVE-серверов

В прошлом месяце мы рассказывали, что меняем подход к тому, как расставляем приоритеты среди самых давних проблем Star Citizen. Сегодня хотим поделиться первыми результатами: что уже удалось исправить, какого прогресса мы добились и какая работа для этого потребовалась.

Сейчас основное внимание сосредоточено на проблемах, которые сильнее всего влияют на игровой опыт. Вместо того чтобы разбирать ошибки по одной, мы смотрим шире и группируем их по системам, которые они ломают. Корабль должен находиться там, где вы его оставили. Инвентарь должен загружаться. Миссии должны работать. Это базовые вещи, и мы понимаем, что если они дают сбой, уже неважно, насколько впечатляюще выглядит всё остальное. Если вы не можете получить свой корабль, теряете снаряжение или тратите 15 минут на попытки пройти ошибку подключения — именно это и запоминается.

Чтобы держать в центре внимания именно опыт игроков, поиск и расстановку приоритетов по таким проблемам передали команде Player Experience. Alpha 4.10 стала крупнейшим применением этого подхода на сегодняшний день, и теперь мы хотим показать, как он работает на практике.

Как это работает на практике в Alpha 4.10

Основное внимание было сосредоточено на следующих направлениях:

• ИИ
  
• Стыковка и дозаправка
  
• Экономика и общие эксплойты
  
• Удобство в первый час игры
  
• Грузовые лифты
  
• Ангары и ASOP
  
• Инвентарь
  
• Ошибки входа и подключения
  
• Квантовые перелёты и Starmap
  
• Потеря кораблей
  

Дважды в неделю команды QA, Production, Player Experience и Community собираются вместе, чтобы рассмотреть проблемы, которые сильнее всего влияют на игроков. Мы сопоставляем внутренние данные с вашими отчётами в Issue Council и учитываем, как часто встречается проблема, сколько игроков она затрагивает, как долго существует и насколько серьёзно мешает игре. Все эти факторы объединяются в так называемый Impact Score — показатель влияния, который помогает определить, чем нужно заниматься в первую очередь.

Ваши отчёты в Issue Council играют в этом очень важную роль. Во многих случаях подробные шаги воспроизведения, дополнительная информация и видеозаписи помогали нам перейти от понимания того, что что-то сломано, к пониманию почему именно это ломается. А это значительно ускоряет поиск решения.

С Alpha 4.10 уже начинают проявляться результаты такого подхода.

На момент написания материала за весь цикл разработки Alpha 4.10 было внесено 1 239 исправлений ошибок, тогда как в Alpha 4.9 их было 295. Разумеется, эти цифры зависят от масштаба каждого обновления. Alpha 4.10 значительно крупнее и содержит больше нового контента, а значит, в процессе разработки появляется и больше проблем, которые приходится находить и устранять.

Но важнее другое: из этих исправлений 479 относятся к ошибкам, которые уже существовали в Alpha 4.9 или более ранних версиях. Именно эта цифра лучше показывает реальный прогресс в улучшении существующего LIVE, а не просто количество проблем, обнаруженных и исправленных во время разработки нового контента.

Мы также добились заметного улучшения производительности клиента. В последние месяцы добавление нового контента без соответствующей оптимизации постепенно снижало производительность, а появление инстансов и Осады Orison сделало эту проблему особенно заметной. В результате команды Engine, Physics, AI, Gameplay, Rendering и Content совместно занялись устранением наиболее серьёзных причин падения производительности.

При сравнении одинаково заполненных посадочных зон в Alpha 4.9 и Alpha 4.10 на разных конфигурациях оборудования средний FPS клиента вырос на 15,5%. Так что следующая поездка по Lorville должна ощущаться заметно лучше.

За кулисами Alpha 4.10

После почти каждого релиза мы видим один и тот же вопрос: если вы знали об этих проблемах, зачем вообще выпускали обновление?

Справедливый вопрос. Список известных проблем никогда не бывает пустым, поэтому решение о готовности сборки к LIVE всегда сводится к тому, какие ошибки мы можем безопасно исправить и проверить, и действительно ли новая версия лучше той, в которую вы играете сейчас. Мы не всегда принимаем идеальное решение. Иногда только полная нагрузка LIVE-среды позволяет по-настоящему проверить систему, но к таким решениям мы относимся очень серьёзно.

Позже сегодня мы опубликуем пилотный выпуск возможной новой серии под названием Inside CIG, где покажем процесс работы над Alpha 4.10 изнутри. Вы сможете заглянуть на наши совещания, увидеть разработчиков за работой над проблемами и контентом, которые вы тестируете на PTU, и посмотреть, как тестирование, телеметрия и ваши отзывы объединяются в процессе подготовки обновления к LIVE.

Подробнее об исправлениях

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

Как и в случае с инициативой по исправлению проблем транспорта, этот подход теперь применяется сразу к нескольким ключевым системам игры. Основной упор делается на то, чтобы точнее находить первопричины, собирать более качественные диагностические данные и проверять, что исправления действительно продолжают работать уже в условиях LIVE.

Пустой инвентарь

STARC-211218 — пустой инвентарь

В итоге оказалось, что здесь наложились сразу три разные проблемы.

Главным признаком было накопление операций со статусом «pending moves». Каждое действие с инвентарём добавляло новую такую операцию, но они не завершались. Когда очередь окончательно зависала, при следующем открытии инвентарь отображался пустым. Причина оказалась глубже: первый запрос на перемещение предмета в хранилище завершался по тайм-ауту. Повторный запрос возвращал ответ «already exists», то есть исходная операция на самом деле прошла успешно, но клиент не получил подтверждение. Поскольку ошибка «already exists» не считалась подходящей для повторной попытки, клиент прекращал обработку, а операция навсегда оставалась в ожидании.

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

Исчезающие из ангаров корабли

STARC-186319 — корабли исчезают из ангаров

При Server Meshing одна и та же сущность иногда может одновременно загружаться на нескольких серверах. Это не должно происходить часто, но такое возможно рядом с границами серверов и у объектов с очень большим радиусом стриминга. Levski оказался особенно подвержен этой проблеме. Код, который определял, нужно ли отправлять корабль в хранилище, использовал проверку IsAuthorityPossible(). Проблема в том, что эта проверка возвращала положительный результат на каждом сервере, а не только на том, которому действительно принадлежит ангар.

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

Само исправление оказалось сравнительно простым: в системе очистки посадочной зоны ошибочную проверку IsAuthorityPossible() заменили на настоящую проверку владельца — HasAuthority(). Хороший пример того, как сравнительно простое решение становится очевидным только после того, как удаётся добраться до реальной причины проблемы.

Другие исправления

Ниже приведена часть ошибок, исправленных в Alpha 4.9 и 4.10. Это не полный список всех изменений, вошедших в эти обновления, а скорее общий обзор работы по ключевым направлениям, на которых сосредоточена эта инициатива.

Все проблемы, отмеченные символом ▲, напрямую связаны с активными отчётами в Issue Council.

Потеря кораблей

▲ STARC-186319 — корабли могли исчезать и отмечаться в терминале ASOP как «Stored» сразу после посадки или вылета из ангаров станций, например Levski, при этом пилот падал на пол.

• Причиной оказалось состояние гонки, при котором два отдельных процесса могли одновременно попытаться удалить и снова отправить один и тот же корабль в хранилище. В некоторых случаях это происходило из-за появления корабля с некорректной зоной или токеном доступа. Исправление добавляет проверку, которая не позволяет удалить корабль, если он уже находится в процессе отправки в хранилище другим процессом.

▲ STARC-206457 — при вызове корабля из ангара он мог появиться уже в состоянии квантового перелёта и сразу после завершения подъёма платформы врезаться в дверь или стены ангара.

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

▲ STARC-152514 — терминал ASOP в вестибюле станции мог ошибочно показывать, что корабль необходимо восстановить, хотя он спокойно находился в хранилище на своей площадке.

• ASOP проверял только непосредственное состояние хранения самого корабля. Однако сохранённый корабль фактически находится внутри инвентаря ангара. Если ангар завершал отправку корабля в хранилище уже после того, как игрок отошёл слишком далеко, ASOP терял его из виду. Теперь ASOP дополнительно проверяет инвентарь самого ангара.

Ангары и ASOP

▲ STARC-128568 — на некоторых станциях внешняя дверь ангара могла оставаться закрытой, тогда как внутренняя открывалась, запирая игроков внутри или не позволяя попасть в ангар.

• Внешняя и внутренняя двери ангара были неправильно связаны на серверной стороне, из-за чего одна могла открываться независимо от другой на таких станциях, как Stanton Gateway, Ruin Station и Orbituary. Связь между ангаром и его дверями восстановлена, теперь обе открываются синхронно.

▲ STARC-205924 — добытая руда исчезала после помещения горнодобывающего корабля в ангар.

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

▲ STARC-207340 — топливо во внешних топливных капсулах пропадало после помещения корабля в хранилище через ASOP.

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

▲ STARC-186642 — вызов корабля, которому требовался ангар другого размера, мог завершиться ошибкой, автоматическим возвратом в хранилище или даже уничтожением корабля.

• Раньше игра поддерживала только один активный инстанс ангара определённого размера для каждого игрока. Если запрашивался ангар другого размера, пока предыдущий ещё использовался, операция могла незаметно завершиться сбоем или, в худшем случае, уничтожить прибывающий корабль. Теперь старый инстанс ангара корректно закрывается и создаётся новый нужного размера. Дополнительное исправление также не позволяет лифтам отправлять игроков в уже выгруженные старые инстансы ангаров, из-за чего корабли раньше могли ошибочно отображаться как требующие восстановления.

Игроки без шлема могли задохнуться в некоторых служебных зонах ангаров и лифтов Levski.

• В части служебных зон ангара отсутствовала атмосфера. Теперь её зона действия расширена и покрывает эти участки.

Грузовые лифты

Платформа грузового лифта могла навсегда зависнуть на экране «Transferring...» после многократного подъёма и опускания груза миссии, полностью блокируя дальнейшее использование лифта.

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

▲ STARC-153267 — груз в миссиях на перевозку мог полностью отсутствовать в точке получения, делая выполнение задания невозможным.

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

Сообщение «Elevator Overloaded» не давало понять, что часть груза всё же была перенесена, из-за чего игрокам было непонятно, что именно оказалось на платформе.

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

▲ STARC-199979 — сдача яиц Boreal Quasi Grazer через грузовой лифт во время Nyx Mission Pack 2 не завершала миссию по сбору ресурсов.

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

Инвентарь

▲ STARC-211218 — личный, станционный или трофейный инвентарь мог полностью опустеть и оставаться недоступным несколько минут, мешая брать и сдавать предметы миссий.

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

▲ STARC-204415 — двойной щелчок по элементу брони в инвентаре мог одновременно экипировать соседний предмет, а иногда полностью удалял слот нижнего костюма и не позволял снять снаряжение.

• Оказалось, что причина совпадала с более ранней проблемой экипировки брони. После полного внедрения того исправления тестирование подтвердило, что ошибка больше не возникает.

▲ STARC-200719 — экипировка некоторых нижних костюмов, особенно после освобождения из Klescher, могла убрать значок слота нижнего костюма из интерфейса и лишить игрока возможности менять его.

• Причиной была рубашка, надетая до попадания в Klescher, которая фактически не снималась и конфликтовала со слотом нижнего костюма. Теперь при попадании в тюрьму рубашка корректно снимается.

Некоторые ключ-карты и накопители могли исчезать при взаимодействии и оставаться скрытыми до тех пор, пока игрок не подбирал другой предмет.

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

▲ STARC-202297 — если выбрать «Carry» для предмета в инвентаре, уже держа что-либо в руках, например мультитул, проигрывалась анимация убирания предмета, после чего он полностью исчезал.

• Команда Carry неправильно обрабатывала уже удерживаемые предметы и помещала их во внутренний контейнер вместо личного инвентаря. Обработка исправлена, а также добавлена проверка, предотвращающая такую потерю предметов.

▲ STARC-200139 — меню фильтров категорий в инвентаре, грузовых терминалах и терминалах крафта могли зависать открытыми и накладываться друг на друга при быстром наведении или нажатии.

• Причиной было состояние наведения, которое не успевало сброситься, если курсор слишком быстро покидал кнопку фильтра. Теперь при открытии нового меню все остальные автоматически закрываются.

▲ STARC-204772 — некоторые виды оружия сразу после экипировки отображались чёрными силуэтами в ячейках снаряжения и интерфейсе добычи до повторного открытия инвентаря.

• Проблема устранена исправлением рендеринга.

▲ STARC-213375 — перетаскивание или перенос через Shift предметов из добычи в рюкзак или слоты брони корпуса не работал во многих локациях.

• Для корректной регистрации событий перетаскивания соответствующей панели интерфейса потребовался другой режим рендеринга.

Кнопка Buy в терминале магазина переработки Nyx на Levski была визуально смещена, из-за чего по ней было трудно попасть.

• Положение кнопки на экране исправлено.

Разделение стопки предметов в личном инвентаре и последующее объединение обратно могло привести инвентарь в неисправное состояние.

• Причиной было то, что разделённые предметы временно сохраняли одинаковые внутренние идентификаторы до обновления локального кэша. Ситуацию дополнительно усугубляло отсутствие правильного порядка сортировки у некоторых предметов из комплектов. Несколько исправлений устранили обе проблемы, а длительное тестирование подтвердило их стабильность.

Только что подобранные предметы, например предохранители или руда, нельзя было разместить из инвентаря, пока игрок хотя бы один раз не закроет и снова не откроет его.

• Причиной был устаревший кэш инвентаря. Теперь кэш правильно обновляется при подборе предметов, а старый обходной механизм, при котором нажатие ESC сбрасывало кэш, удалён.

Пополнение боеприпасов использовало только магазины из слотов брони корпуса и игнорировало запасные магазины в рюкзаке.

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

Ошибки входа и подключения

▲ STARC-178776 — при попытке войти в Постоянную вселенную игроков выбрасывало в главное меню с ошибкой 64008 «Spawn Resolver Error».

• В разное время у проблемы было две причины. Первая волна была связана с ошибкой исключения данных, а более позднее возвращение проблемы — с рассинхронизацией состояния аккаунта на серверной стороне, которая также могла вызывать отключения 64006. Основная причина устранена исправлением серверного сервиса.

▲ STARC-162848 — игроки могли застрять с ошибкой 60029 и полностью потерять возможность войти в Постоянную вселенную.

• У затронутых аккаунтов данные персонажа на серверной стороне оказывались в повреждённом состоянии — фактически персонаж одновременно считался сохранённым в двух местах. Серверное исправление устранило причину проблемы, а уже застрявшие аккаунты были восстановлены вручную с помощью инструментов поддержки.

▲ STARC-177979 — ошибка появления 64010, при которой игроки ждали более 12 минут, пока сервер пытался определить их последнее местоположение, после чего происходил тайм-аут.

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

▲ STARC-210544 — отключение с ошибкой 64006 «Location Resolution Request failed», возникавшее, когда серверная система не могла найти запись персонажа для его загрузки при входе.

• Это была временная рассинхронизация состояния аккаунта на серверной стороне, а не реальная потеря данных персонажа. Проблема могла исчезнуть сама через несколько секунд или даже спустя примерно 15 часов. Она была причиной большинства связанных ошибок 64008, и обе проблемы устранены одним исправлением серверного сервиса.

Квантовые перелёты и Starmap

Прокладка маршрута для квантового перелёта из ангара станции не работала, если пункт назначения не находился в прямой видимости.

• Сама станция блокировала расчёт маршрута, поскольку станции были отмечены типом объектов карты с отключёнными навигационными точками. После включения навигационных точек для станций маршруты из ангаров начали строиться правильно.

Нажатие на маркер отслеживаемой миссии в Starmap слишком сильно приближало камеру.

• Расстояние приближения рассчитывалось по крошечному радиусу самого маркера вместо более подходящего объекта поблизости. Теперь для расчёта используется более корректный объект.

▲ STARC-170842 — участники группы получали уведомление «connected» каждый раз, когда управление их персонажем переходило между серверами, а не только при первом подключении.

• Серверная служба сообщений отправляла уведомление при каждой передаче между серверами в рамках Server Meshing вместо единственного события при первом входе игрока в shard. Пока уведомление отключено через настройку конфигурации.

Корабли могли проходить в квантовом перелёте прямо сквозь луны, которые должны были перекрывать маршрут.

• Проверка препятствий для точки выхода из квантового перелёта не учитывала перекрытие маршрута лунами. Теперь система правильно определяет, когда луна находится на пути.

ИИ

Нестабильное поведение вражеских кораблей в бою: ИИ мог зависнуть посреди схватки или лететь прямо в игрока.

• Причин было несколько: у одного типа корабля отсутствовала метка класса истребителя, один из манёвров работал неправильно и вызывал заметное раскачивание, а команда остановки выполнялась безусловно и полностью замораживала ИИ. Каждая причина была исправлена отдельно, а последующее тестирование подтвердило нормальное маневрирование без зависаний и таранов.

Истребители Vanduul Scythe могли появляться на месте миссии пассивными и не вступать в бой.

• Конфигурация ИИ пилота ошибочно ссылалась на оставшуюся от другого проекта стандартную активность вместо правильного поведения «ожидание — вступление в бой». После исправления ссылки пассивное появление устранено.

Yormandi мог после оглушения зависнуть без дела и больше не возвращаться к атаке.

• Исправления логики и данных затронули мотивацию ИИ существа и обработку прерывания реакции на боль. Проблема ненадолго вернулась в одном редком случае посреди атаки, но дополнительное исправление устранило и его.

Стыковка и дозаправка

▲ STARC-203449 — корабль, которому диспетчер ATC назначил стыковочный узел, мог не пристыковаться даже при идеальном выравнивании.

• В Stanton, Nyx и Pyro корабли иногда теряли возможность пользоваться ангарами и станциями, если находившийся рядом второй игрок вмешивался в процесс стыковки. Кроме того, стыковочные трубы могли зависнуть в состоянии «already associated», блокируя дальнейшие попытки. Исправление успешно проверено на множестве станций и типов кораблей.

Cargo ATC могла переставать отвечать, не позволяя запросить зону погрузки.

• Вызов Cargo Services на станциях Stanton, Nyx и Pyro иногда оставался без ответа, поэтому игроки не могли получить зону для автоматической загрузки груза.

Первый час игры

STARC-177016 — после столкновения и уничтожения корабля игрок мог оказаться навсегда заперт внутри кабины.

• Иногда кресло пилота отсоединялось от разбитого корабля до полного завершения последовательности уничтожения. Пилот оставался жив, но не мог выйти или катапультироваться, порой вообще без возможности выбраться. Теперь такое отделение кресла корректно завершает процесс уничтожения корабля вместо того, чтобы оставлять игрока в ловушке.

Вызванная техника могла появляться с шасси, провалившимся в пол ангара, что делало взлёт невозможным.

• Если вызвать технику и уйти во время анимации её отправки в хранилище, при следующем появлении шасси могло оказаться внутри пола. Повторный вызов иногда также блокировал кнопку Retrieve в ASOP. Теперь добавлена проверка и автоматическая коррекция положения техники.

Радар корабля и другие системы могли оставаться выключенными после перезапуска питания.

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

▲ STARC-179201 — патрульные миссии со сканированием спутника могли зависнуть, если спутник не появлялся.

• В некоторых патрульных миссиях требуется просканировать указанную область через спутник, но сам спутник иногда не появлялся и навсегда блокировал цель. Логика миссии не получала подтверждения успешного появления спутника. Теперь предусмотрена запасная точка появления, позволяющая продолжить миссию, если основная не сработала.

При импульсном сканировании имя и фракция цели могли отображаться как «Unavailable».

• При сканировании корабельным импульсом или через Target Status MFD имя и фракция цели показывались как «Unavailable», даже когда эти данные должны были быть известны. Теперь название модели просканированного корабля отображается сразу.

Пилотируемые и дистанционные турели по умолчанию использовали разные режимы прицеливания.

• Пилотируемые турели по умолчанию использовали гиростабилизацию/автоприцеливание, а та же турель при дистанционном управлении — прицеливание по упреждающему маркеру. Причиной было неправильное повторное определение режима прицеливания при переключении между ручным и дистанционным управлением.

Выбор ремонта на посадочной площадке недостаточно быстро блокировал остальные услуги.

• После выбора Repair другие варианты не блокировались сразу, поэтому можно было отправить конфликтующий запрос на другую услугу, который незаметно отменял ремонт. Состояние гонки между этими запросами исправлено.

▲ STARC-214209 — одновременный запрос нескольких посадочных услуг мог привести к тому, что ремонт приходилось запрашивать повторно.

• Если одновременно выбрать Repair вместе с Restock или Refuel, интерфейс показывал обработку всех услуг, но ремонт мог незаметно завершиться неудачей и требовал повторного запроса.

▲ STARC-131916 — при построении маршрута на мини-карте линия маршрута не отображалась.

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

Многие виды FPS-оружия на средней дистанции отображались грубыми моделями с низкой детализацией.

• Винтовки, пистолеты-пулемёты, дробовики и снайперские винтовки использовали слишком низкий уровень детализации как в миниатюрах инвентаря и терминалов крафта, так и при обычном просмотре с умеренного расстояния. Настройки перехода между LOD были скорректированы, и теперь более детализированные модели отображаются на нужной дистанции.

▲ STARC-127424 — терминал Ore Deposit в Klescher всегда выдавал ошибку при обмене драгоценных камней на merits.

• Заключённые Klescher Rehabilitation Facility не могли обменять добытую руду на merits для сокращения срока: терминал неизменно показывал «Transaction Failed». Система неправильно определяла, находится ли руда в рюкзаке, и отправляла запрос на продажу не в тот список инвентаря. Проверка исправлена.

▲ STARC-214870 — продажа руды с грузового лифта через товарный терминал завершалась ошибкой Entity Query.

• Продажа Dolivine, Aphorite и Hadanite, находившихся на грузовом лифте, через товарный терминал завершалась ошибкой «Failed Entity Query». Клиент неправильно рассчитывал стоимость сделки, из-за чего сервер отклонял её при проверке. Расчёт исправлен.

Основания истощённых месторождений не исчезали после повторного появления ресурса.

• Основания добываемых объектов могли оставаться на месте бесконечно даже после появления нового ресурса в той же точке. Очередь таймеров системы очистки была отсортирована в неправильном порядке, поэтому удаление никогда не срабатывало. Порядок исправлен.

Подсказка о дозаправке могла навсегда остаться на экране после возрождения во время миссии и блокировать другие уведомления.

• Это ещё один вариант проблемы с зависшей подсказкой «Dock with Refueler», возникающий после возрождения во время миссии по дозаправке.

У активных брошенных гранат отсутствовал предупреждающий маркер HUD.

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

▲ STARC-191377 — маркеры участников группы на HUD показывали только стрелку направления и расстояние, но не имя игрока.

• В интерфейсе привязка данных, отвечавшая за видимость подписи имени, постоянно возвращала нулевое значение. Эта привязка исправлена.

Экономика и общие эксплойты

Хотя мы не раскрываем подробности всех исправлений эксплойтов, отметим, что в Alpha 4.10 было устранено 17 таких уязвимостей.

В их числе — самый часто сообщаемый экономический эксплойт в игре, который позволял вводить в экономику огромное количество aUEC и из-за которого сотрудникам Game Security неоднократно приходилось вмешиваться и корректировать ситуацию.

Что дальше?

Выход Alpha 4.10 не означает, что работа закончена. Мы всё ещё разбираемся с рядом проблем, некоторые исправления уже находятся в работе, а часть ошибок проявится только после того, как 4.10 окажется под полноценной нагрузкой LIVE. Эта работа будет продолжаться, а список приоритетов — меняться по мере устранения старых проблем и появления новых.

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

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

Но здесь нам по-прежнему нужна ваша помощь. Отчёты в Issue Council и отзывы на других площадках помогают понять, какие проблемы затрагивают больше всего игроков и где наша работа принесёт наибольший результат. Подробные шаги воспроизведения, видеозаписи и дополнительная информация позволяют не просто узнать о существовании ошибки, а понять, почему именно она возникает. И если проблема, которую мы отметили как исправленную, у вас всё ещё появляется — нам тоже нужно об этом знать.

И самое главное — спасибо всем, кто тратит время на отчёты об ошибках, записывает видео, описывает способы их воспроизведения и помогает нам находить причины этих проблем. Мы знаем, что с некоторыми из них игрокам пришлось мириться гораздо дольше, чем следовало. Ваши отзывы действительно помогают нашим командам и позволяют делать исправления, которые не разваливаются после следующего обновления.

Работы впереди ещё много, и мы продолжим рассказывать о её ходе.