Don't Starve Together mods, admins, rollbacks

Mods on a Don't Starve Together dedicated server take two files: mods/dedicated_server_mods_setup.lua in the server install tells it which workshop items to download, and modoverrides.lua in each shard folder decides which of them are enabled and with what settings. Admins are Klei user IDs, one per line, in adminlist.txt in the cluster folder. Everything else - kicks, bans, saves, rollbacks, spawning items - is Lua typed into a shard's console, and a handful of those commands behave differently on a server console than they do in game. This post covers the mod files in depth, how to get every mod's configuration right without guessing, the admin setup, a full command reference, and how to roll back without leaving your Forest and Caves on different days.

For the cluster itself - the token, cluster.ini, server.ini, ports and shards - start with the Don't Starve Together server guide. This post assumes a cluster that starts.

How mods reach a dedicated server#

A DST server never loads mods from players. It downloads them itself, from the Steam Workshop, when a shard starts. The flow is:

1. The shard reads dedicated_server_mods_setup.lua and downloads or updates every workshop item listed there.
2. It reads its own modoverrides.lua and enables the mods marked enabled = true, with the configuration given.
3. When a player joins, the server tells their client which mods are required, and the client downloads those from the Workshop automatically.

The consequence of this design is that the cluster must be online - offline_cluster = false - for workshop mods to work at all, and every shard downloads what it needs at start-up, so a long mod list means a slower start.

Where the downloaded files end up depends on the mod's workshop format. Older mods are unpacked into the install's mods folder as workshop-<id> directories. Newer ones are stored in a ugc_mods folder, separated by cluster and shard, unless the server is started with -ugc_directory pointing somewhere else. You rarely need to touch either; it is useful to know when you are checking whether a download actually happened.

dedicated_server_mods_setup.lua#

This file lives in the server's install directory, not the cluster folder - mods/dedicated_server_mods_setup.lua next to the game binaries. It is the download list, and only the download list:

-- Individual workshop items, by idServerModSetup("1234567890")ServerModSetup("2345678901")-- Or a whole workshop collectionServerModCollectionSetup("3456789012")

The ID is the number at the end of the mod's Workshop URL, after ?id=. A collection ID works the same way and pulls every item in the collection - convenient for a large list, but it means anyone who can edit the collection can change what your server downloads. Use a collection you own.

Three things catch people here:

• This file is in the install, so a reinstall or validate can reset it. Keep a copy in the cluster folder or in your notes and restore it after updates.
• Listing a mod here does not enable it. It only downloads it. A mod in this file and not in modoverrides.lua is downloaded on every start and never used.
• Mods are updated on every start. When an author publishes, your next restart picks it up. There is no version pinning, which is why a game update or a mod update can break a cluster that ran fine yesterday.

modoverrides.lua, per shard#

Each shard has its own modoverrides.lua in its folder in the cluster - Master/modoverrides.lua and Caves/modoverrides.lua. It is a Lua table keyed by workshop- plus the ID:

return {  ["workshop-1234567890"] = {    enabled = true,    configuration_options = {      stack_size = 99,      show_in_inventory = true,    },  },  ["workshop-2345678901"] = { enabled = true },}

The rule that decides whether a cluster works: every mod that affects the world must be enabled with identical options in both shards. When a player goes down a sinkhole they move between server processes. If a mod is on in the Forest and off in the Caves, items and creatures from that mod do not exist on the far side, and the result ranges from vanished items to a crashing shard. Keep one file and copy it to both folders after every change.

The configuration keys are not documented anywhere except in the mod itself. Every mod has a modinfo.lua, and its configuration_options table lists each option's internal name, its allowed data values and its default. Values in modoverrides.lua must be one of those data values exactly - a number where the mod expects a string, or a value that is not in its list, is silently ignored and the default is used.

Which mods belong on a server#

Every DST mod declares in its modinfo.lua where it runs, and it is worth reading before you add anything:

Client-only mods - minimap HUDs, placement grids, interface tweaks - do nothing on a server. Do not add them to the server's list; tell players which ones you recommend instead.

Server-only mods are the cheapest kind for a group: they change rules, drops or spawns without anyone downloading anything. Mods that require all clients are where the download size, version churn and compatibility problems live. A cluster with forty all-clients mods has forty things that can break on the next game update, and a new player's first join downloads all of them.

A good discipline is to keep a short list, test any addition on a copy of the world, and add mods between play sessions rather than during them. Keeping a modded server clean covers the wider habit, and the general mechanics of workshop content on servers are in Steam Workshop mods on dedicated servers.

Mods that are not on the Workshop - your own, or a private fork - are placed as a folder in the server's mods directory and enabled in modoverrides.lua by that folder name instead of a workshop- key. Players then need a copy by hand, because the auto-download only works for Workshop items.

Admins and how to find Klei IDs#

Admins are listed in adminlist.txt in the cluster folder, beside cluster.ini:

KU_aB3dEf7hKU_9zQ2mNp1

The entries are Klei user IDs, which start with KU_ and are the same on every platform the account plays on. They are not Steam IDs or player names. To find one, have the player join and run this in the shard console:

c_listallplayers()

It prints every connected player with their ID. Players can also find their own on their Klei account page. The file is read when the shard starts, so restart after editing it.

An admin in game gets two things. The player list (held Tab) shows kick and ban buttons beside each name. And the in-game console - opened with the backtick key - can send commands to the server: it starts in local mode, and you switch it to remote with Ctrl before typing. A command run in local mode affects only your own client, which is why "I typed c_save() and nothing happened" is so common.

whitelist.txt uses the same IDs and works with whitelist_slots in cluster.ini to reserve slots. blocklist.txt is the ban list and the server writes to it when you ban someone.

Console command reference#

Commands are Lua, typed into the console of the shard you mean - the Forest commands go to the Master, the Caves commands to the Caves.

The gotcha is who a command targets. In game, commands without a player argument act on you - or on whatever you have selected. On the server's own console there is no "you", and many of these fall back to the first player in the player list. So c_give("goldnugget", 10) typed into the panel console gives gold to whoever happens to be first, not to the person who asked.

Target players explicitly instead:

-- Look up a player by namelocal p = UserToPlayer("Wendy_main")c_godmode(p)c_despawn(p)-- Give items to one specific playerp.components.inventory:GiveItem(SpawnPrefab("goldnugget"))-- The connected players, in join orderfor i, v in ipairs(AllPlayers) do print(i, v.name, v.userid) end

c_countprefabs is the admin tool people overlook. A cluster that has started to lag usually has too much of something - dropped items, planted trees, spawned creatures - and c_countprefabs("log") or c_countprefabs("evergreen") tells you how many there are in seconds.

Rollbacks and snapshots#

DST keeps snapshots: save points taken by the autosaver, up to max_snapshots from cluster.ini (6 by default). c_rollback(1) goes back one, c_rollback(3) three. Players are disconnected and reconnected to the restored state.

The trouble is that a cluster is two worlds. If you roll back the Forest and not the Caves, players who were underground keep their newer state while the surface goes backwards, and the two day counters disagree. Roll back in both shards by the same number, close together, and check both day counters before letting people back in. If you are unsure, the sure way is a full restore of the whole cluster folder from a backup, with both shards stopped.

Snapshots also live on the same disk as the save. They cover "we made a bad decision an hour ago", not "the server was deleted". For that you want a real backup off the machine - backups that actually restore is the argument for it. On RE:NODE, backup slots are included on every Don't Starve Together plan, stored off the machine, restored with a button; the Schedules tab can send c_announce("Saving for backup") and c_save() as console commands, then take a backup a minute later, on a cron expression.

Players can also start a vote to roll back or regenerate the world if vote_enabled = true. On a public server, decide whether you want that power in players' hands.

Updates and when mods break#

Game updates are the main source of DST mod trouble. Klei patches change the internals mods hook into, and each patch breaks a share of mods until their authors catch up. Because the server re-downloads mods on every start, a broken mod update also reaches you without warning.

A short routine:

1. Before a game update, take a backup of the whole cluster folder.
2. After updating, start the Master and read its log as the mods load. A failing mod prints its name and a Lua error.
3. Disable the failing mod in both modoverrides.lua files, restart, and check the world.
4. Re-enable it when the author has published a fix.

A mod that added items or creatures cannot always be removed from an existing world cleanly; the shard may drop its objects or refuse to load. Back up before removing, and see what to do when a mod update breaks for the general recovery drill.

Troubleshooting#

Mods are listed in setup but not active. They are not in modoverrides.lua, or the key lacks the workshop- prefix.

A mod works in the Forest and crashes the Caves. The two modoverrides.lua files differ. Copy one over the other.

Mod settings are ignored. An option name or value does not match the mod's modinfo.lua exactly. Generate the file from the game instead.

Players fail to join after a mod update. Their client has an older copy. Restarting the game usually triggers the Workshop update.

`c_give` gave items to the wrong person. The server console targets the first player when none is given. Use UserToPlayer("name").

Admin commands from the in-game console do nothing. The console is in local mode. Switch to remote, and check the ID is in adminlist.txt and the shard restarted.

FAQ#

Do players have to install the server's mods before joining?

No. Mods marked as required by all clients are downloaded automatically when a player joins. Client-only mods are each player's choice and are never required.

Can the Forest and Caves have different mods?

Only mods that do not touch shared things, such as some server-side tweaks. Anything that adds items, creatures or recipes must be identical in both shards, or players moving between them hit missing objects.

Where do I find a mod's configuration options?

In its modinfo.lua, under configuration_options. Easier: set the options in a local world in the game and copy the generated modoverrides.lua to the server.

Does c_rollback affect both shards?

Treat it as affecting the shard you run it on, and roll back both by the same number. Check the day counter in both worlds afterwards.

How do I make someone admin without restarting?

The admin list is read at start, so the reliable method is to add their Klei ID to adminlist.txt and restart at a quiet moment.