Успешное скачивание ещё не означает, что игроки подключаются к обновлённым файлам. Перед повторным запуском SteamCMD сопоставьте ветку и игровую сборку клиента с журналом работающего сервера, затем проверьте: служба запускает именно ту установку, которую обновляет команда.
Инструкция рассчитана на немодифицированный PC dedicated server на Linux. Используем структуру из настройки Ubuntu: satisfactory.service, пользователь satisfactory, отдельный SteamCMD /home/satisfactory/steamcmd/steamcmd.sh, установка /home/satisfactory/server, HOME /home/satisfactory. Сначала проверьте свой unit, затем адаптируйте пути. У контейнера и Windows-службы механизм обновления другой. Обновление PC-сервера не добавляет поддержку консолей.
Запишите обе стороны несовпадения#
Сохраните точный текст ошибки и версию/сборку, которую показывает клиент игры. В Steam проверьте ветку через Properties → Betas. Обычная public-ветка и Experimental выбираются отдельно; Coffee Stain объясняет назначение Experimental и выбор в лаунчере. В Epic проверьте, какую запись игры запускаете. Если состояние обновления выглядит устаревшим, перезапустите лаунчер.
Соберите сведения о сервере:
sudo systemctl show satisfactory.service \
-p ActiveState -p MainPID -p User -p WorkingDirectory -p ExecStart
sudo systemctl cat satisfactory.service
sudo journalctl -u satisfactory.service -n 160 --no-pager -o short-iso
sudo head -n 120 /home/satisfactory/server/FactoryGame/Saved/Logs/FactoryGame.log
Нужны стартовые строки текущего запуска. Старый журнал или файл соседней установки легко вводит в заблуждение. Запишите игровую сборку/сведения о совместимости и ветку из команды обновления. SteamPipe build ID и идентификатор версии/changelist внутри игры — разные типы значений. Не требуйте совпадения несвязанных чисел только потому, что оба названы «сборкой».
| Наблюдение | Что проверить дальше |
|---|---|
| Не входит один клиент, остальные обновлённые входят | Его лаунчер, ветку и файлы игры |
| Все клиенты видят несовпадение версии сервера | Реально запущенную сборку, каталог обновления и ветку |
| Нет ответа или возникает тайм-аут | Сеть и адрес назначения |
| Подключение проходит, но не загружается один сейв | Совместимость сохранения и журнал игры отдельно от клиента |
В обсуждении несовпадения после запуска обновления хорошо видна ловушка: факт работы установщика не сообщает, какие файлы исполняет процесс. Ответ форума не заменяет проверку вашего экземпляра.
Сопоставьте каталог обновления и службу#
Сравните WorkingDirectory и абсолютный путь ExecStart с +force_install_dir. Команда из домашнего каталога другого SSH-пользователя способна успешно обновить вторую копию, пока systemd продолжает запускать первую. Указывайте каталог явно и используйте непривилегированного владельца игры.
Проверьте ExecStartPre, задания по расписанию, настройки обновления панели и политику контейнера. Если команда перед стартом выбирает Experimental, она может отменить ручной переход на public при следующем запуске. Согласуйте ветку в системе, которая действительно управляет обновлениями. Не переносите команды хоста внутрь постороннего контейнера и не запускайте два установщика над одной директорией.
Перед изменением файлов создайте именованный ручной сейв и дождитесь завершения. Запишите сессию, checkpoint и текущую сборку. Сохраните миры, чертежи, настройки и параметры установки по инструкции резервного копирования. Для отката понадобится также восстанавливаемая старая установка с совместимым состоянием до обновления: архив одних миров не возвращает старый исполняемый файл.
Остановите процесс и выберите ветку явно#
Предварительно проверьте unit: в нашем примере задан KillSignal=SIGINT. Выделите время обслуживания, приостановите принадлежащее вам задание обновления, затем остановите службу:
sudo systemctl stop satisfactory.service
sudo systemctl show satisfactory.service \
-p ActiveState -p SubState -p MainPID -p Result
sudo journalctl -u satisfactory.service -n 80 --no-pager
Продолжайте после чистой остановки, когда нет оставшегося игрового процесса и других записывающих экземпляров. Тайм-аут или неудачное завершение сначала расследуйте. Принудительное убийство с немедленной перезаписью файлов — плохая отправная точка для восстановления. Следующий блок с проверками выбирает public: используйте его, только если игрокам нужна эта ветка, а сохранённый мир с ней совместим.
(
set -e
test "$(sudo systemctl show satisfactory.service -p ActiveState --value)" = inactive
test "$(sudo systemctl show satisfactory.service -p MainPID --value)" = 0
test "$(sudo systemctl show satisfactory.service -p Result --value)" = success
sudo -u satisfactory -H /home/satisfactory/steamcmd/steamcmd.sh \
+force_install_dir /home/satisfactory/server \
+login anonymous +app_update 1690800 -beta public validate +quit
)
Явный выбор ветки показан в справочнике службы dedicated server; SteamCMD описан у Valve. Если группа осознанно играет в Experimental, замените только -beta public на -beta experimental, сохранив состояние заранее и договорившись с игроками. Не выполняйте обе версии команды подряд. Явное public также убирает зависимость от прежнего выбора: историческое обсуждение описывает именно такую путаницу.
Прочитайте вывод установщика и подтвердите успешное завершение для приложения 1690800; одного нулевого кода оболочки недостаточно. При ошибке скачивания, авторизации или проверки оставьте службу остановленной, сохраните вывод и устраните причину. Validation может заменить изменённые файлы установки — заранее сохраните свои доработки. Проверка файлов не подтверждает совместимость мира и не восстанавливает резервную копию.
Проверьте новый запуск и настоящий вход#
После успешного обновления запустите службу отдельно:
sudo systemctl start satisfactory.service
sudo journalctl -u satisfactory.service --since '-5 minutes' \
--no-pager -o short-iso
Убедитесь, что это новые стартовые записи, запускается нужный каталог и ExecStartPre не выбрал другую ветку. Подключитесь к прежнему адресу и порту согласованным обновлённым клиентом. Проверьте записанный checkpoint фабрики, создайте сейв, штатно перезапустите сервер и войдите снова. Так проверяется и совместимость соединения, и сохранность состояния.
Если ошибка осталась, заново сравните уже новые сборки. Проверьте сохранённые записи Server Manager, DNS и проброс портов: адрес может вести в соседний экземпляр. Не сбрасывайте идентичность сервера и не удаляйте ServerSettings ради исправления версии. Если для нужной ветки пока нет совместимой пары клиента и сервера, сохраните резервную копию остановленного состояния и проверьте объявления разработчика. Повторная переустановка не выпускает отсутствующую сборку.
Переход на public не преобразует сейв в старый формат. Не открывайте единственный мир новой ветки старым сервером «на пробу». Проверяйте копию в отдельном совместимом экземпляре, сохраняя исходные байты. При необходимом откате возвращайте согласованную старую установку и её состояние до изменения, оставив новое отдельно для восстановления. В отчёте о воспроизводимой ошибке достаточно очищенных от секретов сведений о сборках, ветках, адресе назначения и обновлении; полный журнал с паролями публиковать не нужно.
