Тайминги приручения не применяются

MAATRIX GAMES

Выставили в конфиге множитель скорости приручения, перезашли на сервер — а дино как приручался час, так и приручается. Классическая ситуация: настройка вроде бы стоит, а эффекта ноль. Разберём по порядку все места, где это обычно ломается, и как проверить каждое за пару минут, не гадая.

Проверьте, тот ли параметр вы меняли

Самая частая причина — правится не тот множитель. За скорость приручения в ARK: Survival отвечает конкретно TamingSpeedMultiplier, а не XPMultiplier (это скорость набора опыта персонажем и племенем) и не TamedDinoClassDamageMultipliers или другие боевые параметры дино. Путаница возникает потому, что все три живут рядом, в одной секции [ServerSettings] файла GameUserSettings.ini, и звучат похоже — "множитель для дино".

Откройте конфиг и проверьте, что строка выглядит именно так:

[ServerSettings]
TamingSpeedMultiplier=5.0

Дефолтное значение — 1.0. Если у вас XPMultiplier=5.0, а TamingSpeedMultiplier вообще отсутствует в файле или стоит на 1.0 — вот и разгадка, приручение шло по дефолту, просто опыт за него теперь начисляется быстрее, что легко спутать с "быстрее приручается".

Второй похожий капкан — регистр и точное имя параметра. ARK не ругается на опечатки в именах параметров GameUserSettings.ini, он просто молча игнорирует строку, которую не распознал. TameSpeedMultiplier без "ing" или Taming_Speed_Multiplier с подчёркиваниями — игра их не увидит и откатится на дефолт, при этом никакой ошибки в логе не будет. Сверяйте написание буква в букву с официальной вики или с рабочим конфигом, а не по памяти.

Настройка применяется только к новым попыткам приручения

Даже если параметр правильный и значение выставлено верно, есть нюанс, который ломает много нервов новичкам: TamingSpeedMultiplier влияет на дино только с момента начала приручения. Если вы усыпили тираннозавра, начали кормить его до правки конфига, а потом на лету поменяли множитель и перезапустили сервер — уже стартовавший таймер приручения этого конкретного существа не пересчитывается. Он продолжает идти по тем параметрам, которые действовали в момент, когда вы дали дино первую порцию еды (или он потерял сознание, в зависимости от версии).

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

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

• Дождаться, пока текущее приручение завершится (пусть и медленно), и applяется новый множитель уже к следующим дино.
• Если приручение только началось (первая минута) — иногда проще усыпить дино заново с нуля после применения настройки, чем ждать полного цикла на старом таймере. Учтите, что повторное усыпление тратит транквилизаторы и рискует потерей дино, если рядом агрессивные существа.
• Если это тестовое приручение мелкого животного специально для проверки настройки — просто начните его заново после рестарта сервера, не пытайтесь "довести" уже идущее.

Конфиг не перечитан сервером

Третья по частоте причина — сервер физически не увидел новый конфиг. GameUserSettings.ini в ARK читается при старте процесса сервера, а не постоянно в фоне. Есть отдельные настройки, которые применяются "на лету" через RCON-команды (например, SetTimeOfDay), но множители геймплея, включая TamingSpeedMultiplier, к ним не относятся — нужен полный рестарт процесса сервера.

Частая ошибка: администратор сохраняет файл в редакторе, видит "изменения применены" в панели хостинга (файл действительно записан на диск) и решает, что этого достаточно. Но пока процесс ShooterGameServer (или ArkAscendedServer для ARK: Survival Ascended) не перезапущен — он продолжает работать с настройками, которые загрузил при старте, и понятия не имеет, что файл на диске изменился.

Проверьте последовательность:

# посмотреть, когда реально стартовал процесс сервера
ps -eo pid,lstart,cmd | grep -i ShooterGameServer

# сверить с временем правки конфига
stat -c '%y' GameUserSettings.ini

Если время старта процесса раньше, чем время последней правки файла — конфиг ещё не подхвачен, нужен рестарт. Через RCON можно послать мягкое предупреждение игрокам и DoExit для штатной остановки, после чего сервис (если настроен через systemd или автозапуск панели) поднимется заново уже с новым файлом. О том, как организовать это без ручного вмешательства каждый раз, есть отдельный разбор — автоматический рестарт сервера по расписанию через cron, тот же принцип graceful shutdown подходит и для разового рестарта после правки конфига.

Отдельно уточним для тех, кто гоняет сервер через панель хостинга: не путайте "рестарт" и "ребут" — если у вас на VPS запущено несколько сервисов или сервер стартует через обёртку/скрипт, может понадобиться перезапуск именно игрового процесса, а не всей машины. Полный ребут хоста сработает, но это избыточно и дольше, чем штатный рестарт сервиса.

Конфликт с параметрами кластера или Game.ini

Если у вас несколько серверов в одном ARK-кластере (общий ClusterID) или используется Game.ini с переопределениями по видам существ — там может стоять параметр, который перебивает общий множитель. В частности, в Game.ini через секцию [/script/shootergame.shootergamemode] можно задать индивидуальные тайминги приручения для конкретных видов дино через TamedDinoClassResistanceMultipliers и подобные оверрайды — если такая строка когда-то была добавлена (например, скопирована из чужого конфига или сборки правил на кластер) и забыта, она может перекрывать глобальный TamingSpeedMultiplier для отдельных существ.

Проверьте Game.ini на предмет строк, содержащих Taming или Dino, и убедитесь, что там нет забытых оверрайдов:

grep -i "taming\|dino" Game.ini

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

Мод, который переопределяет тайминги приручения

Если на сервере установлены моды через Steam Workshop, особенно overhaul-моды или моды на приручение/разведение, некоторые из них принудительно задают собственную логику скорости приручения независимо от GameUserSettings.ini. В этом случае стандартный множитель может либо игнорироваться полностью, либо взаимодействовать с модовым множителем не так, как ожидается (например, перемножаться, а не заменяться).

Временно отключите такие моды (уберите ID из GameModIds в GameUserSettings.ini и перезапустите сервер) и проверьте тайминг на ванильной конфигурации. Если без мода множитель заработал как надо — смотрите документацию конкретного мода на Steam Workshop, там обычно отдельно описано, как он взаимодействует с нативными настройками сервера. Если вы только разворачиваете сервер и подбираете моды — обзор рабочих вариантов есть в статье про топ модов для ARK: Survival.

Как правильно проверить, что настройка реально применилась

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

1. Внесите изменение в TamingSpeedMultiplier в GameUserSettings.ini.
2. Полностью перезапустите процесс сервера (не просто сохраните файл).
3. Убедитесь, что сервер поднялся и загрузил мир (по логам или через RCON — команда ListPlayers подтвердит, что сервер живой и принимает подключения).
4. Найдите или заспавните (если у вас админ-права и это тестовый/приватный сервер) дешёвое мелкое существо — додо, компи или мышь-крысу (в зависимости от карты). Усыпите его транквилизатором и начните приручение уже после рестарта.
5. Засеките время до заполнения шкалы приручения и сравните с ожидаемым при вашем множителе (примерный ориентир: чем выше TamingSpeedMultiplier, тем быстрее процесс, но точные тайминги для каждого вида дино сильно различаются — сверяйтесь с вики конкретного существа, а не с одним универсальным числом).

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

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