Poradniki / Rozwiązywanie problemów

Project Zomboid: jak naprawić "Plik nie zgadza się z plikiem na serwerze"

To najbardziej frustrujący sposób, by zakończyć sesję, zanim się zacznie: wszyscy siedzą na rozmowie na Discordzie, ktoś klika Dołącz, a Project Zomboid wyrzuca go od razu z komunikatem o pliku, który rzekomo nie zgadza się z plikiem na serwerze. Nic się nie zepsuło, serwer robi dokładnie to, co mu kazano. Ten poradnik wyjaśnia, co faktycznie porównuje sprawdzenie, dlaczego się uruchamia, jak prawidłowo naprawić każdą przyczynę i kiedy rozsądnie jest je wyłączyć przez DoLuaChecksum.

Co tak naprawdę oznacza ten błąd

Gdy klient się łączy, serwer Project Zomboid porównuje sumę kontrolną plików Lua i skryptów, które klient wczytał, z własnymi. Jeśli choć jeden plik się różni, połączenie zostaje odrzucone, a gracz widzi komunikat z nazwą tego pliku: "plik nie zgadza się z plikiem na serwerze" albo jednego z jego bliskich krewnych, takich jak "pliku nie ma na kliencie" i "sumy kontrolne Lua/skryptów się nie zgadzają".

Sprawdzanie jest sterowane przez ustawienie serwera DoLuaChecksum, które jest włączone domyślnie. Jego zadaniem jest zagwarantowanie, że wszyscy w sesji działają na tym samym kodzie: identycznych plikach gry i identycznych modach. Ma to znaczenie, bo Project Zomboid uruchamia dużą część logiki w Lua po obu stronach, więc klient z innymi plikami nie widzi po prostu czegoś nieco innego. Desynchronizuje się, rzuca błędami i może uszkodzić to, co zapisuje z powrotem do świata.

Z tego wynikają dwie rzeczy, które oszczędzają sporo straconego czasu:

• Plik, który wskazuje, rzadko jest problemem. To tylko pierwsza różnica, na jaką trafiło porównanie. Ganianie za tym konkretnym plikiem donikąd nie prowadzi. Lepiej sprawdzić, dlaczego obie strony w ogóle mają różne pliki.
• To objaw, a nie usterka. Po jednej stronie jest inna wersja. Znajdź, która strona się rozjechała, a błąd zniknie sam.

Przyczyna 1: klient i serwer są na różnych buildach

To przyczyna w zdecydowanej większości przypadków. Steam aktualizuje klientów graczy automatycznie, zwykle w chwili wydania łatki. Serwer już nie: działa dalej w wersji, z którą został wdrożony. W dniu, gdy The Indie Stone wypuszcza nowy build, wieczorem wszyscy gracze są na nim, a serwer nadal działa na zeszłotygodniowym, więc sumy kontrolne przestają się zgadzać i nikt nie może dołączyć.

Lukę można zamknąć na dwa sposoby, a wystarczy ci jeden z nich.

Przesuń serwer do przodu (zalecane)

Na serwerze Project Zomboid hostowanym u nas otwórz zakładkę Wersja gry w panelu. Pokazuje ona wersję, na której działa serwer, a gdy opublikowano nowszą stabilną łatkę, oferuje aktualizację jednym kliknięciem. Aktualizacja łatki zachowuje ten sam plan, więc twój świat, twój servertest.ini i twoje ustawienia przetrwają ją. Wymieniane są tylko pliki gry.

W tej samej zakładce możesz włączyć "zawsze uruchamiaj najnowszą wersję". Serwer sam śledzi nowe stabilne wydania i już nigdy nie zostaje w tyle za graczami. To ustawienie warto wybrać, jeśli wolisz w ogóle o tym nie myśleć, i właśnie dlatego ten błąd jest w dużej mierze rozwiązanym problemem dla naszych klientów. Warto znać kompromis: automatyczna aktualizacja może przyjść, zanim zaktualizuje się mod, na którym ci zależy, dlatego mocno modowane społeczności czasem wolą aktualizować ręcznie po sprawdzeniu listy modów.

Albo cofnij klienta

Czasem celowo chcesz, by serwer został tam, gdzie jest: długo działający świat albo lista modów przypięta do konkretnego builda. W takim przypadku gracz przypina zamiast tego swojego klienta. W Steam kliknij prawym na Project Zomboid, otwórz Właściwości → Wersje gry i bety i wybierz wersję pasującą do serwera: legacy41 dla serwera Build 41, domyślną wersję publiczną aktualnego stabilnego Build 42 albo konkretną starszą łatkę, jeśli Steam ją jeszcze wyświetla. Klient pobierze ten build i sumy kontrolne znów się zgodzą.

Warto powiedzieć wprost, bo ludzie tracą na tym godziny: klient Build 42 nie może dołączyć do serwera Build 41, i żadne ustawienie po żadnej stronie tego nie zmienia. Oba buildy są na tyle oddalone, że w multiplayerze to praktycznie różne gry. Jeśli grupa jest podzielona, wybierz build i przenieś na niego wszystkich. Nasze plany obejmują oba, zobacz wymagania serwera, by porównać je ze sobą.

Przyczyna 2: mody Workshop są niezsynchronizowane

Drugą przyczyną są mody i zachowują się dokładnie tak samo: element Workshop zaktualizowany po jednej stronie, a po drugiej nie. Autorzy modów publikują według własnego harmonogramu, Steam natychmiast przekazuje aktualizację subskrybującym graczom, a działający serwer trzyma kopię pobraną przy starcie. Wystarczy jeden gracz, który nie skończył pobierania, albo serwer, który nie był restartowany od aktualizacji, by wywołać niezgodność.

• Zrestartuj serwer po fali aktualizacji Workshop. Mody są pobierane podczas uruchamiania, więc to restart ściąga aktualne wersje. Zrobienie tego przed sesją, a nie w jej trakcie, unika całego problemu.
• Poproś dotkniętego gracza, aby odsubskrybował i ponownie zasubskrybował mody. Odsubskrybuj mody serwera, daj Steam minutę na faktyczne usunięcie plików, a potem zasubskrybuj je ponownie i poczekaj na zakończenie pobierania przed dołączeniem. Połowicznie pobrany mod daje dokładnie ten błąd.
• Sprawdź, czy mod jest po stronie serwera poprawnie wpisany. Każdy mod potrzebuje numerycznego ID z Workshop w WorkshopItems oraz tekstowego Mod ID w Mods. Nasz Przewodnik po modach Steam Workshop szczegółowo opisuje tę parę, a Menedżer modów w panelu zapisuje oba za ciebie.
• Podejrzewaj najpierw najnowszy dodatek. Jeśli błąd pojawił się zaraz po dodaniu moda, usuń go, zrestartuj serwer i sprawdź, czy dołączanie działa. Niektóre elementy Workshop zawierają pliki, które nigdy nie trafiają czysto do klienta.

Przyczyna 3: uszkodzone lub połowicznie zaktualizowane pliki klienta

Rzadsze, ale łatwe do wykluczenia. Jeśli jeden konkretny gracz dostaje błąd, a reszta na tym samym buildzie dołącza bez problemu, to jego lokalna instalacja jest tą odstającą. Niech otworzy Steam, kliknie prawym na Project Zomboid i użyje Właściwości → Zainstalowane pliki → Sprawdź integralność plików gry. Steam ponownie pobierze wszystko, co się nie zgadza, w tym plik Lua pozostawiony po przerwanej aktualizacji. Jeśli sama weryfikacja nie pomoże, usunięcie folderu media/lua w katalogu gry i ponowna weryfikacja wymuszą czyste pobranie dokładnie tych plików, które obejmuje suma kontrolna.

Przyczyna 4: fałszywy alarm na Linuksie

Istnieje od dawna znany dziwny przypadek, w którym serwer dedykowany na Linuksie może zgłosić niezgodność, mimo że pliki klienta i serwera naprawdę się zgadzają. Serwery dedykowane, w tym nasze, działają na Linuksie, więc warto wiedzieć, że to istnieje. To nie jest częsty przypadek, więc wnioskuj o nim dopiero po powyższych sprawdzeniach: ten sam build po obu stronach, zsynchronizowane mody, zweryfikowane pliki klienta, a błąd i tak się pojawia.

To sytuacja, w której wyłączenie sprawdzenia jest słusznym wyborem, a nie skrótem, bo nie ma już nic do naprawy: pliki się zgadzają, a porównanie jest błędne.

Ostateczność: wyłączenie DoLuaChecksum

Ustawienie DoLuaChecksum=false wyłącza porównanie, więc serwer przestaje odrzucać klientów z powodu różnic w plikach. To obejście, które znajdziesz cytowane wszędzie, i naprawdę działa.

Na serwerze hostowanym u nas nie musisz nic edytować ręcznie: otwórz zakładkę Ustawienia serwera i wyłącz Sprawdzanie plików Lua w sekcji Dostęp i admin. Panel zatrzymuje serwer, zapisuje ustawienie i go restartuje. Project Zomboid nadpisuje własną konfigurację przy zamykaniu, dlatego zmianę trzeba wprowadzić właśnie w ten sposób. Hostujesz sam? Ta linia znajduje się w servertest.ini:

DoLuaChecksum=false

Zanim to zrobisz, zastanów się, co tracisz. Ta weryfikacja pilnuje, aby każda sesja działała na identycznym kodzie. Po jej wyłączeniu:

• Prawdziwe niezgodności przechodzą. Zamiast czystego odrzucenia przy wejściu dostajesz desynchronizacje, przedmioty zachowujące się inaczej u różnych graczy i awarie klienta w trakcie sesji. Diagnozowanie tego jest znacznie trudniejsze niż błędu, który przed chwilą zniknął z ekranu.
• Zmodyfikowane pliki klienta nie są już wykrywane. Ta weryfikacja wykrywa też gracza, który uruchamia zmodyfikowany Lua. Na publicznym serwerze ma to znaczenie.
• Nie likwiduje prawdziwych różnic wersji. Wyłączenie sprawdzenia na mocno nieaktualnym serwerze nie sprawi, że stary serwer zacznie działać z nowym klientem. Tylko zamienia czytelny komunikat na nieprzewidywalne zachowanie. Między Build 41 a Build 42 w ogóle nie pomaga.

Szczera rekomendacja: używaj tego przy fałszywym alarmie na Linuksie albo jako tymczasowe odblokowanie, żeby grupa mogła zagrać dziś wieczorem, dopóki nie uporasz się z prawdziwą niezgodnością, a potem włącz to z powrotem. To poprawne narzędzie, tylko nie pierwsze, po które warto sięgnąć.

Jak zapobiec ponownemu wystąpieniu

• Niech serwer nadąża za grą. Włącz "zawsze uruchamiaj najnowszą wersję" w zakładce Wersja gry, a najczęstsza przyczyna tego błędu przestanie istnieć.
• Restartuj przed sesjami, a nie w ich trakcie. Restart pobiera aktualizacje modów z Workshop. Zaplanowanie go przed czasem gry grupy zapobiega rozjazdom modów w trakcie wieczoru.
• Ustal listę modów. Im więcej modów, tym więcej niezależnych harmonogramów aktualizacji, na które jesteś narażony. Społeczności, które aktualizują mody celowo, partiami, mają z tym znacznie mniej problemów niż te, które dodają mody bez przerwy.
• Ustal jeden build w grupie. Ustal z grupą, czy gracie w Build 42 czy Build 41, i upewnij się, że każdy gracz ma odpowiednią gałąź Steam.

Serwer, który sam utrzymuje zgodność

Każdy serwer Project Zomboid wdrożony na Flux ma narzędzia, na których opiera się ten poradnik: Zakładka Wersja gry do aktualizacji łatek jednym kliknięciem i automatycznego śledzenia najnowszej wersji, edytor Ustawienia serwera z sprawdzaniem plików Lua wystawionym jako zwykły przełącznik, Menedżer modów, który sam rozpoznaje ID z Workshop i Mod ID, a do tego RCON, konsolę, przeglądarkę plików i backupy. Wdrożenie zajmuje około 30 sekund, z dedykowanymi zasobami i ochroną DDoS, w sieci węzłów w 50+ krajach. Aktualne plany pokazuje sekcja cen, a jeśli serwer jeszcze nie działa, pomoże przewodnik konfiguracji.

FAQ

Co oznacza "plik nie zgadza się z plikiem na serwerze"?

Serwer porównał pliki Lua i skryptów, które wczytał twój klient, z własnymi, znalazł różnicę i odrzucił połączenie. Wskazany plik to tylko pierwsza znaleziona różnica, a nie przyczyna.

Jak to naprawić?

Doprowadź obie strony do tego samego builda. Zaktualizuj serwer w zakładce Wersja gry (albo włącz automatyczne aktualizacje) lub przypnij klienta do builda serwera w Steam, w sekcji Właściwości → Wersje gry i bety. Jeśli buildy już się zgadzają, ponownie zsynchronizuj mody Workshop i zweryfikuj pliki gry klienta.

Czym jest DoLuaChecksum?

Ustawienie serwera, domyślnie włączone, które wykonuje to sprawdzenie. Ustawienie na false je wyłącza. Na Flux to przełącznik Sprawdzanie plików Lua w zakładce Ustawienia serwera.

Czy bezpiecznie to wyłączyć?

To obejście, a nie naprawa. Przepuszcza naprawdę niezgodne lub zmodyfikowane pliki klienta, zamieniając czyste odrzucenie na desynchronizacje i awarie. To właściwe rozwiązanie fałszywego alarmu na Linuksie, a w innych przypadkach rozsądne tymczasowe odblokowanie.

Czy klient Build 42 może dołączyć do serwera Build 41?

Nie, i żadne ustawienie serwera tego nie zmienia. Wszyscy muszą być na tym samym buildzie: przenieś serwer na Build 42 albo niech gracze przełączą się na gałąź legacy41 w Steam.

Wdróż serwer Project Zomboid, który aktualizuje się sam →