NoodlesMcDoodles

🍜 NoodlesMcDoodles

🖥️ Dedicated servers  ·  👥 Works with vanilla clients  ·  🧩 BepInEx 5  ·  📜 MIT  ·  🏷️ v1.0.12

Take the desync out of Valheim: the server runs the world, not whoever loaded in first.

In vanilla Valheim, a zone belongs to whichever connected player is nearest it — and it stays theirs for as

long as they're there. If that player's own connection is the slowest one on the server, their upload and

their latency quietly become everyone else's lag, for every zone they happen to be standing in. Raising send

rates alone doesn't fix that; it just lets a bad connection flood the pipe faster.

NoodlesMcDoodles fixes the cause. The dedicated server runs the world around every player (creatures,

buildings, production, doors, terrain) instead of leaving it to whichever player loaded the area first; players

keep only what they handle directly, like chests, carts and their own character. The server also paces its

sending per player, so distant players get steady updates instead of vanilla's bursty ones. Every feature has its

own config switch, and the whole mod reverts to stock vanilla instantly if you flip its kill switch — see Safety

below.

⚔️ Features

🗺️ Server-run zones

In vanilla, the first player to load an area runs it for everyone: their game simulates the creatures,

buildings, doors and smelters there, and everyone else sees that world second-hand through their connection.

NoodlesMcDoodles gives that job to the dedicated server. With the default `OwnershipAuthority.Mode =

FarOrShared`, the server runs creatures and tames, buildings, production (smelters, kilns, windmills, crafting

stations), trees and rocks, doors and terrain, both in empty areas and in the areas players are standing in.

Players keep what they handle directly: their own character, chests, carts, item and armor stands, turrets,

signs, items on the ground, ships, and anything harvestable within reach. Moving an object to the server only

changes which machine sends its updates; nothing a player sees happen to it changes.

Where several players share an area, the objects players keep go to whichever of them has the best round-trip

time to the server, not to whoever arrived first. An experimental extension (O10) lets the server hold such

an object itself when every player near it is far from the server. It's marked EXPERIMENTAL in its own

config description (that exact case, several far players at once, hasn't been exercised in a long live session

yet), and it can be switched off on its own.

🧊 Empty-area preservation

The server also keeps running areas nobody is standing in — which in vanilla is exactly when things start

decaying, despawning, or losing durability with nobody around to notice. A dedicated guard freezes those specific

destructive vanilla code paths (weather/structural decay, dropped-item despawn, wild-creature-vs-tame and

wild-creature-vs-piece combat) only inside that empty, server-held band. Nothing changes for a zone a player

is actually standing in — normal combat and damage there behave exactly as vanilla.

📡 Steadier networking

Raises the per-connection send-rate ceiling and lets it adapt upward per player as their connection proves it

can take it, instead of pinning everyone to one fixed number. The old vanilla send-queue gate only ever allowed

about one round trip's worth of data in flight, which quietly punished distant players the most; the queue now

grows with a connection's own measured round-trip time, so a far player can approach the same effective

throughput as a nearby one instead of being structurally capped lower.

🧩 Optional client-side extras

Installing the same DLL on your own game client (not just the server) unlocks these client-side improvements, plus

the F6 status panel below: your own uploads get the identical rate/queue treatment the server gives itself, so

other players see fresher updates from you; and a shortened dead-reckoning window means a creature, player, or

objec