Every bridge is tagged [Obsolete("Valheim10Compatibility bridge -> Target(...)")], so other tools can tell a bridge from a native method by reflection, and the Harmony hook can find the native method a typed lookup belongs on. They go into assembly_valheim.dll and assembly_utils.dll.

The sector sweep — the one that matters most. AwayFromHome, Let It Grow, TortalPortal, HearthBelow and Wonderland all call ZDOMan.FindSectorObjects. 1.0 collapsed its two int distance parameters into a SimulationDistance struct and deleted ZoneSystem.m_activeArea. The bridge rebuilds the struct with classic: true — and that flag is not optional: without it vanilla filters each ring through ZonesWithinRadius and the swept area becomes a disc instead of the square ring every pre-1.0 caller is written against. FindObjects and FindDistantObjects gained a visit-tracking HashSet; the bridges pass the game's own set and clear it first, exactly as vanilla does — miss that and the second call in a session returns nothing at all.

ZDOMan.SectorToIndex was once written off as unbridgeable. Re-checked: ZDOMan is still built 512 sectors wide and ZoneSystem.SectorToIndex computes (y + 256) * 512 + (x + 256) — byte for byte the old arithmetic. Only the out-of-range answer differs: the old contract returned -1, the new one 0, which is also a legal sector. The bridge keeps -1, so callers that range-check keep working.

The console-command surface. 1.0 inserted bool hideBehindDevCommands into Terminal.ConsoleCommand's constructor and gave ConsoleEventArgs a third parameter. Breaking those two takes whole admin toolkits down at once.

Reordered, not just retyped. ZNetScene.InActiveArea went from (Vector2i zone, Vector3 refPoint) to static (Vector3 point, Vector2s centerZone). Swapping the arguments would compile, run, and answer confidently wrong. The bridges convert properly, through ZoneSystem.GetZonePos.

The appended-parameter drift. C# bakes default argument values in at the call site, so a method that merely gained an optional parameter still breaks every plugin compiled before it:

Character.Message (43 of 87 plugins) · MessageHud.ShowMessage · SEMan.AddStatusEffect ×2 · EffectList.Create (11 plugins) · four Inventory.AddItem overloads · Inventory.Changed · ItemDrop.SaveToZDO / LoadFromZDO / OnCreateNew ×2 · ItemData.GetTooltip · Heightmap.Poke · TerrainComp.Save · WorldGenerator.GetBiomeHeight · YesNoPopup..ctor · Piece.SetCreator · Player.PlacePiece · ZoneSystem.SpawnLocation · VisEquipment.AttachArmor · Humanoid.IsTeleportable · ZInput.mousePosition · Inventory.IsTeleportable() · CensorShittyWords.FilterUGC · Game.SavePlayerProfile · CookingStation.SetSlot / GetSlot (1.0's new out bool cheated is discarded into a local) · SlowUpdate.SUpdate(float, Vector2i) (callvirt, so Plant and StaticPhysics overrides win) · PlayerProfile.GetStat · ItemDrop.ResetVariantIfInvalid

PlayerProfile.GetCharacterFolderPath(FileSource) moved to SaveSystem, and its argument changed numbering — FileSource went from 0/1/2/3 to flags 1/2/4/8 — so the bridge computes 1 << old before forwarding, rather than answering the Cloud path for a Local request.

The PieceTable.m_availablePieces alias. 1.0 renamed the per-category piece lists to a private m_availablePiecesByCategory and reused the old name for a flat HashSet<Piece>. Fifteen build-piece mods read the old field — to count tabs, index them, or add a list for a custom category. The alias is a second field with the old name and type, assigned in the constructor to the same list object, so the two views cannot diverge. IL binds fields on name and type, so vanilla and 1.0-built plugins keep the HashSet and pre-1.0 plugins get the lists. A guard scan refuses the alias outright if any installed plugin passes the literal "m_availablePieces" to Type.GetField or Traverse.Field.

⚠️ The tab caveat. 1.0 inserted PieceCategory.DeepNorth = 5, pushing Feasts, Food and Meads to 6, 7 and 8. A pre-1.0 mod bakes the old numbers in, so a piece it files under the old Feasts lands in the Deep North tab, and a custom tab created at the old Max shares the Meads list. Wrong tab, not a crash. If your build menu looks wrong, turn the alias off (Settings).

The default interface method. Hoverable is an interface, and 1.0 added float GetHoverOffset() to it. The runtime needs every interface member filled before a type can be built, so an old class implementing Hoverable fails the instant its assembly is scanned — not when the method is called — and every Harmony patch in that assembly goes down with it. Every vanilla call site already reads it as component?.GetHoverOffset() ?? 0f, so the patcher gives the interface method itself the body return 0f; — the same feature C# 8 formalised, applied at the IL level. A class that implements it (every 1.0-built one) keeps its own. Tested live with a controlled A/B on a 91-plugin dedicated server list: it clears every VTable failure.

ZRoutedRpc.Everybody. 1.0 made it a const. Mods compiled against the older declaration — notably the ServerSync inside AzuAntiCheat and SeedBed — read it with ldsfld, which throws MissingFieldException on a literal field and crashes the plugin at startup. The patcher makes it a normal static field again; 1.0-built code inlines the constant and never notices.

The three patch anchors — read this one. Container.RPC_OpenRespons, Container.RPC_TakeAllRespons and Minimap.OnMapRightClick were renamed or replaced by a lambda in 1.0, and plugins patch all three by name, so their absence kills those plugins at PatchAll(). These bridges restore the name so the plugin loads; they do not restore the behaviour — vanilla calls the renamed method, so a prefix on an anchor never fires. The plugin works; that one feature is inert. It is the only place where a name comes back without its meaning, a deliberate trade of one dead feature against one dead plugin, and each anchor says so in its own log line. 🕯️

When a plugin writes [HarmonyPatch(typeof(Inventory), "Changed")] with no argument types, Harmony resolves that target by name alone. Add a second method with that name — exactly what a bridge does — and the lookup becomes ambiguous. HarmonyX throws out of PatchAll(), and the entire plugin dies at load, every patch in it. That is far worse than the one broken call the bridge was meant to fix — and an earlier release of this very patcher broke ProceduralRoads and Venture LocationReset exactly that way. 🩹

The guard blocks any bridge that would collide with a by-name patch. That protection was right, and it was also a ceiling: EffectList.Create was wanted by 11 plugins and stayed blocked because Infinity Hammer patches it by name. And vanilla itself creates the same ambiguity with no bridge in sight: 1.0 gave Inventory.Load, PieceTable.SetCategory, Attack.GetAttackEitr and fifteen other methods a second overload, so pre-1.0 plugins patching those by name die on plain 1.0.

The hook. Every Harmony lookup — attribute patches, AccessTools.Method(...) in code, ___field injection — goes through four AccessTools entry points. The patcher detours all four from the preloader, before any plugin loads, and answers the way the plugin's author meant:

• 🚫 A by-name lookup never returns a bridge. The patch lands on the native method vanilla actually calls.
• 🕰️ Between two native overloads, the pre-1.0 one wins. The table comes from a diff of the last pre-1.0 build against 1.0: 18 names whose overload count went from one to several with the old shape still there.
• ↪️ A typed lookup naming a bridge's exact parameters is redirected to the native it forwards to — when the bridge only appends defaulted parameters and Harmony's own patch machinery is asking. The patch then fires on vanilla's own calls. A plugin's own typed lookup gets the bridge it named, so MethodInfo.Invoke, delegates and Traverse keep the old arity. A bridge handed straight to Harmony.Patch is swapped for the native at patch time. Bridges that transform their arguments are never redirected.
• 🧾 A field lookup that finds an alias is answered from the caller's own IL: a plugin compiled against the old shape gets the alias, everyone else the native field.

Anything the hook does not understand falls through to HarmonyX's own behaviour, exception included. The guard still runs at every boot: with the hook in, it is advisory — the log names every plugin whose by-name patch now relies on the hook — and if the hook cannot be installed, it blocks exactly as it would without one. What the hook leaves alone on purpose: plain Type.GetMethod / Type.GetField callers. Which brings us to the next rule.

The return-type rule. An old call site resolves on the full signature, return type included, so restoring Vector2i ZoneSystem.GetZone(Vector3) beside the native Vector2s one is legal — and exactly what those call sites need. But reflection cannot tell the two apart: the moment both exist, every plugin that looks that name up throws AmbiguousMatchException in its own startup and takes itself down. That is not theoretical: an earlier release injected ZDO.GetSector() and GetZone(Vector3) this way, and Wonderland died in Awake() on a live server because its compatibility probe does that lookup. So the patcher refuses any bridge that would differ by return type alone. The cost is real: ZDO.GetSector() and GetZone(Vector3) call sites stay broken (Procedural Roads, for one). The alternative was those plugins not starting at all.

Everything the guard decides is decided per install, from your plugin folder. A different mod list gets a different answer.

ObjectDB.UpdateRegisters builds the item table with Dictionary.Add, so two item prefabs sharing a name throw out of FejdStartup.SetupObjectDB and startup aborts — a server never loads a world, a client menu spams NullReferenceException. Vanilla's own list is unique; the duplicate comes from a mod registering an item under a name 1.0 now uses itself, and Jotunn lets it through (its duplicate check runs against a table that has not been filled yet). The shield drops the later duplicate just before vanilla's loop — the first registration wins, which is vanilla's whenever vanilla owns the name — and logs which item, which mod token, and why. It only ever acts where vanilla would have thrown.

Measured on a 91-plugin dedicated server list with More Ore Deposits installed, same binary, only the switch toggled: off, An item with the same key has already been added and no world ever loads; on, the world comes up, the shield fires once (GoldOre: kept vanilla's, dropped the mod's), and the mod's five deposits are injected.

⚠️ The shield keeps the game up; it does not make the colliding mod right for 1.0. More Ore Deposits' gold deposits then drop vanilla's Deep North gold ore, and its ×20 smelter bonus applies to vanilla's blast furnace too. Read the warning line, then ask that mod's author for a 1.0 build.

Four Azumatt inventory mods, Jotunn dependants, JereKuusela admin toolkits and fifteen-plus build-piece packs, warts and all. The static check re-resolves every game reference and every Harmony target in each plugin against the patched assemblies, with the hook modelled; the live check boots the same lists on a real Linux dedicated server, patcher out and patcher in. The server's profile was only ever read. These are the figures from when Valheim 1.0 launched; every hotfix since is re-measured, and the per-hotfix numbers are in the changelog.

The two lost patches without the patcher are Mists of Avalor's no-build protection (the bridge and the redirect bring it back) and Advanced Terrain Modifiers' PaintCleared prefix (it names three parameters 1.0 removed — identical either way). The one that appears with the patcher is a SearsCatalog transpiler whose IL pattern no longer exists — SearsCatalog never got that far before, because its SetCategory postfix was ambiguous and the plugin silently applied nothing.

The VTable row is CoreWoodExtras, RustyBuildPieces, SeedBed, Historical Heritage, Ravenwood Random Relics and Procedural Roads, isolated with an A/B on one fixed mod list and one binary — only the switch toggled — so the count belongs to that fix alone.

One exception was found since, and closed: for a time the hook redirected Historical Heritage's own typed AttachArmor lookup to the longer native method, and its Invoke threw where plain 1.0 returned nothing. The hook now hands a plugin's own reflection the bridge it named.

The zip carries patchers/Valheim10Compatibility.Patcher.dll and plugins/Valheim10Compatibility.Adapter.dll. A mod manager maps each top-level folder onto the BepInEx/ folder of the same name. By hand, copy the DLL from patchers/ into BepInEx/patchers/ and the one from plugins/ into BepInEx/plugins/.

[Info   :Valheim10Compatibility] Ambiguity guard: scanned 84 Harmony plugins under '.../BepInEx/plugins' in 1892 ms; 779 by-name patch targets recorded; 17 plugin(s) reference a pre-1.0 field shape this patcher aliases.
[Info   :Valheim10Compatibility] Harmony resolution hook installed on HarmonyX 2.9.0.0 (AccessTools.DeclaredMethod, Method, DeclaredField, Field; PatchProcessor..ctor); ...
[Info   :Valheim10Compatibility] Injected ZDOMan.FindSectorObjects(Vector2i, int, int, List<ZDO>, List<ZDO>) -> SimulationDistance(area, distantArea, classic: true)
[Info   :Valheim10Compatibility]   by-name Harmony patch on EffectList.Create in InfinityHammer.dll, MoreVanillaBuildPrefabs.dll: the resolution hook steers it to the native overload, so this bridge is injected anyway.
[Info   :Valheim10Compatibility] Injected EffectList.Create(Vector3, Quaternion, Transform, float, int)
[Warning:Valheim10Compatibility] BLOCKED ZoneSystem.GetZone(Vector3) -> Vector2i: this would differ from the existing Vector2s GetZone(...) by RETURN TYPE ALONE ...
[Info   :Valheim10Compatibility] assembly_valheim: 52 bridge(s) injected (12 of them beside a by-name Harmony patch that the resolution hook steers past them), 0 already native, 0 skipped (no target on this build), 2 blocked (0 would break a by-name Harmony patch or a reflective field lookup, 2 would be a return-type-only overload).
[Info   :Valheim10Compatibility] Harmony hook: AccessTools.DeclaredMethod(Inventory, "Changed") -> Void Inventory.Changed(Boolean, Boolean)  [1 bridge overload(s) excluded]  <- AzuAutoStore

If the hook line reads NOT installed, the patcher has fallen back to refusing every colliding bridge outright, and says so.

The guard finds your plugins in BepInEx/plugins. If it cannot find the folder, it says so plainly and every overload bridge goes in unprotected. For a nonstandard layout, set the environment variable VALHEIM10COMPAT_PLUGIN_PATH to the plugin folder.