How to Mod Valheim with Universal Modder

To mod Valheim with AI, start with one small plugin in a separate test world and character. Universal Modder can investigate the installed game, help create a C# project and record build results; BepInEx and Jotunn provide the community modding tools. Verify the changed behavior in the game before adding more mechanics. Follow the general modding tutorial for planning, backups and evidence.

Can Universal Modder mod Valheim?

Yes. A working Valheim route uses BepInEx, Jotunn and HarmonyX on native Linux; the Frostner rework turns an existing weapon into a returning hammer. Valheim updates can break plugins, so match Jotunn to your game build.

Valheim can be played alone, which gives this first project a local practice environment. Iron Gate does not officially support mods, so start with community tools that match your actual installation and keep the main character and world out of the experiment.

For another BepInEx project, compare Risk of Rain 2, whose R2API dependencies differ from Valheim's Jotunn setup. If you want a survival-game experiment using Lua and data files, read Project Zomboid's build-specific route. The game guide directory lists the starting tools for each option.

What you need

• Your own PC installation, with operating system, executable, game build and launch method recorded. Native Linux and Windows-through-Proton are different environments.
• An agent with Universal Modder installed, and a source workspace separate from the game files.
• A compatible BepInExPack_Valheim and Jotunn. Jotunn's development guide points to the Valheim-specific pack rather than an arbitrary generic loader archive.
• A C# build environment and references to your own installed game and library assemblies. Keep those dependencies local.
• A new test character and world, plus backups of any existing saves and configuration you intend to touch.

The Frostner rework runs on the following group. Use it when comparing the example, not as an instruction to update an unrelated installation:

The later project's dependency manifest also names that pack and Jotunn pair. A .NET SDK version and a plugin's target framework are separate settings: preserve both when investigating a build failure.

Step-by-step

1. Investigate your game and save locations

Run these in the intended agent environment:

um kb search "Valheim"
um scan "Valheim"

Open the note and compare its platform and game build with yours. If discovery misses the installation, pass the actual folder to um scan and inspect the game's launcher configuration. The CLI scan reference explains the checked command syntax.

Write MODDING_PLAN.md with the chosen loader, library versions, launch path, save locations, first change and removal procedure. Keep commands and actual outcomes in MODLOG.md. Identify local versus cloud-managed saves before taking a backup; do not assume the note's Linux directory is your active save location. Use the backup workflow for the folders you actually found.

2. Establish that the loader runs

For a manager-controlled setup, create a separate profile, install the chosen Valheim pack and Jotunn, and launch through that profile. For a manual setup, follow the pack's maintainer instructions. They distinguish the game root, platform startup files and launch method.

For the pack's native Linux route, the documented Steam launch option is:

./start_game_bepinex.sh %command%

Use it only with the pack's script in the intended installation. A Proton setup needs its own matching instructions. Do not layer manual loader files over a manager setup without first understanding which files the profile uses.

Check the actual startup log for BepInEx and Jotunn before adding your plugin. BepInEx documents BepInEx/LogOutput.log as its initial log; with a profile manager, find the corresponding profile location. A normal title screen does not show that the loader ran; see the BepInEx installation documentation.

3. Build a minimal plugin before a weapon rework

Use the Jotunn ModStub workflow for a new project. Set a unique plugin identity, inspect the project references and choose a deployment directory in the test profile. Review pre-build and post-build actions: the template can reference game assemblies and copy output automatically.

Make the first change small enough to explain in one sentence, such as logging the resolved prefab identity before changing one item property. Prefer an appropriate Jotunn event when it exposes what you need. Its event guide shows PrefabManager.OnVanillaPrefabsAvailable and explains unsubscribing when work should run once. Do not assume event subscriber order or patch an unavailable prefab during early startup.

For a prepared project using the .NET CLI, the example's build step is:

dotnet build -c Release

Run it from that project's root and retain the actual result. Inspect the output and deployment path before launching. A missing assembly reference should be repaired in the project configuration, not by placing copied game libraries into the release package.

4. If using Mjolnir, pin the project and inspect its paths

The Mjolnir project has moved beyond its first version. Pin commit 1f81348e210572432ebadc6a71b9d770f6389782, whose manifest labels the mod 2.1.0. Its project file contains the author's absolute Linux ValheimDir and StageDir values. Adapt those reference locations to your own files before attempting a build; the source is not a machine-independent one-command installer.

The project references assembly_valheim.dll, assembly_utils.dll and separate Unity modules. Inspect the assemblies actually installed in your version instead of assuming an older tutorial's Assembly-CSharp.dll contains the game code.

Review the pinned README, changelog, manifest and source together. Their behavior must match the commit you build.

5. Test the exact feature in a practice session

First confirm the intended plugin version appears in the loader log. Then obtain the relevant item in the test world through the project's documented method. Check the changed property or mechanic, repeat it, exit and reload, and record the result.

For a returning-weapon experiment, define separate checks for throw, hit, recall, inventory count, equipment state and a miss. Include moving while recalling and an interrupted action. If an observation is unavailable, leave it pending. A log announcing that the plugin loaded cannot establish that an item returns correctly.

Keep multiplayer as a separate project with explicit server and client version checks. Do not infer synchronization from a local play session or from the absence of a detected protection component.

Example prompts

Adapt these requests for your agent. The prompt library includes more variants.

Use game-recon and mod-any-game for my Valheim test profile.
Record game build, native/Proton environment, BepInEx pack, Jotunn,
actual save folders and launch command. Plan one small plugin change.
Show source references, deployment paths, backup and removal steps,
and a concrete game check before editing.

Review this Jotunn project against my installed game assemblies.
Check target framework, references, plugin identity, dependency metadata,
event timing and automatic deployment tasks. Explain every path change.
Keep game assemblies out of the output package and report unrun checks.

The hammer throws but recall fails. Use my exact source commit and logs.
Separate input handling, projectile state, inventory and auto-equip.
Propose one test for the first failing transition; do not copy behavior
from another revision's field note without comparing the code.

Mods people built

Frostner into Mjolnir modifies the existing MaceSilver prefab instead of adding a separately crafted item. It passes repeated throw-and-recall checks on native Linux, including several recovery cases. Read the full Frostner build notes on GitHub.

The revisions differ: the early version uses aimed recall and a consumed-item flow, while the 2.1.0 changelog keeps the hammer in inventory and recalls it without aiming. Treat those as separate implementations. The README covers single-player Linux and Steam Deck play; multiplayer needs matching installs and its own test.

For a first project, borrow the idea of one visible mechanic with explicit recovery checks. The Terraria weapon case study offers another example of separating item behavior from artwork.

Known issues and fixes

The game opens but no plugin loads. Confirm the active profile and loader startup path, then inspect the loader log. On native Linux, bypassing the pack's startup script can bypass the intended loader route. Follow the platform instructions for the pack you actually installed.

The project cannot find a game or Jotunn assembly. Inspect the reference paths and target framework. The pinned Mjolnir project contains the author's staging folders; changing the folder you cloned into does not update those references automatically.

A prefab lookup returns nothing or a patch never runs. Check the exact internal name, game build and event timing. The sample uses MaceSilver, while its displayed weapon name is Frostner. Avoid repeatedly retrying the same missing name at the same lifecycle stage.

An old recall fix makes a new build worse. Establish which revision is running. Compare the actual inventory and projectile code before applying the early version's consumed-item workaround. Its assumptions changed in the later project.

A world loses modded content after removal. Jotunn's tutorial overview warns that loading characters or worlds without their mods can lose custom items or produce undefined behavior. Test removal using the practice character and world; recover important data from a pre-change backup with its original mod environment. Keep unrelated dependencies and mods intact.