Serwer StarRupture 2026: DSSettings, hasła i zapisy

StarRupture wymaga od ekipy co-op czegoś lekko sprzecznego. To gra o fabrykach, więc cała rzecz polega na maszynerii, którą zostawiasz działającą: excavators zasilają smelters, a smelters zasilają drone rail, która jedzie dalej niezależnie od tego, czy ktoś na nią patrzy. Jednocześnie domyślnie jest to gra typu host i znajomi, więc ta maszyneria istnieje tylko wtedy, gdy jedna konkretna osoba ma włączoną grę. Odpowiedzią Creepy Jar jest osobne narzędzie dedicated server. Wciąż nosi etykietę Experimental i konfiguruje się w sposób, który zaskakuje nawet ludzi po kilkunastu innych serwerach. Oto co ono naprawdę robi.

Serwer to darmowe, osobne narzędzie na Steam

Nie jest ukryty gdzieś w plikach gry. "StarRupture Dedicated Server (Experimental)" to własna aplikacja na Steam, ID 3809400, darmowa do pobrania i przypisana do gry podstawowej jako tool. Nikt nie musi kupować StarRupture drugi raz, żeby go uruchomić, a osoba, która wcześniej hostowała, nie musi już być online.

Trzy cechy tej paczki decydują o większości konfiguracji:

• Jest tylko na Windowsa. Natywnej wersji na Linuksa nie ma, więc na maszynie z Linuksem działa pod Wine. Dokładnie tak zbudowane są nasze własne serwery StarRupture i właśnie dlatego wśród zależności pojawia się Visual C++ 2022 runtime: binarka serwera potrzebuje go zarówno na Windowsie, jak i w Wine prefix.
• Jest duży. Obecne depot to około 21 GB, więc pierwsze pobranie przez SteamCMD na domowym łączu nie zajmie dwóch minut.
• Zmienia się. Ostatni publiczny build serwera trafił do sieci 17 czerwca 2026, razem z hotfiksem 0.2.8 samej gry. Klient i serwer muszą się zgadzać, więc aktualizacja gry to zawsze też aktualizacja serwera.

Sama linia SteamCMD jest zwyczajna:

steamcmd +force_install_dir C:\StarRuptureServer +login anonymous +app_update 3809400 validate +quit

Narzędzie jest darmowe, więc logowanie anonymous zwykle działa. Jeśli twój SteamCMD odmówi, zaloguj się prawdziwym kontem Steam. Nic to nie zmienia w kwestii posiadania gry, po prostu część konfiguracji tak się zachowuje.

Gotową instalację uruchamiaj skryptem (na Windowsie plikiem .bat), a nie przyciskiem Play w kliencie Steam. Klient i serwer zaczynają walczyć o tę samą sesję Steam, a błędy, które z tego wychodzą, wyglądają jak problemy z siecią, choć nimi nie są.

StarRuptureServerEOS.exe -Log -Port=7777

DSSettings.txt to cała konfiguracja i jest w formacie JSON

Nie ma tu rozbudowanego pliku INI z dwustoma ustawieniami. Serwer czyta jeden plik o nazwie DSSettings.txt, leżący w katalogu głównym serwera obok pliku wykonywalnego, i mimo rozszerzenia .txt jego zawartość to JSON. Jeden przecinek za dużo zatrzyma start serwera, a komunikat błędu nie będzie pomocny.

{
  "SessionName": "SESSIONNAME",
  "SaveGameInterval": "300",
  "StartNewGame": "true",
  "LoadSavedGame": "false",
  "SaveGameName": "AutoSave0.sav"
}

• SessionName: folder, w którym zapisuje się twój świat, w StarRupture/Saved/SaveGames/. Wybierz nazwę, którą rozpoznasz też za trzy miesiące.
• SaveGameInterval: liczba sekund między autozapisami. 300 to pięć minut, co jest rozsądne w grze, w której godzina pracy to kawał belt layout.
• StartNewGame: generuje zupełnie nowy świat.
• LoadSavedGame: wczytuje istniejący zamiast tworzyć nowy.
• SaveGameName: który plik zapisu wczytać, na przykład AutoSave0.sav.

Pułapką są trzeci i czwarty klucz. StartNewGame jest poprawne dokładnie raz, przy pierwszym starcie. Zostaw je włączone, a restart potrafi podsunąć ekipie świeżą planetę, podczas gdy stary świat leży nietknięty w folderze SaveGames. Nic nie zostaje skasowane i tylko dzięki temu da się to odratować, ale czterech ludzi logujących się na pustą mapę to i tak zmarnowany wieczór. Zaraz po udanym pierwszym starcie ustaw StartNewGame na false, LoadSavedGame na true i wpisz w SaveGameName ten zapis, który naprawdę chcesz.

Jednej liczby tu nie znajdziesz: player cap, który warto podnieść. StarRupture jest zbudowane wokół czterech graczy w sesji, a wychodzenie poza to, co gra obsługuje, to droga do desynchronizacji, a nie do serwera społecznościowego.

Hasła leżą w dwóch osobnych plikach

Kontroli dostępu też nie ma w DSSettings.txt. Siedzi w dwóch kolejnych plikach JSON w tym samym katalogu głównym serwera:

• Password.json trzyma hasło management, czyli to od administracji serwerem.
• PlayerPassword.json trzyma hasło join, czyli to, które wpisują znajomi, żeby wejść.

Zapisywany jest hash, a nie hasło, które wpisałeś, i dlatego hostingi odsyłają do generatora społeczności na starrupture-utilities.com po zawartość pliku. Użyj hasła, którego nie używasz nigdzie indziej, wklej wygenerowany wynik do pliku i zrestartuj serwer.

Reset któregokolwiek z nich to ta sama sztuczka od tyłu: skasuj plik, wygeneruj nowy. Rób to świadomie, bo serwer bez PlayerPassword.json nie ma między internetem a twoją fabryką nic.

Dołącza się po adresie, nie przez server browser

Z menu głównego: Join Game, potem zakładka Dedicated Server, potem adres w formie ip:port i hasło gracza. Nie ma publicznej listy, na której twój serwer się pojawi, więc adres rozdajesz sam, nikt na niego nie trafi przypadkiem.

Port, z którym startujesz, to port, który oni wpisują. 7777 UDP to zwyczajowy domyślny wybór i nie ma w nim nic magicznego, ale argument -Port=, adres podany graczom i reguła firewalla przed maszyną muszą się zgadzać.

Jedna linia logu warta zapamiętania to OnUpdateSessionComplete. StarRupture rejestruje swoją sesję przez Epic Online Services podczas startu i dopiero od tej linii serwer naprawdę przyjmuje połączenia. Dokładnie dlatego używamy jej jako readiness marker na własnych serwerach. Wszystko wcześniej to jeszcze ładowanie, więc znajomy, który próbuje wejść trzydzieści sekund po starcie i nic nie dostaje, po prostu się pospieszył. Pełny log leży w StarRupture/Saved/Logs/StarRupture.log.

Dobieraj serwer pod fabrykę, nie pod liczbę slotów

Skoro sufit to czterech graczy, typowe liczenie slotów prawie nie ma zastosowania. Na serwerze StarRupture rośnie świat: działające maszyny, drone rails i ziplines rozpięte między nimi, przedmioty leżące w storage oraz to, jak dużą część mapy ktoś już przeszedł. Świat po pierwszym wieczorze jest tani w utrzymaniu. Ten sam świat po kilku Corporation Levels, łańcuchu Oil Extractorów i paru odblokowanych strefach to zupełnie inna maszyna, a rośnie dalej przez cały sezon.

Dwa praktyczne wnioski:

• Planuj pod wzrost, nie pod start. Dobieranie zasobów pod to, ile świat kosztuje pierwszego dnia, to dokładnie powód, dla którego ekipy przenoszą się w połowie sezonu. Kalkulator RAM dla StarRupture uwzględnia rozmiar świata i gęstość zabudowy, co jest bardziej użyteczne niż jedna polecana liczba.
• Taktowanie bije liczbę rdzeni. Symulacja fabryki mocno opiera się na wydajności single thread, więc wysoka częstotliwość na rdzeń daje zapracowanej bazie więcej niż dodatkowe rdzenie.

Aktualizacje, kopie zapasowe i realia early access

Skoro buildy muszą się zgadzać, każdy patch gry jest też patchem serwera. Hostingi zarządzane (nasz również) robią to same. Jeśli hostujesz sam, uruchom ponownie tę samą linię app_update 3809400 validate i zrestartuj serwer.

Kopię folderu SaveGames rób przed dużą aktualizacją, a nie po niej. To early access, a precedens jest realny: Update 1 z kwietnia 2026 cofnął wszystkie Corporation Levels do poziomu 1 i zwrócił dotychczasowy postęp jako Data Points do rozdysponowania, potem zmienił Quartz i przebudował sposób, w jaki Cargo Dispatchers łączą się z Receivers. Istniejące światy to przetrwały, ale nie bez zmian. Między kwietniem a czerwcem 2026 gra przeszła przez hotfiksy od 0.2.1 do 0.2.8, więc tempo jest szybkie.

Albo niech zajmie się tym ktoś inny

Jeśli Wine prefix, 21 GB pobierania i młyn aktualizacji brzmią jak cudza robota, właśnie po to jest hosting serwerów StarRupture: instalacja, auto update i dostęp do plików są ogarnięte, a panel zarządzania serwerem daje ci pliki konfiguracyjne i logi bez sesji SSH. Tak czy inaczej fabryka pracuje dalej, kiedy śpisz, a o to chodziło od początku.