Game Hosting home

Valheim dedicated server world modifiers: apply them safely

Apply Valheim dedicated server world modifiers with exact arguments, preset-first ordering and a test record that catches overwritten settings.

Difficulty
NormalDifficulty Normal
Time to do
10 min
Reading
9 min
Updated
By
Game Hosting team

You will need

  • Access to the startup script or panel that actually launches the server
  • The manual for the installed dedicated-server build
  • A disposable world or protected test world
  • Permission to stop and restart the server

The reliable order for Valheim dedicated server world modifiers is preset first, then documented modifier exceptions and supported setkeys. The server log can confirm that it accepted the text, but only an in-game check can confirm the resulting world behavior. This guide shows where the effective arguments live, how to write the syntax, and how to keep a short test record. It does not repeat a full server installation or tell you how to change an established world.

For the other server switches, see the reference to native Valheim launch arguments; it separates modifier flags from ports, paths and documented save defaults.

Find the startup line that actually launches the server#

Start by locating the configuration that your server really executes. On a Windows dedicated server, the official guide tells you to edit a copy of start_headless_server.bat; on Linux, the equivalent is a copy of start_server.sh. A managed panel may generate that line for you instead. The important detail is not the filename: it is the final command or argument field used by the running process.

The official dedicated-server manual is the authority for native argument names. Before changing anything, record the current effective line and the world name it starts. If the server is managed by a panel, look for a startup-arguments, launch-parameters or generated-command view. A field that looks editable is not enough if a template rewrites it on the next restart.

Use this quick ownership check:

Hosting route Find this first What proves you found it
Windows self-host The batch file used by the shortcut or service Its launch creates the server log you are reading
Linux self-host The shell script or service ExecStart line Restarting that service changes the same log
Hosting panel The generated startup or arguments field The saved field appears in the next launch record

Do not edit a sample file and assume it is live. If the next launch log never changes, stop and identify the effective script, service or panel template before adding more flags. This guide owns the modifier fragment; a complete installation has different checks.

Put the preset before every exception#

Choose one starting preset, then place individual exceptions after it. The current manual lists these seven preset names: Normal, Casual, Easy, Hard, Hardcore, Immersive and Hammer. A preset is a bundle selected by name, not a shorthand for one slider.

The documented shape is:

text
-preset hard -modifier raids none -setkey nomap

Read that as a fragment to append to the effective argument field, not as a complete server command. It says: start with the hard preset, then apply the raids exception, then enable the nomap key. The manual says the preset overwrites preceding modifiers, so putting -preset hard at the end risks replacing exceptions that appeared before it.

Use the preset as a starting point rather than guessing its complete contents. The official manual names the presets and the accepted argument families, but it does not provide a complete composition table for every bundle. If the group wants a hard combat setting but ordinary resource gathering, write those as separate decisions after the preset and verify the resulting world.

The order is also why you should not scatter duplicate occurrences across a panel field, a script and an environment variable. You need one visible source of truth for the final launch line. If your provider documents a different field, follow its workflow but still compare the resulting arguments with the native syntax.

Add one modifier with an accepted value#

Use -modifier for one documented category at a time. The manual’s accepted values are exact tokens; they are not numeric multipliers and they are not guaranteed descriptions of every gameplay effect. Copy the spelling and case from the current manual supplied with the server build.

Modifier Accepted values
Combat veryeasy, easy, hard, veryhard
DeathPenalty casual, veryeasy, easy, hard, hardcore
Resources muchless, less, more, muchmore, most
Raids none, muchless, less, more, muchmore
Portals casual, hard, veryhard

For example, this is a valid modifier fragment:

text
-modifier Combat hard -modifier Resources more

The category and value are paired. Do not convert a menu label into -modifier Combat normal: normal is documented as a preset name, not as an individual value for every modifier. Likewise, do not paste a provider’s numeric damage, drop-rate or raid-timer claim into the launch line unless the current primary documentation supports it.

Change one category at a time while you are learning a panel or script. If the log accepts the token but the crew cannot identify the expected behavior, record that as “accepted by server; player effect not yet observed.” That is a useful result, not a failed article or a reason to invent a percentage.

Add only the four documented setkeys#

Use -setkey for the native checkbox-style rules documented by Iron Gate. The supported keys are:

Key What to discuss with the crew
nobuildcost Whether this is a construction-focused session and what limits remain
playerevents How the campaign should handle player-based events
passivemobs Whether the group understands how passive creatures behave
nomap How the crew will coordinate exploration without the map

An example with a preset and one key is:

text
-preset casual -setkey passivemobs

Keep these keys separate from permissions. adminlist.txt, admin commands and devcommands answer who can operate the server; a setkey changes a world rule. A community mod can add its own configuration, but that does not make its option a native -setkey.

Search results and provider summaries sometimes add names such as noworkbench, NoPortals or fire. They are not in the current official list used for this guide. An unknown token can be ignored, rejected or handled differently by a provider wrapper, so do not publish it as a supported native setting. If a panel exposes an extra control, identify whether it is a provider feature or a mod and follow that tool’s own documentation.

Run a disposable launch and read the acceptance record#

Test a new fragment away from the only copy of a long-running world. The goal of the first launch is narrow: prove that the effective startup line contains the intended tokens and that the server starts and saves cleanly. It is not proof that every slider produced its expected player-facing behavior.

  1. Record a baseline

    Save the current effective argument line, world name, server build and the exact fragment you plan to add. Use a disposable world when possible. The check is a dated record another operator can read.

  2. Launch with one ordered fragment

    Put the preset first, then one modifier or setkey. Start the server through the real script, service or panel. The check is that the same startup log contains the documented tokens you intended to test.

  3. Read the startup messages

    Look for lines such as Setting world modifier preset: hard and Setting world modifier: raids->none, followed by a successful server connection. The check is acceptance and startup, not an inferred gameplay percentage.

  4. Stop cleanly and save the record

    Shut down through the normal route and keep the log with the fragment. A clean save proves the test ended normally; it does not prove that a player saw no raids or no map.

In a clean Windows headless-server acceptance run on public build 1.0.15, the ordered fragment -preset hard -modifier raids none -setkey nomap produced the preset and modifier log lines before the server connected, and the controlled shutdown completed the world save. Reversing the first two arguments reversed the log order, which is useful evidence for precedence. Neither run was a player-facing effect test.

Restart, verify in-game, and remove duplicates#

Treat a restart as a second check, not as proof that a saved world has the intended active rules. A headless log can show that the world reloaded while still omitting a readable summary of the effective modifiers. The current evidence therefore supports this distinction:

Result What it proves What it does not prove
Startup log accepts token The process recognized the documented argument The player-facing effect is correct
Server connects and saves The test server ran and shut down cleanly No-map, raid or achievement behavior
Client observes the rule The selected behavior appeared in-game Every future restart or panel deployment
Generated line matches rule card after restart The configuration source retained the text That an existing world was safely rolled back

After restarting, have the owner and one client verify the behavior that matters. For nomap, check the actual map experience; for Raids, observe the campaign over an appropriate session instead of promising a timer; for achievement-sensitive goals, read the current warning. The Valheim 1.0 FAQ says some modifiers, including hammer-mode, block certain achievements. It does not provide a universal safe list for every combination.

If the panel rewrites the line, compare its generated output with the rule card. Remove one of two conflicting occurrences rather than relying on a silent last-write rule. Do not treat the world folder’s _main.<N>.fwl2 and _main.<N>.db2 files, an older .db or .fwl save or any other save file as a readable settings report. A world loading after a restart is not proof that an observable effect persisted.

Decide whether manual arguments are worth maintaining#

Finish with a short rule card that another authorized owner can apply:

text
Build: 1.0.15
World: disposable-test
Preset: hard
Modifiers: raids none
Keys: nomap
Observed: startup accepted preset and modifier; client effect pending
Next check: client observation after clean restart
Owner: <name>

For the wider settings decision, understand the world-modifier choices before changing a crew’s rules. C02 is the application syntax and verification record; it is not a catalog of what every preset feels like.

If maintaining an effective startup line is fine, self-hosting remains a valid route. If the group would rather delegate the script, restarts and configuration access, compare current editable Valheim hosting options. Renting changes who maintains the infrastructure; it does not remove the need to agree on modifiers or verify the resulting world.

Quick answers

Does argument order change the result?

Yes. Put the preset first, then add individual modifiers and setkeys; a later preset can overwrite earlier exceptions.

Can a panel overwrite manual modifier arguments?

It can if the panel regenerates the effective startup line. Inspect the generated line and remove duplicate UI and manual entries.

Where should an unknown modifier error be checked?

Check the server startup log and compare the token with the current official manual. A panel label or search snippet is not proof that a key is supported.