BeanheimNet

Networking fixes for Valheim 1.0 dedicated servers and clients, with built-in telemetry. One DLL, installed on the server and on every client. No version lock: a player without it still connects and plays vanilla.

The problem

Valheim keeps at most 10 KB of object updates in flight per player and pins Steam's send rate at 150 KB/s. A player 150 ms away can receive at most about 68 KB/s, and the same limit caps what each player uploads. Building pieces are always sent before creatures, carts and dropped items. Fish and ambient animals write an update every frame they move. On a busy server this shows up as creatures that stutter or teleport, carts that freeze and snap, drops that appear seconds late and hits that land late.

What it does

Everything players cannot see ships on. The two features that change what players see, Cleanup and ItemMerge, ship off.

Feature	Effect	Default
SendWindow	Sizes each player's in-flight window from their measured ping instead of the fixed 10 KB	on
SteamTransport	Raises Steam's per-connection send rate from 150 KB/s to 1 MB/s	on
Scheduler	Sends to every connected player each interval instead of one player per frame; can raise the server's 30 fps cap	on
RelayThrottle	Limits how often fish, far creatures, far items, floating logs and sound effects are re-sent. Nothing near a player is slowed	on
Priority	Creatures, carts and drops next to a player no longer wait behind a distant building backlog	on
Deadband	Owners skip updates for movement under a centimetre or a degree; a moored ship gets a wider band	on
Telemetry	Per-player stats every 10 s in the BepInEx log and in BepInEx/BeanheimNet-stats.log	on
Items	Periodic report of dropped items on the server; optional cleanup of old floating junk	report on, cleanup off
ItemMerge	Merges nearby plain stacks on the client that owns them	off

Before and after

Two players in one session, one on LAN and one at 48 ms ping, fighting and moving through the same areas. Features were switched off for ten minutes and back on, live, with telemetry running throughout.

	Features off	Features on
Server frame time	47 ms	28 ms (ServerTargetFrameRate 60)
10 s intervals with updates left waiting	90 %	46 %
Largest backlog in one interval, remote player	437,280 updates	96,026 updates
Remote player, receive rate	65–69 KB/s in almost every interval (the vanilla ceiling)	44 KB/s at rest, up to 145 KB/s entering an area
LAN player, receive rate	up to 73 KB/s	up to 124 KB/s
Intervals with no backlog at all	6	67, with 0 refused rounds and 0 waiting updates for both players

One player's upload, measured on a separate day: 130 KB/s pinned at the Steam cap with thousands of updates deferred per ten seconds before, 44–52 KB/s with none deferred after.

Ping under load is the one number vanilla wins: during area arrivals the remote player's in-game ping was 104 ms with features off and 123 ms with them on, because a larger window queues more. At rest it was 86 ms and 93 ms.

Setup

• Install on the server and on every client (BepInEx 5).
• Config: BepInEx/config/helix.beanheim.net.cfg. Edits are picked up within 5 s. No restart.
• Dedicated servers do not read console input. Use the one-shot keys under [11 Triggers] (Census, ItemReport, ItemCleanupOnce, Stats): set one to true, it runs and resets itself.
• Clients: console command bnet stats | census | items | cleanup dryrun|run | reload | config.
• Rollback: [01 General] Enabled = false, live, makes every patch behave like vanilla. Delete the plugin folder to uninstall. Nothing persists in the world except Cleanup deletions, and only if it was enabled.

Advanced

Settings

• 02 SendWindow: window = ping × TargetRateKBps (300) × BdpFactor (1.25), clamped between MinWindowBytes (32768) and MaxWindowBytes (65536); vanilla 10240 when there is no ping reading. Includes queue-drain compatibility for mods that wait on the socket queue (ServerSync, Jotunn, ConditionalConfigSync) and raises Jotunn's MaximumSendQueueSize while on. Refuses to install if ZDOMan.SendZDOs does not have the expected shape.
• 03 Scheduler: SendIntervalSeconds (0.05) caps send rounds per player per second; FrameBudgetMs (4) bounds the time spent per frame. ServerTargetFrameRate (0 = vanilla 30): on a server that idled at 47 ms per frame, 60 gave 28 ms at the same CPU use.
• 04 SteamTransport: SendRateMin and SendRateMax set to SendRateKBps (1024). Steam requires them equal. Applied globally and to live connections, and read back.
• 05 RelayThrottle: rates in updates per second as near/far/beyond: fish 6/3/2, creature ∞/10/5, item ∞/5/3, floating ∞/5/3, effect 10/5/3, other ∞/∞/∞. Bands at NearMeters (40) and FarMeters (100). Distance is measured from the receiving player on the server and from the nearest loaded player on the client upload. Never throttled: never-sent objects, ownership changes, force-sends, players, ships, carts and non-Default object types. Nothing is dropped; a held update goes in the next round.
• 06 Priority: score = distance − AgeWeight (1.5) × seconds since the last sync − SolidBiasMeters (64) for building pieces − NewNearBonusMeters (200) for never-sent objects inside NearMeters. Foreign-owned Prioritized objects and terrain keep their top tiers. Uses the live character position instead of the one the client reports every 2 s.
• 07 Deadband: item 0.02 m / 2°, creature 0.01 m / 1°, other 0.01 m / 1°, velocity 0.05 m/s, moored ship 0.05 m / 2°. Measured against the last written value, not the last frame. One exact zero velocity is written when an object comes to rest. Never players, carts, Prioritized objects or a ship with anyone aboard.
• 09 Items: Cleanup deletes items older than MaxAgeHours (6) of played time, farther than ProtectRadiusMeters (200) from every player, not within BaseProxyRadiusMeters of a BaseProxyPrefabs piece, in water when OnlyInWater is set, and not matching ProtectedPatterns. An item with custom data (every EpicLoot enchantment), a quality above 1, a max stack of 1 (all gear) or unreadable item data is never deleted. Every deletion is logged.
• 10 ItemMerge: same name, quality 1, variant 0, no custom data, within MergeRadiusMeters (5), checked every MergeIntervalSeconds (30). Vanilla auto-stacks at 4 m, once per item and only while more than 200 drops are loaded.

Reading the stats line

• deferred: updates that did not fit the window this round. Sustained non-zero with two or more players means the window is the limit. With one player it is always 0.
• refused: rounds that sent nothing because the queue was above the window.
• rtt is Steam's ping; app is a ping through the game's own send queue. app includes one server frame and one client frame (about 16 ms with the server at 60 fps, 33–76 ms at 30), so the queueing delay is app − rtt − floor.
• throttled: updates held back by RelayThrottle this interval. They are sent later, not dropped.
• frame avg on a server line is the server's frame time; frames >50ms N >100ms N counts long frames in the interval. sched frames/served/budget-breaks appear when Scheduler is on.
• gc N heap N MB cpu N%: gen-0 collections in the interval, managed heap size, and process-wide CPU as a share of one core. A long frame with low cpu is waiting, not working.
• steam-status ok N not-ok N last <EResult> appears when Steam's connection-status call fails; that player's window stays vanilla until it works.
• Vanilla's own Connections N ZDOS:X sent:Y recv:Z line is the cross-check. Both counters are 0 with one player.
• To measure a change: turn one toggle off in the cfg, play ten minutes, compare the lines, turn it back on.

Compatibility

Every private game member is bound once at startup. A missing member disables only the features that need it, with a logged reason. Every patch body is wrapped: an exception logs once per minute and that call falls back to vanilla. If Smoothbrain Network, ValheimTune, NetworkPerformanceSystem, ReturnToSender, BetterNetworking or VBNetTweaks is loaded, only telemetry is installed. At boot the plugin lists every other Harmony patch owner of the methods it touches ([owners] lines).