Spawn That, Drop That and Custom Raids on a Valheim server

Spawn That, Drop That and Custom Raids, all by ASharpPen, are the three config-driven mods that rewrite what Valheim spawns, what things drop, and which raids attack your base. They work the same way: plain .cfg files in BepInEx/config with one [Section] per entry, numbered entries that override vanilla when the number matches, extra files you can add with your own name, and debug switches that dump the vanilla tables so you start from real data. All three must be installed on the server and every client. Clients ignore their own files when connected and use the copy the server sends, so the server's files are the only ones that count. Most "it does not work" reports come down to three things: editing the wrong copy, not restarting, or conditions that can never be true at the same time.

This guide covers how Valheim decides spawns, drops and raids, the files for each mod, the debug dumps, working examples, testing changes safely, and the mistakes that leave a raid announced but empty.

How spawns, drops and raids work in Valheim#

You need the vanilla model to configure these mods, because they modify vanilla's systems rather than replacing them.

• World spawners are the background spawn rules: a list of templates per biome saying which creature, how many at most nearby, how often to check, day or night, which weather, how far from the world centre. Spawn That's documentation counts 44 default templates.
• Local spawners are invisible spawn points placed inside locations and dungeon rooms - the skeletons in a ruined tower, the boars at their runestone. Each manages one creature and only one at a time.
• Spawn areas are spawners such as Greydwarf nests, which spawn from a list around themselves.
• CharacterDrop is how creatures drop loot: each entry rolls its own chance and amount, independently.
• DropTable is how most non-creatures drop: trees, rocks, chests, and a few creatures such as birds. The table rolls how many picks to make, then picks entries by weight.
• Raids are events. The server checks every so often whether to start one, picks from the raids whose conditions are met, and tells clients to start it.

The detail that explains most server behaviour: spawning happens on the client that owns the zone. The server decides that a raid starts, but the player whose game simulates the area runs the spawners. That is why these mods must be on every client, and why one player's game decides what appears near them. Raids and events on servers covers the vanilla raid logic in more detail.

Installing the three mods and how config sync works#

Each depends only on BepInExPack. Install them like any BepInEx plugin - Valheim mods with BepInEx on a server has the full route - on the server and on every player's PC, at the same versions. A shared mod manager profile is the easy way to keep the group in step; r2modman for groups covers that.

The first file in each row is the general config: debug switches and global behaviour. The others hold your entries. Most start empty - you fill in only what you want to change.

The sync rules, from the mods' own documentation:

• Clients connecting to a server do not use their local configs. They receive the server's configs in memory, without touching their own files, so a player can keep a different single-player setup.
• Configs are loaded when a world is entered. On a dedicated server that means when the server starts, so restart the server after editing, then have players reconnect.
• Extra files are merged with the main one. Where two entries overlap, the one loaded later wins. Spawn That and Drop That load their main file last, so it always has the final say. Custom Raids also scans subfolders for its supplemental files.

On RE:NODE these are text files you edit in the browser file manager, with syntax highlighting, or over SFTP; restart from the console and watch the BepInEx output there for warnings. Nothing is installed for you - you upload the mods - and there is no list of allowed mods.

Dump the vanilla tables before you change anything#

Every one of these mods can write out the game's own tables in the same format as its config. Start there. You will learn the real prefab names, the existing entry numbers to override, and the values vanilla uses.

[WorldSpawner]WriteSpawnTablesToFileBeforeChanges = true[LocalSpawner]WriteSpawnTablesToFileBeforeChanges = true[Datamining]WriteLocationsToFile = true

[Debug]WriteCharacterDropsToFile = trueWriteDropTablesToFiles = true

[Debug]WriteDefaultEventDataToDisk = trueWriteGlobalKeyDataToDisk = true

The output goes to the folder set by DebugFileFolder, which defaults to Debug relative to the BepInEx folder - so BepInEx/Debug. Turn the switches off again afterwards. The simplest place to generate the dumps is a single-player world on your own PC with the same mods, because the files appear on that machine and you can read them in an editor. The dumps also show the location names you need for local spawners and the global keys raids check, such as defeated_bonemass.

Spawn That: world and local spawners#

A world spawner entry is [WorldSpawner.ID]. If the ID matches one of the default templates (0 to 43 in current documentation), it modifies that template; any unused ID adds a new one. This adds hunting wolves to the Black Forest after Bonemass, at night, in groups:

[WorldSpawner.200]Name = Night wolvesPrefabName = WolfBiomes = BlackForestHuntPlayer = trueMaxSpawned = 3SpawnInterval = 300SpawnChance = 20GroupSizeMin = 2GroupSizeMax = 3LevelMin = 1LevelMax = 2SpawnDuringDay = falseSpawnDuringNight = trueRequiredGlobalKey = defeated_bonemassConditionDistanceToCenterMin = 1500

Setting Enabled = false on an existing template stops vanilla's version, which is how you remove a spawn. Note SpawnDuringDay = false also makes creatures from that template try to despawn in daylight. The general section [WorldSpawner] in the same file accepts DisableSpawnLimiter = true, which turns off a vanilla spawn limitation; the documentation calls it possibly temporary, and it is a fast way to flood a zone if your counts are high.

Local spawners use [Location.PrefabName] or [DungeonRoom.PrefabName] and can only modify spawners that already exist. Each combination must be unique:

[Runestone_Boars.Boar]PrefabName = BoarLevelMin = 1LevelMax = 3LevelUpChance = 25RespawnTime = 20

RespawnTime is in minutes for local spawners, while SpawnInterval for world spawners is in seconds. If several spawners share a location and prefab, all of them get the template - Spawn That cannot tell them apart.

Spawn That adds console commands for checking your work: spawnthat wheredoesitspawn 200 writes a PNG map of where template 200 can spawn, spawnthat area prints the area ID you are standing in, and spawnthat room tells you which dungeon room you are in - handy for finding room names. If Creature Level and Loot Control is installed, it takes over levels unless you set UseDefaultLevels = true in a [WorldSpawner.200.CreatureLevelAndLootControl] sub-section; Creature Level and Loot Control covers that integration.

Drop That: creature drops and drop tables#

Creature drops go in drop_that.character_drop.cfg, as [PrefabName] for settings on the whole creature and [PrefabName.ID] for each drop. As with spawners, a matching ID overrides vanilla's entry and a new one adds a drop.

[Draugr.10]PrefabName = IronScrapAmountMin = 1AmountMax = 2ChanceToDrop = 25ScaleByLevel = falseConditionKilledByEntityType = Player[Troll.0]Enable = false

The first entry gives Draugr a 25% chance to drop one or two scrap iron, not multiplied by star level, and only when a player lands the kill. The second disables the troll's first vanilla drop. ChanceToDrop is a percentage from 0 to 100 in current versions. Older configs used names such as SetAmountMin and SetChanceToDrop; Drop That still reads them, but new files should use the current names. Other useful drop options are DropOnePerPlayer, AmountLimit, and conditions such as ConditionBiomes, ConditionGlobalKeys, ConditionMinLevel and ConditionKilledWithStatus.

Drop tables work differently, and the config shows it. The [EntityName] section must set the table's own rules, then entries have a Weight:

[TreasureChest_forestcrypt]DropChance = 100DropOnlyOnce = trueDropMin = 3DropMax = 6[TreasureChest_forestcrypt.8]PrefabName = SurtlingCoreWeight = 0.5AmountMin = 1AmountMax = 2

Because entries are picked by weight, adding a heavy entry makes everything else in the table rarer. DropOnlyOnce removes an entry after it is picked, which is what keeps chests varied.

drop_that.cfg has two settings for keeping a server healthy: DropLimit (default -1, no limit) caps how many items a single drop can create, and AlwaysAutoStack stacks drops into fewer objects on the ground. With star scaling and multipliers, both are worth using; dropped items and world cleanup explains why item piles cost the server. dropthat:reload reloads configs in a running world for testing, but the documentation warns that it is meant for quick tests and can cause issues - restart for real changes.

Custom Raids: frequency, new raids and disabling old ones#

custom_raids.cfg controls the raid system as a whole. The documented defaults:

EventTriggerChance = 0 turns raids off entirely, and that one setting is the case where the mod only needs to be on the server, because the server decides when raids start. The two preset raids are Ragnarok and Deathsquitoseason; leave them disabled until you have read them.

A raid is a section for the raid and numbered sub-sections for its spawns, in custom_raids.raids.cfg or a supplemental file:

[DraugrSiege]Name = draugr_siegeEnabled = trueRandom = trueDuration = 120NearBaseOnly = trueBiomes = Meadows, BlackForest, SwampRequiredGlobalKeys = defeated_bonemassCanStartDuringDay = falseStartMessage = The dead are marchingEndMessage = The dead fall silent[DraugrSiege.0]PrefabName = DraugrHuntPlayer = trueMaxSpawned = 6SpawnInterval = 5SpawnChancePerInterval = 50GroupSizeMin = 1GroupSizeMax = 2[DraugrSiege.1]PrefabName = Draugr_EliteHuntPlayer = trueMaxSpawned = 1SpawnInterval = 20SpawnChancePerInterval = 25

To switch off a vanilla raid, name it and disable it:

[foresttrolls]Name = foresttrollsEnabled = false

The vanilla raid names are in the WriteDefaultEventDataToDisk dump. Other raid conditions include ConditionPlayersOnlineMin, ConditionWorldAgeDaysMin and ConditionDistanceToCenterMin, plus player-based conditions that work with the playerevents world modifier. Note that StopTouchingMyConfigs in custom_raids.cfg defaults to true from version 1.7.10, so the mod no longer rewrites your raid files with comments and missing options; the wiki still shows the older default.

Testing changes without wrecking the world#

A spawn table change affects the whole world from the next restart, and a raid that spawns forty trolls in someone's base does not undo. Test like this:

1. Take a backup of the server's world.
2. Make the change on a copy: your own single-player world with the same mods, or the server's world downloaded and loaded locally.
3. Use the debug commands. With admin rights and devcommands, the vanilla event draugr_siege starts a named event where you stand and stopevent ends it; randomevent starts a random one. On a dedicated server devcommands need the Server Devcommands mod - see Server Devcommands.
4. Check the BepInEx log for warnings about your files.
5. Only then copy the file to the server, restart, and tell the group.

On RE:NODE, backups are taken on demand and restored with one button, and the Schedules tab can take a backup before a planned restart - a good pairing when you change spawn tables in the evening and want a known-good copy if the group hates it.

Why custom spawns and raids fail#

The raid message appears but nothing spawns. The raid started, but the spawn entries' own conditions failed: wrong biome, a day-only spawn at night, ground too steep, or a required global key not set. Custom Raids' documentation names this as the usual cause. Loosen spawn conditions first.

The raid never starts. Raid conditions rule it out (NearBaseOnly with no base nearby, missing keys), Enabled is false, or with UseIndividualRaidChecks on, its own frequency and chance are too low. Check the debug output after changes.

Changes do nothing. You edited a client copy, not the server's, or did not restart the server. Clients use the server's configs.

Entries are ignored. Typos in option names or prefab names. Prefab names are case-sensitive internal names, not display names; spawn command and item IDs lists the common ones.

Drops multiply out of control. ScaleByLevel is on and creatures have high star levels, or another mod multiplies loot too. Set ScaleByLevel = false for that entry or use DropLimit.

A vanilla spawn still appears after you replaced it. You added a new ID instead of overriding the vanilla one. Find the vanilla ID in the dump and use it.

FAQ#

Do players need these mods if the server has them?

Yes, for nearly everything. Spawning happens on clients, and the mods send the server's configs to clients that have the mod. The exception is turning raids off, which works with Custom Raids on the server alone.

Where do supplemental files go?

In BepInEx/config next to the main files, named with the mod's pattern, such as spawn_that.world_spawners.wolves.cfg. Custom Raids also finds its supplemental files in subfolders. Spawn That and Drop That load extra files before the main file, so the main file wins any conflict; give each raid a unique section name to avoid the question in Custom Raids.

Can I change spawn tables on a world we already play?

Yes. These mods change rules, not terrain, so they apply from the next restart. Creatures already spawned stay until they die or despawn, and local spawners in dungeons already visited use the new template the next time they spawn.

Can I just make raids rarer instead of removing them?

Yes. Raise EventCheckInterval or lower EventTriggerChance in custom_raids.cfg. The vanilla raids world modifier also changes raid frequency without a mod; world modifiers and presets lists its values.

Will these configs survive a game update?

The files will. Whether the mods load on the new version is up to their author, and new game content can add or renumber vanilla entries. After a patch, update the mods, regenerate the dumps, and compare before trusting old IDs.