Changelog

1.2.1 — 2026-09-29

Opening your inventory no longer costs you most of your framerate. Since 1.2.0, opening the inventory or a chest dropped the game to 15-30 FPS and held it there for as long as the panel was open — on any world, including a brand new one with no portals built in it.

The overlay that marks the stacks a portal will refuse has to know which portal you are standing at, and it asked the game to find that by searching the whole scene. That search costs the same whether the world holds fifty portals or none, and the inventory panel redraws every frame — twice, with a chest open. The mod now keeps a list of the portals loaded around you and reads that instead, which is the same answer for none of the cost.

If you turned the overlay off to get your framerate back, turn it back on. Set ShowBlockedCargoOverlay = true and CargoPreviewRange back to 8 in com.recognizerhd.stavebound.cfg. Nothing rewrites a config file that already exists, so those have to go back by hand.

Also fixed, from the same pass: in a world whose TeleportAll key lets everything through portals, the overlay marked stacks the game would have carried. It now only ever removes one of the base game's marks, never adds one.

Safe to update alone. A patch release, so this and 1.2.0 still connect to each other, and the fix asks nothing of the server.

1.2.0 — 2026-09-17

Everyone has to update together this time. Stavebound will not connect across different minor versions, so a 1.1.x player cannot join a 1.2.0 server, or the other way round. Update the server and every player at the same time. (1.1.1 was a patch release, which is why that one could be taken up one player at a time.)

Portal names can be 32 characters, against vanilla's 10, which runs out fast once a world has enough portals to tell apart. The selector's panel widens to suit, so a full-length name still fits a row whole. PortalNameLength sets it anywhere from 10 to 32.

Set on the server, so every portal in a world is named under one rule — though a player on an older build still types under vanilla's 10 while seeing everyone else's longer names normally.

1.1.1 — 2026-09-15

A player who walks through a portal no longer leaves their body standing there on everyone else's screen, still emoting, until those players teleport somewhere themselves.

That was the game's doing, not this mod's: your position travels only to players near you, and a portal is the one way to leave an area without crossing its edge, so everyone watching keeps their last copy of you — at the portal — forever. It shows up here because portals are what this mod is for, so it is fixed here. Nothing is faked: your game asks the server for a fresh copy of anyone who looks stuck, and the game then clears the body itself. ClearLeftBehindBodies turns it off.

Safe to update alone. This is a patch release, so 1.1.1 and 1.1.0 still connect to each other. The fix is entirely on your own machine and asks nothing of the server, which does not need updating — or even to be running this mod.

1.1.0 — 2026-09-14

Update the server and every player together. Stavebound refuses to connect across minor versions, so a 1.0.0 player cannot join a 1.1.0 server, or the other way round. That is the check working as intended — it stops two builds quietly disagreeing about portals — but it means nobody can update alone.

The destination selector works with a mouse. Each destination is a clickable row with its clearance chips right-aligned; a dropdown lists them all; the key hints along the bottom are buttons; the wheel scrolls the list without zooming the map; and hovering a row pans the map to it. Arrow keys and gamepad still highlight and the confirm key still picks — a click picks straight away, and clicking a portal's pin on the map picks it and closes the map.

Your home portal stands out. The portal nearest your bed is coloured in the list and on the map, and every other destination's pin is orange while you choose, so the selector's pins no longer blend in with the ones you placed yourself.

Every mouse behaviour is a per-player setting under 8 - Selector.

stave_players, for diagnosing a player who looks left behind at a portal after going through. Needs the console, not devcommands.

Fixed: with the cargo filter emptying the list, pressing confirm or the arrow keys crashed. Fixed: closing the selector could leave the map open, because it checked a flag the game never changes. Fixed: clicking the map to choose a destination read the pointer through Unity's old input API, which the game stopped using in 1.0.

1.0.0 — 2026-09-10

Valheim 1.0 compatibility. 0.9.0 does not run on 1.0 — update.

Numbered 1.0.0 because it has now been played on a real network and on the game's own 1.0 release, and nothing in it is known to be wrong. The costs in the ladder still have not been tuned over a long game — that is a dial, not a defect, and every one of them is config.

Two things the game moved out from under the mod. The inventory grid's slot type was promoted out of InventoryGrid and its position field became a property, which the cargo overlay reads. And portal ZDOs are now bucketed by sector, so the call the server sweeps use to list every portal returns a dictionary rather than a list — there is a new one with the old shape, and the sweeps use it.

Jotunn 2.30.0 is now required, since 2.29.2 predates 1.0.

The Deep North's metals are sealed. Bloodgold and Petrified Tissue cannot travel by portal at all, whatever a site has built — the base game moves those by stone portal and nothing else, and this mod now leaves that alone instead of selling them back to you for a Fader trophy. The refusal says so in its own words rather than naming a stave that would not have helped. SealedItems is config if you disagree, and a stone portal is unaffected either way.

The staves are filed under Transportation in the build menu and carry the up-arrow vanilla puts on upgrades. On 1.0 they were appearing only under "show all".

The categories are worked around rather than fixed upstream: Jotunn has not yet ported them to 1.0's rebuilt build menu, so the mod sets each piece's category itself once Jotunn is done registering.

Everything else came through 1.0 unchanged — every patch target, every private field read, and the teleport timing seamless transit depends on were all checked against the new assembly rather than assumed.

0.9.0 — 2026-09-06

First release. Both features have been played in single player and confirmed on a real network. Numbered 0.9 rather than 1.0 because the costs have not been tuned over a long game, not because anything is known to be wrong.

Any-portal travel. Interact with a portal to pick any portal in the world off the map. The choice belongs to the portal and applies to everyone until someone re-aims it. Pointers are one-way: aiming a portal at your base does not make the return trip. Vanilla tag pairing still works untouched on any portal nobody has re-aimed.

Destination clearance. Six staves, each bought with a boss trophy and a little of the metal it unlocks. Stand one near a portal and that portal accepts those metals — and refuses the rest by name: "Iron cannot enter "Copper Mine" — no Bonemass's Stave there." Only the destination is ever checked, so an outpost with no staves can send ore to your base forever and never receive any.

Knowing before you commit. The portal's runes go dark when it will refuse what you are carrying. Inventory slots mark the stacks that cannot make this trip while you are near a portal, rather than the ones that can never teleport at all. Walking up gets you the reason in words. Holding a stave shows its range and a beam to the portal it would bind to.

Optional seamless transit. Off by default. A destination already in memory skips the loading screen; one that is not shows it for as long as loading actually takes, rather than for vanilla's fixed eight seconds.

Five console commands for looking at what the mod believes: stave_portals, stave_aim, stave_net, stave_items, and the prefab tools stave_prefabs / stave_inspect / stave_preview.

Which end pays. MaterialFlow decides whether a site's staves count for arriving, departing, or both. Both is the default: either end is enough, so a site with an iron stave takes iron from anywhere and sends it anywhere, and only two sites that both lack iron cannot pass it between them. Receive is the sharper original rule — only the destination counts, so outposts are one-way. Deliver mirrors that, for supplying a frontier rather than feeding a capital.

Known gaps

Clearance and MaterialFlow have both now been played on a real network, which were the two things holding this back. LogNetworkSync defaults off as of that confirmation — turn it on before reporting anything about portals disagreeing between machines.

What is left is judgement rather than correctness, and is listed in TESTING.md: the §4 costs have never been tuned, and whether Both is the right shipped default is an open question about how it feels over a long game.