Palworld: десинхронизация питомцев (Pal) между игроками

MAATRIX GAMES

Знакомая картина: хозяин базы клянётся, что его Anubis стоит у печки и работает, а зашедший в гости друг видит пустое место — или наоборот, пал вдруг телепортируется через полкарты, когда кто-то быстро добрался до второй базы. Иногда бывает хуже — пал пропадает из Палбокса совсем, или на секунду мелькает его дубликат. Это десинк питомцев — рассинхронизация состояния палов между клиентами и сервером. Разберём, откуда он берётся конкретно в Palworld, что из этого реально чинится настройками сервера, а с чем придётся смириться как с болячкой ещё сырого сетевого кода игры.

Почему у палов вообще расходится состояние между игроками

Palworld построен на Unreal Engine, и сетевая модель у него по духу похожа на многие другие survival-песочницы на этом движке (например, ARK) — сервер держит единственную "истинную" версию мира, а клиенты получают не полный поток данных о каждом объекте ежесекундно, а компактные обновления, между которыми сами достраивают движение через интерполяцию и предсказание. Пал бежит по прямой — клиент это предсказывает сам, не дожидаясь каждого пакета с сервера. Когда приходит следующее обновление и реальная позиция отличается от предсказанной — клиент "доводит" пала до истинного места. Если обновления идут с задержкой, редко или сервер не успевает их разослать вовремя — расхождение растёт, и это ощущается как рывки, телепорты, "залипание" пала на месте с последующим резким скачком.

У палов это усугубляется тем, что у каждого активного пала есть собственное ИИ-поведение (патрулирование, работа на станции, бой, следование за игроком) — это не статичный объект, а постоянно пересчитываемая сущность, чьё состояние нужно синхронизировать со всеми клиентами поблизости. Чем больше палов активны в зоне видимости нескольких игроков — тем выше нагрузка на репликацию именно в этот момент.

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

Сетевая стабильность: проверяем в первую очередь

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

С клиентской машины проверьте маршрут до IP сервера:

tracert ip_сервера        # Windows
traceroute ip_сервера     # Linux/macOS
mtr ip_сервера             # Linux/macOS, показывает потери по каждому узлу маршрута

Смотрите на две вещи: скачет ли пинг рывками вместо ровного значения и есть ли packet loss на любом из промежуточных узлов. Если жалуется вся группа игроков одновременно — вероятнее дело в сети самого сервера или хостинга. Если десинк ловит только один человек, пока остальные ничего не замечают — почти наверняка проблема на его стороне (домашний Wi-Fi, VPN, перегруженный роутер), и никакими настройками сервера это не вылечить.

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

Перегрузка сервера: слишком много палов и построек одновременно

Palworld плохо прощает разросшийся мир — это известная особенность движка, а не баг конкретно вашей настройки. Каждый пал на базе (и рабочий, и боевой сопровождающий) — это отдельная сущность с собственным ИИ, коллизией и сетевым состоянием, которое нужно постоянно синхронизировать. Чем больше баз с активными палами держат игроки, тем выше суммарная нагрузка на каждый цикл репликации — и десинк, которого не было в первую неделю сервера, постепенно нарастает вместе с ростом мира.

Что реально снижает эту нагрузку без урезания геймплея под корень:

• ServerPlayerMaxNum — не задирайте выше реального числа игроков "про запас": каждый слот в теории увеличивает пиковую нагрузку, даже когда он пустует большую часть времени.
• PalSpawnNumRate в PalWorldSettings.ini — контролирует плотность спавна диких палов на карте. Если сервер уже под нагрузкой от построенных баз, не имеет смысла держать этот множитель выше единицы — лишние дикие палы просто добавляют объектов для репликации без особой пользы игрокам.
• WorkSpeedRate — косвенно тоже влияет: чем быстрее рабочие палы производят/перемещают предметы на базе, тем чаще меняется их состояние и тем чаще его нужно рассылать клиентам.
• Регулярная ревизия заброшенных баз неактивных игроков — если гильдия давно не заходила, а на её территории продолжают "работать" десятки палов, это чистая нагрузка без смысла. В Palworld нет встроенного автоматического сноса заброшек, так что это вопрос ручной модерации админом.

Про общие принципы диагностики, что именно упирается — CPU, RAM или сеть — при просадках производительности любого игрового сервера, подробно в статье про мониторинг TPS и лагов: методика диагностики там применима и к Palworld, хотя сама игра не показывает TPS в привычном для Minecraft-игроков виде.

ServerReplicatePawnCullDistance: единственный прямой рычаг по сети

В PalWorldSettings.ini, в той же длинной строке OptionSettings=(...), что и остальные параметры, есть значение ServerReplicatePawnCullDistance — дистанция (в юнитах Unreal Engine), дальше которой сервер перестаёт репликировать состояние пала конкретному клиенту. Это прямой аналог "дальности прогрузки" именно для живых существ, а не ландшафта — и один из немногих параметров, который влияет непосредственно на десинк, а не на общую производительность.

ServerReplicatePawnCullDistance=15000.000000

Логика простая: чем больше значение — тем на большем расстоянии клиент продолжает получать актуальные данные о пале, и тем меньше ему приходится "додумывать" положение интерполяцией. Но у этого своя цена: больше дистанция репликации — больше объектов, за которыми сервер следит одновременно для каждого клиента, а значит больше трафика и нагрузки на CPU. Точное значение по умолчанию у разных версий сервера может отличаться, так что перед правкой посмотрите, что стоит в вашем текущем конфиге, и меняйте небольшими шагами (±20-30% за раз), проверяя реакцию по ресурсам и по фидбеку игроков.

Занижение этого параметра ради экономии ресурсов на перегруженном сервере — рабочий компромисс, но именно оно чаще всего и объясняет тот самый эффект "пал телепортировался, когда я быстро добрался до второй базы": пока игрок был далеко, пал выпадал из зоны репликации и не обновлялся, а при возвращении в радиус сервер разом "досылает" актуальную позицию — отсюда и рывок.

Десинк при быстром перемещении между базами

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

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

Смягчить эффект помогает то же, что и от перегрузки в целом: не разгонять PalSpawnNumRate выше необходимого, не копить десятки рабочих палов на каждой базе "про запас" и не задирать ServerReplicatePawnCullDistance без запаса по CPU и каналу.

Пропажа и дублирование палов: отдельная головная боль

Часть жалоб на "десинк" на деле про более неприятный сценарий — пал реально пропадает из Палбокса или на короткое время появляется в двух местах одновременно. Это классический race condition: если два клиента одновременно взаимодействуют с одним палом (например, один забирает его из Палбокса ровно в момент, когда второй назначает его на работу) при нестабильной сети или нагруженном сервере, порядок обработки действий может разойтись с тем, что видят клиенты — отсюда "призрачные" дубли, которые обычно пропадают сами при следующем сохранении.

Что тут реально в ваших силах:

• Не полагайтесь на визуальное состояние Палбокса как на источник истины в спорных ситуациях — если пал выглядит пропавшим, прежде чем восстанавливать сейв, перезайдите на сервер: часто это просто зависший локальный кэш UI.
• Регулярные бэкапы SaveGames — не лечат саму причину, но превращают редкую потерю пала в решаемую проблему. Настройте AutoSaveSpan на разумный интервал и дополнительно бэкапьте папку Pal/Saved/SaveGames/ на отдельное хранилище.
• Избегайте одновременных операций с одним палом двумя игроками, особенно при заметных лагах — это снижает частоту гонки состояний.

Официальных инструментов диагностики именно этого сценария Pocketpair пока не даёт, так что тут работает только профилактика.

Сеть игроков и практический чек-лист

Отдельно стоит сказать честно: десинк — не только вопрос сервера. Домашний Wi-Fi, перегруженный роутер, VPN с плохим маршрутом до дата-центра — всё это вносит вклад независимо от настроек сервера. Если жалуется один игрок, а не вся группа — начинайте разбор с его сети, а не с конфига.

Собираем всё в порядке приоритета — от простого к более трудозатратному:

1. Проверить сеть (mtr/traceroute, стабильность пинга, packet loss) — и со стороны сервера, и со стороны жалующегося игрока отдельно.
2. Свериться с ресурсами хоста — CPU и исходящий сетевой канал в часы пика онлайна.
3. Провести ревизию накопленных палов и баз — заброшки неактивных игроков, раздутые фермы рабочих палов "про запас".
4. Проверить и, при необходимости, аккуратно скорректировать PalSpawnNumRate, WorkSpeedRate и ServerReplicatePawnCullDistance небольшими шагами.
5. Настроить регулярные бэкапы SaveGames — на случай редких, но неприятных пропаж и дублей.
6. Если десинк остаётся заметным при разумном онлайне после всех шагов — это, вероятнее всего, упор в возможности текущего тарифа, и стоит посмотреть в сторону более мощной конфигурации VPS.

Если сервер только разворачивается и конфиг ещё не настроен, начните с базовой инструкции как поднять сервер Palworld — там расписаны требования по RAM и структура файлов, включая расположение PalWorldSettings.ini. А если проблема не в палах конкретно, а в общей просадке кадров и тиков — подробный разбор диагностики по CPU/RAM/сети есть в статье про десинк на ARK-сервере — механика репликации там объясняется на похожем движке и во многом переносится на Palworld.

Частые вопросы