Fixed

• A host no longer takes your keybinds. Registering a mod syncs its whole config file, which is right for anything a mismatch could desync and wrong for the one class of setting the readme had already warned against in as many words. Three mods here bind a key - Tether, Vaettir's stow and Devkit - so for as long as this stood, joining a server moved your keys to whatever the host had chosen, greyed the entry out, and put the value back if you tried to change it. Keybinds are now held back by type. A mod that genuinely needs one to match can still say so with Suite.Sync.

  discuss

Added

• Suite.Local, the other half of that. Keybinds are the only thing Core can recognise on its own, and they are not the only thing a player would resent losing - a UI scale, a colour, a hover-text toggle. Anything a mismatch cannot desync belongs to the player, and only the mod knows which of its settings those are.

  discuss

• shared\Prefabs.cs: one runtime prefab registry for the suite, as shared source rather than as part of this DLL. Five mods have their own copy, and the copies are not the point: the wrong version of this destroys saved objects in silence. ZNetScene and ObjectDB are rebuilt on every world load, including a trip to the menu and back, so a mod answering "registered yet?" from a static bool says yes to a scene that has never heard of the prefab, registration early-returns, and every ZDO of it is discarded as junk with nothing written to any log. Stow lost a built piece that way on 2026-08-16. Everything here asks the live scene instead. Prefabs.Keep takes a name and a builder and holds the thing registered for whatever world is loaded - both of ZNetScene's lookups, ObjectDB when it is an item, a tool's build menu when it is a piece.

  It is linked into each mod's csproj and excluded from this project, so Core gains no new responsibility and the mods gain no new dependency. That is the whole reason it is a file and not a class in here: Core is soft everywhere, and a mod that could not register its prefab would load, patch nothing into the world and look broken - so owning this would have made Core mandatory for five mods to do anything at all. A runtime fallback was considered and rejected for costing two code paths, the second of which only ever runs where nobody tests, which is how the bug above survived in the first place.

  Linked so far by Taum; the five mods carrying their own copy are a change each.

  discuss

Changed

• RefuseMods is Off / Notice / Refuse instead of on and off. Watching the rule without acting on it used to mean turning Enforce off, and Enforce is one switch over the whole verdict - so trialling the mod list also stopped refusing cheats, cheat commands and altered builds. Notice logs what it would have done and lets the player in.

  discuss

• The allowlist moves into its own file, so a long list is edited as a list.

  discuss

• IdleMinutes now defaults to 5, matching what the door has been set to in practice.

  discuss

Fixed

• A dedicated server no longer chases materials it can never load. A headless process has no renderers and never loads the asset bundles the borrowed materials live in, so the retry that waits for one could never be satisfied and never gave up: four warnings every five seconds, roughly 68,000 lines a day, which had built a 360MB journal on the live server and drowned every real line in it - a mass disconnect of every player went unnoticed there until the log was filtered by hand. Skinning is skipped whole when headless, and nothing visual is lost because a server draws nothing. The repeated warning was wrong on a client too: a donor that never arrives said the same line every five seconds for the whole session, and is now reported once.

  discuss

Fixed

• The plugin announced the wrong version of itself. 1.1.0 moved the csproj, the manifest and the toml and missed the BepInPlugin constant, which is the version the plugin actually reports and half of what Core's gate compares - so the package read 1.1.0 on Thunderstore and introduced itself as 1.0.1 on every connection. Harmless while everyone runs identical builds, and not harmless the moment they do not.

  discuss

The bug

ZoneSystem.RPC_GlobalKeys clears every global key and re-adds them one at a time, and it runs on every client every time anybody sets any key, because SetGlobalKey ends in SendGlobalKeys(Everybody). For the length of that loop the dictionary this mod reads its roster and its credits out of is incomplete.

Vanilla never notices - the refill is synchronous, no frame boundary falls inside it. A Harmony postfix on GlobalKeyAdd does notice, and Yoke has one, hooked there deliberately so it catches the bulk list a server sends on connect. So every key in that list made Yoke ask this mod whether the group had cleared a boss, once per key, while the answer was built from whatever fraction had arrived.

With a partial roster the counted members can be exactly the ones who hold the key - the two who had just killed the Elder, whose credits were already in - and LatchIfGroupCleared then finds a group that has cleared it. The !anyCounted guard only ever caught a completely empty roster; a partial one walked straight through it. The open key is permanent by design, RPC_SetGlobalKey has no permission check, and so one client's half-loaded view became everyone's, for good.

The two-second roster cache is what let one frame of that outlive itself.

Fixed

• The latch refuses to run while the world's keys are settling. A prefix and postfix on RPC_GlobalKeys hold a flag across the rebuild; while it is up, nothing latches. This is the irreversible half of the mod, so it is the half that must decline to answer early rather than answer wrongly.

  discuss

• The roster is never cached from a half-filled key list, and is invalidated on every key that arrives rather than only on a publish. A cache can no longer outlive the world state it was built from.

  discuss

Fixed

• The grid would not turn on a server, while turning perfectly in singleplayer - which is the shape of bug that sends you looking everywhere except at the cause. GridAngle is a float, and Longhouse Core's config sync exempts only KeyCode and KeyboardShortcut from being decided by the host. So on a server the host's angle was imposed on the client, and Core's watch put an imposed setting straight back the moment anything wrote it: every scroll notch set the angle and had it reverted in the same frame. Nothing was wrong with the wheel, the input or the grid.

  The angle is now declared personal through Core's own Suite.Local, which is written for exactly this and names a UI scale or a colour as the same kind of setting. The host's value is never applied rather than applied and then fought.

  The actual rules stay host-decided on purpose - GridCell, GridLevel, GridEnabled and the harvest numbers are all things a server is entitled to settle for everyone. Which way one player's rows happen to run is not.

  discuss

Changed

• Metals wait for their own biome now, like everything else does. Ore and bars are held out of the ramp on purpose, because hauling metal is pacing rather than an oversight - but which boss lifted that was a single global switch, and it cut the wrong way at both ends. Black metal got a bigger stack the moment Bonemass died, before the Plains had been seen; copper and tin sat at their vanilla thirty through the entire bronze age with the Elder long dead. Metals were the one thing in this mod not following the mod's own rule.

  Each metal now waits for the boss of the biome it comes from: copper and tin at the Elder, iron at Bonemass, silver at Moder, black metal at Yagluth. It asks the same question the multiplier already asks of the same item, so the two cannot drift apart. The pacing survives - never a bigger stack of a metal before you are established where it is mined - and in practice only copper, tin and iron move, since Bonemass is always down long before silver is worth carrying.

  discuss

• LiftPortalRuleAt is removed. Naming one biome for every metal was exactly what was wrong, so there is nothing left for it to say. An orphan line in an existing config file is harmless.

  discuss

• The item list says metal-held instead of portal-blocked, and names that metal's own boss rather than one answer copied across all of them. The old word described the flag used to FIND the metals rather than the rule being applied, and it read as though the mod had opinions about portals. It does not: nothing here reads or writes what may go through one, and IncludeNonTeleportable now says so plainly - it is about stack size and nothing else.

  discuss