Surge

Change how much adrenaline a trinket needs before it goes off.

Installing

Needs BepInEx. Nothing else. Through a mod manager it is one install. By hand, put Surge.dll in BepInEx/plugins/Surge/.

Then start the game once and quit. That first run writes the config file. It does not exist before the mod has loaded, which is the usual reason people think it is broken.

Nothing changes until you edit that file. Every default is a no-op on purpose.

Changing the settings

The file is BepInEx/config/ezomic.valheim.surge.cfg. Open it in any text editor. Every setting has a comment above it, so the file explains itself.

To make every trinket take longer to fire:

Multiplier = 2

To set exact numbers on some trinkets and leave the rest alone. These are absolute values, not multipliers, and Multiplier has to be 1 or it still applies to everything you did not name:

Multiplier = 1
PerTrinket = TrinketBronzeHealth=35,TrinketFlametalStaminaHealth=45

Save the file and it applies straight away. No restart, and you do not have to leave the world. That is deliberate. The right number here is a feel judgement rather than a fact, and you find it by fighting something, changing the value, and fighting the same thing again.

One thing that will make you think it did not work. Valheim writes an item's tooltip once, at the moment your cursor arrives on it, and never rewrites it while it sits there. So if you are hovering a trinket when the change lands, the tooltip keeps showing the old number. Move the cursor off it and back on and you will see the new one. The crafting panel is the same, it refreshes when you click a different recipe. Nothing is wrong when this happens and the value in the game has already changed, it is just the interface not being asked again.

Set Verbose = true and the mod lists every trinket it found in BepInEx/LogOutput.log, with what it changed each one to.

What the number is

A trinket gives you an adrenaline bar. Parrying, dodging and staggering fill it. Missing an attack and taking unblocked damage drain it, and it decays on its own after a short delay. When it reaches the top, the trinket's effect fires and the bar empties.

So the max is not a stat you want more of. It is a charge time. Raise it and the effect takes a longer run of good fighting to earn. Lower it and it pays out more often for less.

It scales close to linearly. Fill and decay are both curves over how full the bar is rather than fixed amounts, so they stretch along with it, and 2 really is about twice as long.

One thing does not stretch. The grace period before an idle bar starts decaying is a fixed number of seconds, so a longer bar gives a lull in the fight more chance to eat into it. High values are harder than the number makes them look, and against things that die too fast to keep the bar fed the payoff can get out of reach entirely.

The trinkets

Read off the game rather than a wiki. The prefab name is what PerTrinket wants.

Thirteen of them, running 10 to 100. That spread is why the default is a multiplier rather than one flat number. The value is doing per-trinket balance work, not marking tiers. Fins of Destiny at 10 charges almost constantly and Brimstone at 100 is a long earn, and a single flat value throws all of that away. FlatValue is there if you want to flatten it anyway.

Settings

PlayerBase is the odd one and is left alone by default. A trinket's value is added to a base the player carries, and in vanilla that base is 0, which is why the bar only appears once you equip something. Raise it and you have an adrenaline bar permanently.

How it works

The number a trinket grants is a plain float on ItemDrop.ItemData.SharedData, and Player.UpdateModifiers reads it back off m_shared by reflection every frame, summing that one field across all eight equipment slots. So the mod writes to the trinket prefabs in ObjectDB and patches nothing else. The bar resizes, the tooltip updates and the effect fires at the new threshold, all through the game's own code.

Two things follow from that. The config change lands live, because the game re-reads the field every frame rather than on equip. And the multiplier never compounds, because each trinket's original value is captured the first time it is seen and every result is computed from that rather than from whatever is currently set.

BepInEx does not watch config files, so the mod watches its own, waits for the writes to settle, and retunes.

Multiplayer

Client-side. Adrenaline is worked out entirely on the owning client and the max never travels, so you get your own numbers whether or not anyone else runs this.

ObjectDB.CopyOtherDB is patched as well as Awake, because a client rebuilds its item database from the server's copy when it joins. Patching only Awake would let a vanilla server quietly undo the mod the moment you connect.

Status

Played and working, 2026-08-16.

Confirmed on a running game: all thirteen trinkets are found and retuned, per-trinket values apply from a cold start, editing the config retunes without a restart, values are always recomputed from the originals so nothing compounds across reloads, and the mod loads and works with no other plugin installed.

One path has been reasoned about but never run: ObjectDB.CopyOtherDB, which fires when you join a server that does not have the mod. Every test so far hosted its own world, so the client was the server and that path never came up.

License

MIT. See LICENSE.

Changelog

1.0.3 - 2026-08-16

Editing the config now actually changes a trinket you are wearing. Until this, it did not, whatever the three previous releases claimed.

The mod wrote its numbers to the item prefabs and nothing else, on the understanding that an item in your inventory shares its prefab's data. ItemData.Clone is a MemberwiseClone, which copies the reference rather than the contents, so on paper writing one writes both. Measured in a running game, it does not: with a trinket equipped, the prefab was set to 42 while the item being worn stayed at 99, and the player's max adrenaline stayed with the item.

What hid it is that a fresh load looks perfect. The inventory is rebuilt from the prefabs after the retune runs, so everything picks up the new number on the way in. That is why restarting appeared to be the fix, and why the mod's own log agreed with itself while a player watching his own trinket kept saying nothing had changed. He was right.

Carried items are now written along with the prefabs. The log reports both counts, as retuned N, plus M in the player's inventory.

The README also explains something that will otherwise look like the same bug. Valheim writes an item tooltip once, when your cursor arrives on it, and never rewrites it while it sits there. Hover a trinket while a change lands and the tooltip keeps the old number until you move off it and back. The value in the game has already changed.

1.0.2 - 2026-08-16

Config changes no longer depend on the mod being told about them.

A player reported that edits still only took effect after reloading the world, on a build where reading the file, noticing the edit and applying it had each been checked here. His screenshots ruled out the remaining explanation: the game rebuilds an item's tooltip every frame while the inventory is open, so a stale tooltip was never the answer and the value genuinely was not changing for him.

Rather than guess at his machine a third time, the notification is now an optimisation instead of the mechanism. Every trinket is recomputed from its original once a second and only what differs is written, which costs a lookup and a float compare per item. Whatever fails to arrive, the values are right within a second.

It also says so. If that sweep ever finds work to do, it logs Swept up N trinket(s) the config change did not reach, which turns a silent failure into a line in the log.

Also adds, under Verbose, a line reporting the player's live max adrenaline whenever it changes. That is the number the bar is drawn from and the threshold the trinket fires at, so it can be read rather than inferred.

Fixes editing the config needing a restart, which is what 1.0.0 said it did not need.

Three separate causes, found after a player reported it. Any one of them is enough to make the feature look broken.

• The file watcher is no longer relied on by itself. It runs on Unity's Mono rather than desktop .NET, and a mod manager will often put a profile behind a junction or a symlink, which a watcher does not see through. The file's write time is now checked once a second instead, which has none of those failure modes. The watcher is kept only to make it immediate when it does work.
• The settle delay ran on scaled time, and a singleplayer game is paused while you are alt-tabbed out editing the config. That is exactly when the timer needed to run, so the reload arrived only once you came back and unpaused. It runs on unscaled time now.
• Turning Verbose on did not itself trigger anything, so it printed nothing until some other change happened to cause a pass. Anyone switching logging on to check whether live editing worked would have found silence and concluded it did not.

1.0.0 - 2026-08-16

First release.

Surge changes how much adrenaline a trinket needs before it fires. Every default is a no-op, so installing it and changing nothing leaves the game exactly as it was.

• Set an exact value per trinket, scale them all with a multiplier, or give them one flat number.
• Editing the config applies straight away, with the game running and without leaving the world.
• No dependencies.

Played and working. Confirmed on a running game: all thirteen trinkets are found and retuned, per-trinket values apply from a cold start, editing the config retunes without a restart, values are always recomputed from the originals so nothing compounds across reloads, and the mod loads and works with no other plugin installed.

Worth knowing before turning the multiplier up a long way. Fill and decay are both curves over how full the bar is, so they stretch with it, but the grace period before an idle bar starts decaying is a fixed number of seconds and does not. A much longer bar gives a lull in a fight more chance to eat into it, and against things that die too fast to keep it fed the payoff can get out of reach.