How to Change the Playstyle on a Project Zomboid Server (Build 42)

To change a Project Zomboid dedicated server’s playstyle, stop the server, edit its sandbox Lua file (normally servertest_SandboxVars.lua), save a valid copy, and restart. The sandbox file controls zombies, loot, time, utilities, XP, vehicles, farming and weather. Server-wide rules such as player slots, PvP, passwords, mods and the map remain in servertest.ini. On an existing save, some world-bound changes may require a new world before their full effect appears.

Prefer not to run the server on your own PC? Godlike.Host offers hosted Project Zomboid servers with free DDoS protection and up to three free backups a day.

What “playstyle” means on a Project Zomboid server

Project Zomboid does not expose one official server setting called “playstyle.” Hosting documentation uses the term for the combined effect of sandbox values and a smaller group of server options. In practice, a server’s feel comes from two files:

#	Preview	Product	Price
1		Zombicide 2nd Edition Strategy Board Game | Cooperative Game for Teens and Adults | Zombie Board...		Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

The default server name is servertest. If the server was launched with -servername MyServer, the files use that name instead, such as MyServer_SandboxVars.lua and MyServer.ini. Every configuration file must use the same server name; uploading a file with the wrong name causes the server to ignore it.

Choose the kind of change you need

World difficulty and pacing

Change the sandbox file when you want to alter zombie numbers or senses, loot scarcity, loot respawn, the length of a day, utility shutoff timing, XP gain, vehicle availability, farming, weather or the starting date. These values shape whether the server feels like a forgiving builder world, a normal survival game or a harsh apocalypse.

#1 Best Overall

Zombicide 2nd Edition Strategy Board Game | Cooperative Game for Teens and Adults | Zombie Board Game | Ages 14+ | 1-6 Players | Avg. Playtime 1 Hour | Made by CMON

• UPDATED CLASSIC: Dive into Zombicide: 2nd Edition, the thrilling update to the classic zombie-slaying game. Experience enhanced gameplay and new challenges in the zombie apocalypse.
• COOPERATIVE SURVIVAL: Join forces as Survivors in a world overrun by zombies. Work together to navigate through missions, complete objectives, and fight for survival.
• ADRENALINE-POWERED ACTION: With each zombie kill, increase your Adrenaline Points. Gain strength and skills but attract more zombies with your actions – a double-edged sword.
• INTENSE MISSIONS: Face a series of challenging missions, each requiring strategic planning, teamwork, and bravery. Can you accomplish your objectives while fending off the undead?
• SURVIVE OR BECOME ZOMBIE PREY: The stakes are high - will you emerge as a triumphant survivor or fall victim to the relentless zombie hordes?

Buy on Amazon

Social and access rules

Change servertest.ini for player-versus-player behavior, the maximum player count, password and public-listing settings, spawn and map choices, enabled mods, RCON and anti-cheat options. These are server-level rules rather than sandbox difficulty.

Why changing only one file can disappoint

Setting PvP to false does not make zombies less dangerous, and increasing loot does not increase the player cap. Decide first whether you are changing the simulated world, the multiplayer rules, or both, then edit the corresponding file.

Find the configuration files

Linux

Dedicated-server files are normally under:

~/Zomboid/Server/

Look for the matching <servername>_SandboxVars.lua and <servername>.ini files. For the default name, that is servertest_SandboxVars.lua and servertest.ini.

Windows

On Windows, the usual location is:

C:UsersYOURNAMEZomboidServer

Replace YOURNAME with the Windows account that runs the server. A hosted panel may expose the same files through a file manager rather than a local path; the names and editing rules are unchanged.

When the files are missing

Start the server once and stop it cleanly. The first run normally creates the server configuration and world directories. If you intentionally use a custom server name, verify that the launch parameter and every configuration filename agree.

Safe procedure for changing playstyle

1. Record the current state. Note the server name, game build, active mods and whether you are keeping the current world. Make a copy of both configuration files and, ideally, a backup of the save.
2. Stop the server completely. Use the host’s Stop control or the server console and wait until the process exits. Do not edit while the process is still running.
3. Open the correct file. Use <servername>_SandboxVars.lua for world rules and <servername>.ini for multiplayer/server rules. The sandbox file is Lua; it is not an INI file.
4. Change only the values you understand. Preserve the existing braces, commas, quotation marks and nested tables. Important groups include structures such as ZombieConfig, MultiplierConfig, Map and Basement.
5. Save a reversible copy. Keep the original under a dated name outside the active configuration set, so the server does not mistake the backup for another live profile.
6. Start the server. A syntax error can prevent startup; it will not reliably fall back to safe defaults.
7. Verify in game. Check the resulting world and, where appropriate, use administrator commands to display options. Confirm the setting on a test world before applying a major change to a long-running community save.

A simpler supported workflow is to configure a sandbox once through the in-game host screen, let the game generate the files, then copy those generated files to the dedicated server. This reduces the risk of guessing a Build 42 variable name.

Editing the sandbox Lua file without breaking it

A sandbox file is a Lua table. It commonly begins and ends with braces and contains comma-separated key/value pairs. Keep that structure intact. A missing comma, an extra brace or a misspelled key can stop the server from starting.

• Use a plain-text or code editor rather than a word processor.
• Do not convert quotation marks into typographic “smart” quotes.
• Do not delete an enclosing table simply because you are changing one value inside it.
• Change one small group at a time and start the server after each group if you are troubleshooting.
• Keep a copy of the file generated by your own Build 42 installation; setting names can differ between 42.19, 42.20, 42.21 and later patches.

Because no official Build 42 reference for every variable and default is established here, the safest source for exact key names is the file generated by your own server or the in-game host configuration screen. Do not paste a variable copied from an older build unless it already exists in your file and its nesting matches.

Build a playstyle by adjusting the main sandbox dimensions

Zombie population and behavior

Zombie population determines pressure on every trip outside a safehouse. Behavior and sensory settings determine how quickly zombies detect, pursue and retain a target. A low-population builder world can still become dangerous if sight, hearing or memory values are aggressive. Change population and behavior together, then test a fresh area rather than judging the result only inside an already-cleared base.

Loot rarity and respawn

Loot rarity controls how often useful supplies appear; respawn controls whether searched containers refill over time. These are separate levers. Abundant loot with no respawn creates an easy opening followed by scarcity, while scarce loot with frequent respawn changes the value of exploration and long-term base planning.

Build 42 documentation is inconsistent about the exact location of respawn controls. One guide places respawn options in the sandbox file; another advises setting HoursForLootRespawn=0 in the INI and LootRespawn=1 in the sandbox file. Verify which keys your generated files contain before changing anything. Do not add both versions blindly.

Day length and starting date

Short days accelerate every schedule: travel, cooking, construction, farming and combat. One hosting guide advises avoiding day lengths below roughly 30 minutes because farming becomes impractical. Treat that as a practical warning rather than a game rule; choose a longer cycle if players need time for a cooperative routine, and test the setting with the farming calendar your group intends to use.

Water and electricity shutoff

Utility shutoff timing changes the urgency of collecting fuel, generators, water containers and preservation equipment. Shortening the timing produces a harder apocalypse even without increasing zombie density. Because utility state is tied to world progression, changing it on an established save may not recreate the early-game experience; a new world is the reliable way to evaluate a radically different schedule.

Experience multipliers

XP multipliers affect how quickly players gain levels in skills. Higher values make a short co-op season more forgiving; lower values make every action and specialist role matter for longer. Multipliers can also magnify the effect of other changes: a high construction multiplier combined with abundant materials removes much of the intended preparation loop.

Vehicles, farming and weather

Vehicle availability changes travel and hauling. Farming settings control how demanding food production is. Weather alters visibility, temperature and the risk of spending time outdoors. Adjust these as a package: a server with scarce loot but plentiful vehicles may still be easy because long-distance scavenging is cheap, while harsh weather can make the same map substantially more demanding.

Configure multiplayer rules in servertest.ini

Some casual co-op examples use a small player cap, disabled PvP, pausing when empty, disallowed sleep and an enabled safety system. Those values are an example from a third-party guide, not a universal recommendation. Confirm each variable in your own generated INI before using it.

Builder, survival and apocalypse-style setups

Builder-style co-op

Start with low zombie pressure, generous loot and enough daylight for construction and farming. Keep PvP disabled if the group is cooperative, set a player cap that matches the intended group, and decide explicitly whether the server should pause when empty. Do not assume that “builder” is one preset; it is a balance of scarcity, time and social rules.

Standard survival

Use moderate zombie population and senses, ordinary loot scarcity, a day length that leaves time for travel, and utility failures that force preparation without ending the first week. Keep XP multipliers near the values generated by your selected sandbox profile unless the group has a clear reason to speed progression.

Hard apocalypse

Increase zombie density or senses, reduce useful loot, shorten utility shutoff timing and make travel more expensive through vehicle and weather choices. Change one difficulty axis at a time on an existing community world; otherwise players cannot tell which adjustment caused a new failure. For the full effect of world-bound changes, create a fresh world.

Can you change playstyle without restarting?

Administrators commonly mention showoptions and reloadoptions. Command syntax varies: some consoles and guides use a leading slash, while others use the bare command. The guides also disagree about whether reloadoptions rereads servertest.ini, another file such as ServerOptions.ini, or sandbox values at all.

Use live reload only as a cautious check for options your server explicitly reports. It is not a dependable substitute for a clean restart, especially for world-bound or mod-related settings. The safe sequence remains: stop, edit, start, then verify. If a value appears unchanged, restart again and test on a new world before concluding that the key is wrong.

Existing world versus new world

A configuration file can contain a new value while the current map still reflects state already generated. Changing a setting on a live save may therefore show only a partial effect. World-bound systems, previously generated cells, utility progression and mod changes are the most likely to require a clean restart or a new world.

• Keep the old save when the change is mainly an administrative rule, such as a password or player cap.
• Test a new world when changing the overall difficulty, zombie distribution, utility timeline, map or a major mod set.
• Tell players whether the change applies prospectively, only in unexplored areas, or after a wipe.
• Never delete the old world before verifying that the new configuration starts and that players can connect.

Troubleshooting failed changes

The server will not start

Restore the last known-good backup, then inspect the most recent edit for a missing comma, brace or quotation mark. Confirm that the file is valid Lua and that you did not save it as a rich-text document. Reapply changes one at a time.

The server starts but ignores the setting

Check that you edited the active server name, not servertest while the launch command uses another name. Confirm that the setting belongs in the sandbox file rather than the INI. Restart cleanly and test an ungenerated area or a new world.

Players cannot connect after an edit

Review port, password, public-listing, map and mod fields in servertest.ini. A sandbox change normally should not alter connection details, so a connection failure after editing may indicate that the wrong file was uploaded or that a server-name mismatch caused an older configuration to be loaded.

Loot behavior is inconsistent

Check the exact Build 42 file generated by your installation. Respawn keys are reported in conflicting locations, and variable names differ across builds. Remove duplicate or guessed entries, restore the generated structure, and change only the key your file already defines.

Commands produce no result

Try the syntax expected by your console or RCON interface, with and without the slash prefix if that interface documents both forms. Treat showoptions as a diagnostic, not proof that every sandbox value can be reloaded live.

A repeatable change checklist

• Identify the active server name and Build 42 patch.
• Back up the sandbox file, INI and world save.
• Stop the process and wait for a clean shutdown.
• Edit Lua for world rules and INI for multiplayer rules.
• Preserve nested tables and punctuation.
• Change only keys present in files generated by your installation.
• Restart and inspect the console for syntax or mod errors.
• Verify the result in game or with administrator diagnostics.
• Use a fresh world when the setting is world-bound or the old map masks the change.
• Record the final values so players know what changed.

What is confirmed—and what is still version-sensitive

The file split, file locations, need to stop before editing and the possibility of requiring a fresh world are consistent across the available dedicated-server guidance. Exact Build 42 variable names and defaults are not established by an official developer reference here. Guides cite different 42.x builds, disagree about loot-respawn placement and do not agree on the scope of live reload. Treat the files generated by your own server as authoritative for syntax, and regard copied presets as starting points rather than guaranteed profiles.

Quick Recap

Bestseller No. 1

Zombicide 2nd Edition Strategy Board Game | Cooperative Game for Teens and Adults | Zombie Board Game | Ages 14+ | 1-6 Players | Avg. Playtime 1 Hour | Made by CMON

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Build 42Dedicated ServerProject Zomboidsandbox settingsserver administration