Gidsen / Probleemoplossing

Project Zomboid: hoe los je "File Does Not Match the One on the Server" op

Het is de meest frustrerende manier om een sessie te beëindigen voordat hij begint: iedereen zit in de Discord-call, iemand klikt op Join, en Project Zomboid gooit ze meteen weer eruit met een bestand dat volgens de melding niet overeenkomt met dat op de server. Er is niets kapot, de server doet precies wat hij moet doen. Deze gids legt uit wat de controle precies vergelijkt, waarom hij afgaat, hoe je elke oorzaak goed oplost, en wanneer het redelijk is om hem uit te zetten met DoLuaChecksum.

Wat de fout echt betekent

Wanneer een client verbinding maakt, vergelijkt de Project Zomboid-server de checksum van de Lua- en scriptbestanden die de client heeft geladen met zijn eigen. Als één bestand verschilt, wordt de verbinding geweigerd en ziet de speler een melding met de naam van dat bestand: "bestand komt niet overeen met het bestand op de server", of een verwant bestand zoals "bestand bestaat niet op de client" en "Lua/script-checksums komen niet overeen".

De controle wordt geregeld door de serverinstelling DoLuaChecksum, die standaard standaard ingeschakeld is. De taak is garanderen dat iedereen in de sessie dezelfde code draait: identieke gamebestanden en identieke mods. Dat is belangrijk omdat Project Zomboid veel van zijn logica in Lua aan beide kanten draait. Een client met andere bestanden ziet dus niet simpelweg iets een beetje anders: hij desynct, gooit fouten en kan wat hij terugschrijft naar de wereld beschadigen.

Daar volgen twee dingen uit, en die besparen veel verspilde tijd:

• Het bestand dat wordt genoemd is zelden het probleem. Het is gewoon het eerste verschil dat de vergelijking tegenkwam. Dat specifieke bestand najagen leidt nergens heen; kijk liever of waarom de twee kanten sowieso verschillende bestanden hebben.
• Het is een symptoom, geen fout. Iets aan één kant is een andere versie. Zoek welke kant is weggedreven, en de fout verdwijnt vanzelf.

Oorzaak 1: de client en de server draaien op verschillende builds

Dit is de oorzaak in de overgrote meerderheid van de gevallen. Steam werkt spelersclients automatisch bij, meestal op het moment dat een patch uitkomt. Een server doet dat niet: hij draait de versie waarmee hij is gedeployd. De dag dat The Indie Stone een nieuwe build uitbrengt, staat iedere speler er tegen de avond op en staat de server nog op die van vorige week. De checksums komen dan niet meer overeen en niemand kan joinen.

Er zijn twee manieren om de kloof te dichten, en je hebt er maar één nodig.

Zet de server vooruit (aanbevolen)

Op een Project Zomboid-server die bij ons gehost wordt, open je het tabblad Game Version in het dashboard. Het toont de versie waarop de server draait en, als er een nieuwere stabiele patch is verschenen, biedt het een update met één klik. Een patchupdate houdt hetzelfde abonnement, dus je wereld, je servertest.ini en je instellingen blijven behouden; alleen de gamebestanden worden vervangen.

In hetzelfde tabblad kun je "altijd de nieuwste versie draaien" aanzetten. De server volgt dan nieuwe stabiele releases vanzelf en blijft nooit meer achter op je spelers. Dat is de instelling om te gebruiken als je er liever helemaal niet over nadenkt, en de reden dat deze fout voor onze klanten grotendeels een opgelost probleem is. De afweging is het weten waard: een automatische update kan binnenkomen terwijl een mod waar je op vertrouwt nog niet is bijgewerkt, dus gemeenschappen met veel mods updaten soms liever handmatig na het controleren van hun modlijst.

Of zet de client terug

Soms wil je bewust dat de server blijft waar hij is, bijvoorbeeld bij een langlopende wereld of een modlijst die is vastgezet op een specifieke build. In dat geval zet de speler zijn client vast. Klik in Steam met de rechtermuisknop op Project Zomboid, open Properties → Game Versions & Betas, en kies de versie die bij de server past: legacy41 voor een Build 41-server, de standaard publieke versie voor de huidige stabiele Build 42, of een specifieke oudere patch als Steam er nog een toont. De client downloadt die build en de checksums komen weer overeen.

Het is het vermelden waard, want mensen verliezen er uren aan: een Build 42-client kan niet joinen op een Build 41-server, en geen enkele instelling aan beide kanten verandert dat. De twee builds liggen ver genoeg uit elkaar dat het in multiplayer effectief verschillende spellen zijn. Als je groep verdeeld is, kies dan een build en laat iedereen erop overgaan. Onze abonnementen dekken beide; zie de serververeisten voor hoe de twee zich tot elkaar verhouden.

Oorzaak 2: Workshop-mods lopen uit de pas

De tweede oorzaak zijn mods, en die gedraagt zich precies hetzelfde: een Workshop-item dat aan één kant is bijgewerkt en aan de andere niet. Modauteurs publiceren op hun eigen schema, Steam pusht de update meteen naar geabonneerde spelers, en een draaiende server houdt de kopie die hij bij het opstarten downloadde. Eén speler die het downloaden nog niet heeft afgerond, of een server die niet opnieuw is opgestart sinds de update, is genoeg om de mismatch te veroorzaken.

• Herstart de server na een golf Workshop-updates. Mods worden tijdens het opstarten opgehaald, dus een herstart haalt de huidige versies binnen. Dat vóór een sessie doen in plaats van tijdens een sessie voorkomt het hele probleem.
• Laat de getroffen speler zich afmelden en opnieuw aanmelden. Meld je af van de mods van de server, geef Steam even een minuut om de bestanden echt te verwijderen, abonneer je daarna weer en wacht tot de download klaar is voordat je joint. Een half gedownloade mod geeft precies deze fout.
• Controleer of de mod server-side correct is vermeld. Elke mod heeft zijn numerieke Workshop-ID nodig in WorkshopItems en zijn tekstuele Mod ID in Mods. Onze Steam Workshop-modsgids behandelt dat paar uitgebreid, en de Mod Manager van het dashboard schrijft beide voor je.
• Verdenk eerst de nieuwste toevoeging. Als de fout begon net nadat een mod was toegevoegd, verwijder die, herstart en kijk of joinen dan lukt. Sommige Workshop-items bevatten bestanden die nooit netjes bij de client aankomen.

Oorzaak 3: beschadigde of half bijgewerkte clientbestanden

Minder vaak, maar makkelijk uit te sluiten. Als één specifieke speler de fout krijgt terwijl iedereen op dezelfde build wel goed joint, is hun lokale installatie de uitzondering. Laat hem Steam openen, met de rechtermuisknop op Project Zomboid klikken en Properties → Installed Files → Verify integrity of game files gebruiken. Steam downloadt opnieuw alles wat niet overeenkomt, inclusief een Lua-bestand dat is achtergebleven door een onderbroken update. Als verifiëren alleen niet helpt, verwijder dan de map media/lua in de spelmap en verifieer opnieuw, zodat precies de bestanden die de checksum dekt schoon opnieuw worden gedownload.

Oorzaak 4: het Linux-foutpositief

Er is een al lang bestaande eigenaardigheid waarbij een Linux dedicated server een mismatch kan melden, terwijl de client- en serverbestanden echt overeenkomen. Dedicated servers, ook die van ons, draaien op Linux, dus het is goed om te weten dat dit bestaat. Het is niet het gangbare geval, en je moet pas tot die conclusie komen nadat je de checks hierboven hebt gedaan: dezelfde build aan beide kanten, mods opnieuw gesynchroniseerd, clientbestanden geverifieerd, en de fout komt nog steeds.

Dit is de situatie waarin de controle uitzetten de juiste keuze is en geen shortcut, omdat er niets meer te repareren valt: de bestanden kloppen en de vergelijking is fout.

Het laatste redmiddel: DoLuaChecksum uitzetten

DoLuaChecksum=false zet de vergelijking uit, zodat de server clients niet meer weigert vanwege bestandsverschillen. Het is de tijdelijke oplossing die je overal aangehaald ziet, en hij werkt echt.

Op een server die bij ons gehost wordt hoef je niets met de hand te bewerken: open het tabblad Server Settings en zet Lua File Check onder Access & Admin uit. Het dashboard stopt de server, schrijft de instelling en start hem opnieuw op. Project Zomboid herschrijft zijn eigen config bij het afsluiten, daarom moet de wijziging zo worden toegepast. Zelf hosten? De regel staat in servertest.ini:

DoLuaChecksum=false

Voordat je dat doet, begrijp wat je opgeeft. De controle zorgt ervoor dat elke sessie exact dezelfde code draait. Zonder die controle:

• Echte mismatches komen erdoorheen. In plaats van een schone kick bij de deur krijg je desyncs, items die voor verschillende spelers anders werken, en clientcrashes midden in een sessie. Dat is veel lastiger te diagnosticeren dan de fout die je net hebt gedempt.
• Gewijzigde clientbestanden worden niet meer gedetecteerd. De controle is ook het ding dat merkt of een speler gewijzigd Lua draait. Op een publieke server doet dat ertoe.
• Het overbrugt geen echte versieverschillen. De controle uitschakelen op een ernstig verouderde server maakt een oude server niet compatibel met een nieuwe client. Het verplaatst alleen de fout van een duidelijke melding naar onvoorspelbaar gedrag. Tussen Build 41 en Build 42 helpt het helemaal niet.

Het eerlijke advies: gebruik hem voor het Linux-foutpositief, of als tijdelijke ontgrendeling zodat je groep vanavond kan spelen terwijl je de echte mismatch oplost, en zet hem daarna weer aan. Het is een geldig hulpmiddel, alleen niet het eerste dat je moet pakken.

Hoe voorkom je dat het opnieuw gebeurt

• Laat de server het spel volgen. Zet "altijd de nieuwste versie draaien" aan op het tabblad Game Version, en de meest voorkomende oorzaak van deze fout bestaat niet meer.
• Herstart vóór sessies, niet tijdens. Een herstart is wat Workshop-modupdates ophaalt. Plan die vóór de speeltijd van je groep, dan blijft moddrift uit je avond.
• Maak de modlijst definitief. Hoe meer mods, hoe meer onafhankelijke updateschema's je blootstaat. Gemeenschappen die mods bewust in batches bijwerken, merken dit veel minder dan gemeenschappen die continu mods toevoegen.
• Kies één build. Beslis als groep of het Build 42 of Build 41 wordt, en zorg dat elke speler op de bijpassende Steam-branch zit.

Een server die zichzelf gelijk houdt

Elke Project Zomboid-server die op Flux wordt gedeployd, komt met de tools waar deze gids op rekent: een tabblad Game Version voor patchupdates met één klik en automatisch bijhouden van de nieuwste versie, een Server Settings-editor met de Lua file check als gewone schakelaar, een Mod Manager die Workshop- en Mod-ID's voor je oplost, plus RCON, een console, een bestandsbrowser en backups. Deployen duurt ongeveer 30 seconden, met dedicated resources en DDoS-bescherming op een netwerk van nodes in 50+ landen. Zie de prijsgedeelte voor de huidige abonnementen, of de installatiegids als je server nog niet online is.

FAQ

Wat betekent "file does not match the one on the server"?

De server vergeleek de Lua- en scriptbestanden die jouw client heeft geladen met de zijne, vond een verschil en weigerde de verbinding. Het genoemde bestand is alleen het eerste gevonden verschil, niet de oorzaak.

Hoe los ik het op?

Zet beide kanten op dezelfde build: werk de server bij via het tabblad Game Version (of zet automatische updates aan), of zet de client vast op de build van de server in Steam onder Game Versions & Betas. Als de builds al gelijk zijn, synchroniseer dan de Workshop-mods opnieuw en verifieer de gamebestanden van de client.

Wat is DoLuaChecksum?

De serverinstelling, standaard aan, die deze controle uitvoert. Die op false zetten schakelt hem uit. Op Flux is het de Lua File Check-schakelaar in het tabblad Server Settings.

Is het veilig om het uit te zetten?

Het is een tijdelijke oplossing, geen echte fix. Het laat echt verschillende of bewust gewijzigde clientbestanden door, en ruilt een schone kick in voor desyncs en crashes. Het is het juiste antwoord voor het Linux-foutpositief, en een redelijke tijdelijke ontgrendeling in andere gevallen.

Kan een Build 42-client joinen op een Build 41-server?

Nee, en geen enkele serverinstelling verandert dat. Iedereen moet op dezelfde build zitten: zet de server op Build 42, of laat spelers in Steam naar de legacy41-branch overschakelen.

Deploy een Project Zomboid-server die zichzelf bijwerkt →