7 Days to Die 3.0 Settings: What Changed for Server Owners

If an old serverconfig.xml guide tells you to set XPMultiplier, GameDifficulty or BloodMoonFrequency, pause before copying it. In V3.0, The Fun Pimps moved 30 gameplay settings out of separate XML properties and into SandboxCode. The XML file still handles server and world setup; the gameplay rules now come from the code. This guide lists the historical keys and gives you a safe way to recreate the rules you want using the Sandbox Options available in your current build.

The version boundary matters. The dedicated server’s public and v3.4.0 Stable branches were both at build 26167630 when checked on October 28, 2026; the latest_experimental branch pointed to that build as well. These branches can change. Match the clients and server to a compatible build and check its current options before you edit a world. For an overview of the current XML versus code split, see our 7 Days to Die server settings reference. If you prefer named controls to editing code by hand, the Game Hosting 7 Days to Die panel includes a friendly SandboxCode editor.

Which 30 old XML gameplay settings changed in V3.0?#

The official V3.0 release notes list 30 legacy gameplay properties that were removed or converted as the game moved those choices into SandboxCode. The names below are useful when you recognize them in an older config or tutorial. They are historical property names, not a current V3.4 XML schema and not a complete map of each new option label.

Group	Legacy properties listed in the V3.0 notes
Difficulty, damage and progression	GameDifficulty, BlockDamagePlayer, BlockDamageAI, BlockDamageAIBM, XPMultiplier, BiomeProgression
Day, weather and death	DayNightLength, DayLightLength, StormFreq, DeathPenalty, DropOnDeath, DropOnQuit, JarRefund
Enemy and zombie behavior	EnemySpawnMode, EnemyDifficulty, ZombieFeralSense, ZombieMove, ZombieMoveNight, ZombieFeralMove, ZombieBMMove, AISmellMode
Blood moon	BloodMoonFrequency, BloodMoonRange, BloodMoonWarning, BloodMoonEnemyCount
Loot and air drops	LootAbundance, LootRespawnDays, AirDropFrequency, AirDropMarker
Quests	QuestProgressionDailyLimit

That list answers “why is this old line missing?” It does not mean every serverconfig property disappeared, or that every listed rule maps one-to-one to a current named control. The release notes say to recreate the old gameplay choices through the Sandbox Options menu and use the generated SandboxCode. Treat each old name as a clue to the rule you meant to set, then choose that rule in the current game.

Find a replacement by the rule you want#

The settings are now presented in Sandbox Options rather than as one XML line per gameplay rule. A versioned catalog from V3.2 gives examples of the kind of translation you may see: XPMultiplier was labeled “XP Multiplier,” ZombieMove “Zombie Day Speed,” DayNightLength “24 Day Cycle,” and LootAbundance “Global Loot Abundance.” Those are V3.2 examples only. Enemy and animal density and respawn choices were split into day and night values in V3.1, so a single old key may not describe the choices available now.

Do not use that short example list as a V3.4 lookup table. The catalog we inspected is from V3.2; we have not verified a complete current V3.4 mapping. In the current build, open Sandbox Options and search by the gameplay outcome you want: XP gain, day length, loot abundance, zombie movement, or blood-moon behavior. Read the option description and select the value there. If a host panel offers a named SandboxCode editor, use it as another way to choose and save those controls; it does not certify that a particular world, mod or client combination is compatible.

Keep server setup in XML and gameplay rules in SandboxCode#

serverconfig.xml remains the place to configure server operation and world setup. This change separates two jobs: XML sets up the dedicated server, while SandboxCode carries gameplay choices that used to appear as individual XML properties. The 30 names in the table above belong to the second group.

If you need to find or edit the active file, use our guide to locating and editing the server config. For a broader list of settings and their version boundaries, see the server settings reference. Check the file shipped with your installed server version before adding or removing any property; an older example cannot establish the current schema.

Rebuild your chosen rules on the current build#

Use this sequence when migrating a server that still has a pre-V3 config or when you are correcting an old tutorial’s settings. It preserves the difference between the gameplay rules you intend and the server properties you still need.

1. Save a separate copy of the active config and world. Confirm which serverconfig.xml the process loads rather than assuming the first file you find is active. Keep the backup outside the live files.
2. Confirm the server build and branch. The build numbers above are a dated check, not a promise about what is available today. Check the current game and server version before using a code created by a different build.
3. Open Sandbox Options in the matching game build. Recreate the rules you want using the current named options. Do not try to translate every old property by guessing at its new label.
4. Copy the generated SandboxCode. The V3.0 notes show the default code AAAJABJACJADJARFBNC, which corresponds to the old Adventurer difficulty value. That is an example of a code, not a recommendation for your world.
5. Set the code in the active server XML and keep the rest of the server setup intact. Avoid replacing the entire file with a sample from another game version.
6. Restart and verify the result. Check the loaded server build and review the intended gameplay options in the game. V3.4 fixed an issue where GetSandboxOptions did not print changed values when printing all options; do not rely on old output behavior without checking the current build’s notes.

The V3.1 Stable notes also warn that an invalid preset code can cause some or all settings to default and provide refreshed official codes. If you are unsure whether your generated code was accepted, stop and verify the selected options in game before inviting the group. Our server port guide covers the network setup separately; it does not affect how gameplay rules are selected.

Check branch and client versions before changing settings#

The dedicated-server branch check for this guide found public and v3.4.0 Stable at build 26167630, with latest_experimental on the same build. The official V3.4 Stable notes were posted October 26, 2026. SteamDB’s dedicated-server branch record is useful for checking which server build a branch currently points to, but branch names and build numbers can move after publication.

V3.1 changed the option shape for some enemy and animal rules by splitting density and respawn into day and night values. That is why an old property name is not enough to infer the current menu. Use the Sandbox Options screen from the build you intend to run, and make sure each player’s client is compatible with the server. For current console crossplay constraints, consult The Fun Pimps’ dedicated-server requirements at the time you configure the server; this guide does not certify crossplay eligibility or a player limit.

Back up first when saves or mods are involved#

Changing gameplay rules does not by itself tell you whether a particular save, overhaul, or mod set will work. The V3.0 and V3.1 notes discuss version-specific behavior, but they do not certify every combination. Before changing branches or settings on a world you care about, make a separate backup and test the transition on a copy. Check the game’s current release notes and the mod author’s compatibility notes for the exact game build and mod version. A panel can make a setting easier to edit, but it cannot establish that a save or third-party overhaul will load correctly.

The practical takeaway is straightforward: recognize the 30 historical gameplay keys, decide which rules you still want, and rebuild those choices through the Sandbox Options for the server’s current build. Keep server-level XML settings in place, preserve a backup, and verify the result before the group resumes play. That gives you a version-aware migration path without treating an old XML snippet as today’s complete settings map.

Frequently asked questions#

What changed in 7 Days to Die 3.0 server settings?

V3.0 moved 30 legacy gameplay settings from separate serverconfig.xml properties to SandboxCode. Server operation and world setup remain in XML. The official release note provides the historical names and says to rebuild those gameplay choices in Sandbox Options.

Do old serverconfig.xml gameplay settings still work as controls?

The 30 properties in this guide were removed or converted as gameplay controls in V3.0. Do not treat an old line as the current way to set that rule. Recreate the desired value in the current Sandbox Options menu and use its SandboxCode; check the server build you actually run.

Where did GameDifficulty go?

GameDifficulty is included in the V3.0 list of properties moved into SandboxCode. The V3.0 notes identify the default code with Adventurer difficulty, but you should choose the difficulty you want in the current Sandbox Options screen rather than copying a code from an older guide.

Sources and version notes#

• The Fun Pimps, V3.0 Dead Hot Summer release notes: removed/converted property list and migration instructions.
• The Fun Pimps, V3.1 and V3.4 Stable news: day/night option changes, invalid-code warning, and V3.4 output fix.
• SteamDB, dedicated-server app branches: branch and build snapshot checked October 28, 2026.
• The Fun Pimps, dedicated-server crossplay requirements: consult the current requirements directly for console groups.

Quick answers

What changed in 7 Days to Die 3.0 server settings?

V3.0 moved 30 legacy gameplay settings from individual serverconfig.xml properties into SandboxCode. Server and world setup still uses serverconfig.xml.

Do old serverconfig.xml gameplay settings still work as controls?

The 30 keys listed here were removed or converted as gameplay controls in V3.0. Recreate the rules in the current Sandbox Options screen and use its SandboxCode value; check the build you actually run.

Where did GameDifficulty go in 7 Days to Die?

GameDifficulty is one of the old gameplay keys moved into SandboxCode. The V3.0 notes show the default code as Adventurer, but choose the difficulty you want in the current Sandbox Options menu.