AutoChestSort

Name your chests. Teach them once. Let the server keep things tidy.

Dump everything into an Input chest and walk away. AutoChestSort moves it, stack by stack, into the chests you taught. Chests that hold the wrong thing sort themselves, a group spreads its stock sensibly over its chests, and Misc catches the overflow until there is room again.

No client magic, no item loss, no automation beyond your storage.

One modded player is enough. The mod lives on the server. One person with it installed names the chests, teaches the groups and holds the config. With allowVanillaClients = true everyone else can play completely vanilla and still gets their Input chest emptied.

Read this first

This is version 1.1. Back up your world before you use it. The mod writes into chest inventories, and it will have rough edges. Names, groups, the learn dialog, Input sorting, chest-to-chest tidying, clusters, the spreading stage, the beautify pass and the config sync are built and tested on a dedicated server, but that is not the same as being finished.

Why would you want this

Every Valheim player knows the moment: you come home with a full inventory and spend the next five minutes walking past twelve chests, shuffling stacks around.

• The sorting marathon. Wood to the wood chest, ore to the smelter room, food to the kitchen. Every trip home turns into a logistics job.
• Where did I put it? Unlabelled chests are lucky dips. Signs help you find things, but they do not put anything away, and they do not stop three chests from each holding a bit of everything.
• Multiplayer entropy. On a server everyone sorts differently. The system one player builds is gone after the next visitor.

The idea: instead of telling the mod where every item goes, you tell the chest once. Put in what belongs there, press +, done. From then on the whole group knows its items, and the server does the walking.

What does the mod do

Names, groups, and a server that does the work. Nothing else changes about how you play.

• Chests get names. A name field right in the chest window. The name lives in the chest itself, so the game saves and syncs it. It also shows in the hover text before you open the chest.
• Same name, same group. Every chest called Building is one group. Rename one chest and the whole group follows. Case does not matter. Works for all six vanilla chests, from the barrel to the wardrobe.
• Groups learn their items. Fill a chest, press +: the item types inside now belong to that group. A dialog lets you replace the old list or merge into it.
• Input chests. A chest named Input is your drop-off point. The server empties it one stack per second into the group chests of the same cluster.
• Chests tidy themselves. No Input chest needed. Drop ore into the wood chest and the server carries it to the ore chest. Teach an item to a new group and every chest in range hands it over.
• A group spreads its stock. Two wood-and-stone chests end up as one wood chest and one stone chest. Big amounts push each other apart, small ones may share, partial stacks are poured together.
• Misc is the buffer. Items with no group in the cluster, overflow from full group chests and unknown items land in Misc. As soon as a matching chest has space again, Misc sends it back.
• Clusters, not a radius. Chests standing within 12 m of each other chain into one cluster, and a cluster is one store. Your outpost across the valley is its own store. Nothing ever travels between them.
• Optional: tidy-looking chests. Switch it on and every group chest is packed from the top left, equals next to equals, full stacks first. Off by default.
• The server sorts. Only the server. In singleplayer, or when you host from your own game, you are the server. No client ever moves an item, so two players cannot race each other. Every move adds to the target first and removes from the source second. Open chests are never touched, a chest gets a cooldown after it is closed, and the server reads every move back to prove it landed. It keeps out of an unroofed chest in the moment rain damage is due to write to it, and it watches every move for three minutes afterwards and reports one that a foreign write undid.
• English and German, quiet log. Tooltips, messages and dialogs show in each client's language, English as the fallback. Input and Misc stay the same in both, because they are data, not labels.

The sorting chain

Everything happens inside one cluster of chests. One move per second at most. Six steps per tick, and a step only gets its turn when every step before it found nothing to do.

Everything that does not belong in a group leaves it before the mod works out how to spread the rest, and Misc is emptied back into a group after that group has made room. Nothing is made to look tidy while anything else still has real work to do.

Out of an Input chest, in this order:

1. Group chests of the same cluster whose group knows the item type and that have room.
2. Of those, the chest that already holds the most of that type wins. Ties go to the chest built first, never to the nearer one.
3. None holds it yet? Any chest of the group with space.
4. Otherwise a Misc chest of the cluster, preferring one that already has a stack of this type. Also for items the server does not know.
5. Otherwise the stack stays in Input. Nothing gets lost, nothing leaves the cluster.

If somebody has any chest of that group open, or just closed it, the item type waits instead of landing somewhere that is not its home.

Out of any other chest:

• Group chest: a stack is misplaced if its type was taught to a different group. It moves to a chest of that group in the cluster. Items that belong to no group stay where you put them unless you enable step 2.
• Misc chest: anything with a group leaves for a chest of that group as soon as one in the cluster has space. That is how overflow and early mistakes find their way home.
• Never: group chest to Misc, Misc to another Misc, or anything across cluster borders.
• A group chest has to be quiet twice as long as an Input chest before the server takes anything out of it. A beautify rewrite waits one minute.
• The sorter measures every attempt and stops for the second when it has spent its milliseconds. A big base sorts slower. The server does not.

Clusters instead of a radius. Two named chests are neighbours when they stand at most graphEdgeRadius (12 m) apart, and everything connected through a chain of neighbours is one cluster. Five chests along a wall with 4 m gaps are one cluster even though the first and the last are 16 m apart. A workshop forty metres away is its own cluster, and nothing ever travels between the two. A chest with no name is not a node and cannot bridge anything.

The one that surprises people: a chain of named chests joins two bases. Storage along a path, a chest at a landing spot, a row on a long pier. If every gap is under 12 m, the far base becomes part of the same store. If you did not mean that, lower graphEdgeRadius, take the name off the bridging chest, or use different group names. The server warns once when a cluster grows past 40 chests or 80 m across, and acs_dump lists every cluster.

Spreading and tidying

Two stages work within a group. One decides which chest holds what and is on by default. The other decides how a single chest looks and is off by default.

Spreading a group over its chests (relocateItemStacks, on by default). For every group in a cluster the mod works out, once, which item type belongs into which chest and how much of it. Then it moves one stack per second towards that layout. Two Building chests holding a mix of wood and stone end up as one wood chest and one stone chest. The plan only changes when what the group holds changes (you put something in or take something out, or an Input or tidy-up move brings items); the mod's own spreading moves, merges and beautify rewrites keep it, so nothing wanders.

• While a chest of the group is open or was just closed, the plan is kept as it is and nothing is rebuilt. The next plan is worked out once every chest is quiet again.
• Big amounts push apart, small ones may share. A type needing more than two slots wants a chest of its own. A handful of seeds does not deserve one.
• A single-type chest may be filled to the brim. A mixed chest keeps one free slot, if the group can afford it. That slot is what lets the next move happen.
• Partial stacks are poured together. 10 + 3 wood become 13.
• Equal chests: least movement wins. Among chests of the same size the mod picks the layout that moves the fewest items, so what already lies there decides. After updating to 1.1.0 a group may reorder itself once, then it stays put.
• Tip: two big stack types in one group (wood and stone, say)? Give each its own group. Then a stray stack is simply carried out instead of the planner reshuffling both types.
• A brim-full chest gets unblocked with a parked stack: one stack is moved to another chest of the same group to gain a slot, and fetched back later. Wood in the stone chest for a minute is the mod working, not misplacing.
• Not touched: equipment, tools, items this server does not know, oversized stacks, anything of another group.

Making a chest look tidy (beautifyChestItemOrder, off by default). It changes nothing about where your items are. No unit leaves the chest. Only which slot a stack sits in, and how the stacks are split.

• Packed from the top left, row by row, no gaps. Named group chests only, never Input or Misc.
• Equals next to equals, in progression order: Meadows first, then Black Forest, Swamp, Mountains, Plains, Mistlands, Ashlands, Deep North. Alphabetical inside a tier. Wood before fine wood, copper before iron.
• Full stacks first, one partial stack per type at most. 6/10 + 7/10 becomes 10/10 + 3/10.
• Gear keeps your order. Tools, weapons and armour do not stack, so they are only moved up to close gaps.
• One write per chest, after one quiet minute, read back to prove it arrived.
• Hand-made arrangements are replaced. If you sorted a chest a particular way on purpose, leave this off. That is exactly why it is off by default.

What it does not do

AutoChestSort is a storage mod, not an automation mod. The goal is the vanilla experience without the sorting headache.

• No feeding of smelters, kilns or forges. Ore never walks into a smelter, wood never into a kiln, coal never into a blast furnace. Fuelling and crafting stay your job.
• No teleporting across the map. Every move stays inside the cluster the source chest belongs to, and only while a player is nearby. Your outpost does not drain into your main base.
• No touching your inventory. The mod moves stacks between chests. Never out of your pockets, never into them.
• No carts, ships, tombstones. The six stationary vanilla chests you build yourself, and mod chests you list explicitly. No ships, carts, personal chests, tombstones, dungeon or treasure chests. A chest you never name is never touched.

Installation

The mod has to run on the server, because the server does the sorting. There is no client fallback. In singleplayer, or when you host a world from your own game, your game is the server and the client install is all you need.

Whether players without the mod may join is one switch: by default allowVanillaClients = false turns them away with the game's usual "incompatible version" message. Set it to true and you have a server-only setup: one player with the mod names chests and teaches groups, everyone else plays pure vanilla and still gets sorted. A client that does have the mod must always match the server version down to the patch digit.

Option A: r2modman or Thunderstore Mod Manager

1. Create or open a Valheim profile.
2. Search for AutoChestSort and install it. BepInExPack and Jotunn come along automatically.
3. Start the game once. The config file is created with its defaults.

For a dedicated server, the mod manager has a separate game entry Valheim Dedicated Server. Create a profile there, install AutoChestSort the same way, and point the profile at your valheim_server.exe. Same package, same dependencies, nothing else to do.

Option B: Manual

1. Install BepInExPack Valheim and run the game once so the folders exist.
2. Unpack Jotunn into BepInEx/plugins/.
3. Copy both AutoChestSort.dll and AutoChestSort.Core.dll into BepInEx/plugins/AutoChestSort/. The plugin does not load without the second one.
4. Repeat on the dedicated server.

What it looks like afterwards, on client and server alike:

BepInEx/
├── plugins/
│   ├── AutoChestSort/
│   │   ├── AutoChestSort.dll        # the mod
│   │   └── AutoChestSort.Core.dll   # its logic library, required
│   └── ValheimModding-Jotunn/       # dependency
└── config/
    ├── nexxy.valheim.autochestsort.cfg   # settings, created on first start
    └── AutoChestSort/
        ├── incidents.log                 # incident ledger, server only, created with the first incident
        └── worlds/
            └── <world>.yaml              # group assignments per world, server only

Nothing has to be copied between client and server. The fifteen server settings are pushed to every connected client automatically. Only two settings are local to each machine: debug logging and the hover line.

Dependencies and supported chests

Built and tested against Valheim 1.0.15 and 1.0.16, client and dedicated server.

The six stationary chests you build yourself are always supported and cannot be switched off. A chest only takes part once you give it a name.

Chests from other mods can be listed in additionalChestPrefabs in the server config, at your own risk: a container with its own inventory logic reads as empty and is never written. The grid is read off the prefab, never guessed.

Known incompatibility: SmartContainers. It routes items into chests from the client side, so both mods would fight over the same stacks. Do not run them together.

Using it

Everything happens in the chest window. Open a chest and the AutoChestSort panel appears below the inventory: a name field, four buttons, an info line and a status line.

Five minutes to a sorted base

1. Name a chest. Open a chest, type Building into the name field, press Enter. The info line says "Group: Building - 1 chest(s)". A name that already exists makes the chest join that group. Changing the name of a group chest renames the whole group.
2. Teach the group what belongs in it. Put one of everything that should live here into the chest: wood, stone, core wood. Press +, then pick Replace or Merge.
3. Add more chests to the group. Every further chest named Building belongs to the group and knows the same items. Nothing to re-teach. Keep the chests within 12 m of a neighbour so they form one cluster.
4. Optional: an Input chest. Open an empty chest in the same cluster and name it Input. From now on the server empties whatever you throw in there. You can have several, at different bases too, and you do not need one at all.
5. Optional: a Misc chest as the buffer. Open a nameless, empty chest and press +, or type Misc as the name.

Good habit: teach the group chests first, then fill the Input chest. The sorter works one stack per second, so a full chest takes about half a minute and you can watch it empty. A chest you just built or just named is picked up after the next world scan, so give it a minute. After switching the mod on in an old base, expect a wave of moves until every group has sorted itself out.

Several players. Changes only work on the chest you have open. If someone else has a chest of the same group open, your buttons are greyed out ("Group locked"), and that group's item types wait instead of landing elsewhere.

Groups are world-wide, stores are local. A group name is one vocabulary for the whole world: Building at base A and Building at base B know the same items. Sorting itself is always local to a cluster.

Teaching a group

You never type item names. You show the chest what belongs in it and press +.

1. Fill the chest. One of each is enough. Quantity does not matter, only the item types. The chest needs a name first; on a nameless chest with contents + is greyed out.
2. Press +. The client asks the server for a preview. The dialog lists what is new for the group and what a Replace would drop, because it is not in the chest right now.
3. Replace or Merge. Replace makes the chest's contents the whole list. Merge keeps everything the group already knew and adds the new types. If both would do the same thing, there is just one Learn button.
4. Conflicts, one at a time. An item type belongs to exactly one group. If Coal is already in Fuel, you are asked: Yes moves it here, No leaves it in Fuel and skips it, Cancel aborts the whole operation and changes nothing.
5. Done. Every chest of the group knows it immediately, nothing to repeat per chest. The i button shows the list any time.

Re-teach any time: put the new item in, press +, choose Merge. To remove a type, open a chest that has everything except that type and choose Replace.

Teaching moves things. The moment an item type joins a new group, every chest in a player's range starts handing that type over to its new home, one stack per second. Move Coal from Fuel to Smelting and the fuel chests empty themselves of coal. On a large stock it takes a while.

The Misc shortcut. + on a chest with no name and nothing inside does not open the dialog. It turns the chest into a Misc chest right away. Roles never learn items: Input and Misc have all buttons except Reset greyed out.

Configuration

One BepInEx config file, BepInEx/config/nexxy.valheim.autochestsort.cfg, created with its defaults on first start. Seventeen keys: fifteen in [Server], admin-only and synced to every connected client, and two in [Client] that stay on your own machine. Saving the file reloads it without a restart, and acs_config reload does the same by hand.

The group assignments live per world in BepInEx/config/AutoChestSort/worlds/<world>.yaml, written by the server. Item types are the internal prefab names. It belongs to the world: copy the world, copy the file. The comment lines at its top say how to treat it: the file is written by AutoChestSort, comments and layout are lost on the next save, and it should be edited by hand only to repair a locked file, then reloaded. Teach groups in the chest panel instead.

The group file is not reloaded by itself (since 1.1.0). After an edit, press ↻ in a chest panel or run acs_groups_reload; an edit without a reload is ignored, and the server locks the file rather than overwrite it. Before every save the server keeps the previous, loadable version as <world>.yaml.bak. The file is checked strictly: one line the server cannot read copies the file aside as <world>.yaml.broken-<time> (at most five) and locks it: group changes are refused, the sorter pauses, the chest panel shows only malformed group yml – see server log and the reload button, and two # ACS-PROBLEM: lines at the top of the file name the first bad line — until the file is repaired and reloaded. A repaired file that still carries those two lines is simply saved again without them - no .broken copy, no warning. Mistakes in single items are corrected on start and reload instead: an item in two groups stays in the first one, an item name the game does not know is removed, and the corrected file is saved right away (the original goes into the .broken copy first). If most items look unknown, nothing is removed and the file locks. Nothing but a # comment may follow the closing ] of an item list (bau: [Wood] Stone locks), an item name with spaces is an error (bau: Wood Stone locks; write [Wood, Stone]), and a list inside a list entry is an error (- [Wood] or - wood: Wood locks; write - Wood per line). Save the file as UTF-8: a file saved as Latin-1/ANSI or UTF-16 is not read at all and locks without a hint, the log says so. An empty file (ACS_groups: {}) is valid.

Console (F5): acs_sort status shows counters, clusters, the time budget, parked stacks, the beautify stage and, since 1.1.0, the lines sorter distribution planning (plan changes by cause, plan builds skipped while a chest was blocked), sorter revert watch and sorter rain guard. acs_sort pause and acs_sort resume stop and restart the sorter. acs_dump lists every cluster and chest, with the same lines plus sorter provenance (own writes against changes from outside). acs_incidents [n] lists the last incidents from the server's incident ledger (default 10). acs_config status and acs_config reload handle the config. acs_group shows a chest's group. acs_groups_reload makes the server read the group file again, from any player's console, without an open chest. acs_debug on|off toggles verbose logging of your own game; acs_debug_server on|off|status does the same for the server (on/off for admins only).

FAQ and limits

Can players without the mod join my server? Yes, with one switch. By default (allowVanillaClients = false) a server refuses a client that does not run AutoChestSort. Set it to true and vanilla players join and play normally: no name field, no buttons, no teaching, but whatever they throw into an Input chest gets sorted anyway, because the server does it. Players with the mod always need the same version as the server.

What exactly is a cluster? All named chests that hang together through neighbours standing at most 12 m apart. A cluster is one store: every move stays inside it, and standing next to any chest of it wakes the whole cluster. A chest with no neighbour is its own cluster and can only be tidied inside itself.

Why is my Input chest not sorting? The usual suspects, in order: nobody is within 28 m of any chest of the cluster; the Input chest is not in the same cluster as the group chests (run acs_dump); somebody has a chest of the target group open or just closed it; you just built or renamed the chest and the next world scan is up to 60 s away; the group does not know the item type and there is no Misc chest in the cluster; somebody paused the sorter; the group file is locked (the chest panel then shows only a text and ↻); it is raining on unroofed chests of the group and the rain guard makes them wait; the mod is not running on the server.

My groups are gone after a server restart. That was a bug in 1.0.0: a group file holding only ACS_groups: {} was taken as broken, and nothing taught was saved from then on. Fixed in 1.1.0. On 1.0.0: stop the server, delete <world>.yaml if it holds nothing but comments and ACS_groups: {}, start again and teach the groups once more — or simply update to 1.1.0.

The chest panel only says "malformed group yml – see server log". The server could not read the group file, so it locked it: nothing is saved or sorted until it is fixed. The top of the group file (# ACS-PROBLEM:) and the server log name the line. Fix the file (or put <world>.yaml.bak back), then press ↻ or run acs_groups_reload. The same goes for "group yml changed on server – reload": somebody edited the file while the server ran; the reload takes the edit over and drops group changes the server had not saved yet.

An item disappeared from a group after a restart. The server removed an item name it did not know (a typo, or a mod that is not loaded) or an item that stood in two groups. The server log names each one with group and line; the original file is in the newest <world>.yaml.broken-*.

Why is there wood in my stone chest all of a sudden? For a minute, that is the spreading stage at work. A brim-full chest has no slot to work with, so one stack is parked in another chest of the same group and fetched back as soon as the plan can take it. It never leaves the group and never leaves the cluster.

Will it rearrange chests I sorted by hand? Between chests of a group, yes, by default. Set relocateItemStacks = false if you like your chests exactly as you arranged them. Inside a chest, no, unless you switch beautifyChestItemOrder on.

How fast is it? One stack per second at most, shared across all chests in the world. That is deliberate: the server must never stall, and moves must never race a player. On top of that there is a CPU budget of a few milliseconds per second, so a huge base sorts slower rather than lagging everyone. Several Input chests take turns, so more Input chests mean more time, not more speed.

What happens when a group chest is full? The next chest of the group gets it. If every chest of the group in the cluster is full, the stack goes to Misc as a buffer. As soon as a group chest has space again, Misc hands it back. Nothing is thrown away and nothing stays stuck in Input forever.

Can I have different groups per base? Not in this version. Group names are world-wide, an item type belongs to the same group everywhere. Separate bases still work, because sorting only ever happens inside a cluster. A per-base scope is on the idea list.

What about items and chests from other mods? Items can be taught like any other as long as the server knows the mod. Items the server does not know are moved to Misc untouched: the mod copies the raw data byte for byte instead of interpreting it, so nothing is lost.

Can a player overwrite a server move? Rarely. While you have a chest open, your game owns its inventory and writes it back when you close it. If that lands on top of a move the server just made, the stack exists twice. Nothing is lost; the server counts and logs it. The cooldown after closing, doubled for group chests, keeps this rare. Do not lower it.

Why does sorting pause in the rain? An unroofed chest takes rain damage every 60 seconds, and on a dedicated server the game of a nearby player writes that into the chest. A server move in the same instant can be silently undone. So the rain guard learns each wet chest's rhythm from its health and keeps out of it for two seconds around every expected hit; a waiting chest holds up its group. With many wet chests a group can wait for minutes. That is on purpose - waiting beats a lost item. A roof ends it. Not covered: the first hit of each rain, attacks, and support updates of a chest on a building; those keep the usual quiet window.

What is incidents.log? After every move the server watches both chests for up to three minutes. If a foreign write puts one back on exactly its old content, with no player at the chest, the move was undone: the item is probably lost (target) or doubled (source). The server logs a warning, counts it as reverts, may raise the chat warning, and appends one line to BepInEx/config/AutoChestSort/incidents.log (all worlds, created with the first incident). It does not fix anything, it reports. acs_incidents lists the entries. If a player was at the chest in that time, it is only an info line: they most likely took the stack out again.

Other limits. One item type belongs to exactly one group, so teaching it to a second group takes it out of the first (you get asked). A crashed client can leave a chest marked as open, which blocks group-wide changes until someone opens and closes that chest again. The name field blocks keyboard input while you type in it, and releasing it again can release another mod's input block at the same time.

The full manual

This page is the short version. The complete handbook ships with the package as MANUAL.md, next to the DLLs in BepInEx/plugins/NexGaming-AutoChestSort/. It covers every setting with its range, the console commands, the group file format with backup and repair, troubleshooting and what ends up in the log.

License

AutoChestSort is released under the MIT License, Copyright (c) 2026 Nexxy. You may use, modify and pass on the mod, including as part of something else, as long as the copyright notice and the license text travel with it. The full text ships with this package as LICENSE, next to the DLLs in BepInEx/plugins/NexGaming-AutoChestSort/.

Valheim is a title by Iron Gate Studio. This mod is a community project and is not affiliated with Iron Gate or Coffee Stain.

Changelog

1.1.0 (2026-10-01)

Client and server must both run 1.1.0: there are new answers between them, and the version check turns a mismatched client away.

Fixed

• Groups were lost on a server restart. A group file holding only ACS_groups: {} (what the server writes for a world without groups) was taken as broken, and from then on nothing was saved. Everything taught afterwards was gone after the next restart. An empty file is valid now: ACS_groups: {}, ACS_groups: with nothing below it, an empty or missing file.
• A repaired group file that still carries the hint loads quietly. If the admin fixed the file but left the two # ACS-PROBLEM: lines at the top, the server loads it like any other file and saves it again without them: no .broken-* copy, no warning, and the .bak keeps the last clean version. Before, the leftover hint alone counted as a correction, with a warning and a copy that was identical to the file saved right after.
• The group file says who writes it. Two new comment lines at the top: the file is written by AutoChestSort, comments and layout are lost on the next save, and it should be edited only to repair a locked file, then reloaded (panel button or acs_groups_reload).

Added

• Revert watch. After a move has passed its read back, ACS keeps watching both chests for up to 180 s. If a foreign write puts one of them back on exactly the content it had before the move, with no sign of a player, it is recorded as an incident: a warning in the server log (target chest: the moved item is probably lost; source chest: it probably exists twice), the conflict counter reverts, and the chat warning counts it like any other conflict. ACS does not compensate it, it reports it. With player activity at the chest in that time (opened, in use, a new owner, several writes) it is only an info line, not an incident. Background: on a dedicated server the game of a player near a chest can write to it (rain damage, building support) in the same instant as a server move, both writes carry the same revision and each side drops the other one, and the next write from the player's game can silently bring the old content back - after the read back has already said "ok".
• Incident ledger incidents.log. One line per incident, append-only, shared by all worlds of the server, in the AutoChestSort folder of the BepInEx config next to worlds/. It is created with the first incident. Every server start logs incident ledger: N incident(s) on record (this world: M), last: ....
• acs_incidents [n] lists the last n incidents from the server's ledger, newest first (default 10, at most 100), with the totals overall and per world. Any player, no open chest needed, read only.
• Rain guard. An unroofed chest takes rain damage every 60 seconds, and every hit is a write into the chest. ACS learns that rhythm from the chest's health and does not write to the chest in the two seconds around its next expected hit (a few seconds longer after a repair). The new wait reason ForeignWriteExpected (rain write expected, N s left) shows in the debug log, in acs_sort status and in acs_dump. Only chests of clusters with a player within activationRadius are sampled, every 0.25 s. No setting. Not covered: the first hit of each rain period, attacks, and chests on a building that the game rewrites for its support - those keep the usual quiet window.
• New lines in acs_sort status and acs_dump: sorter rain guard: ... and sorter revert watch: ...; acs_dump also shows sorter provenance: ... (how many chest changes were ACS's own writes and how many came from outside).
• Move lines in the debug log carry a move number per session (move #12 ...), so a warning of the revert watch can be matched to its move.
• acs_debug_server on|off|status switches the server's verbose log live from the client console. on and off are for admins only (the server's admin list); anybody else gets refused, you are not on the admin list and the server logs the attempt. status is open to every player. acs_debug is now local only: it switches the log of your own game and no longer the server's.

Changed

• No automatic reload of the group file any more. The server reads it when the world starts and after that only on request: the new ↻ button in the chest panel or the new console command acs_groups_reload (any player, no open chest needed, at most every 5 seconds).
  • An edit without a reload is ignored.
  • The server does not overwrite it, it locks instead: if the file on disk changed when the server wants to save, it saves nothing and waits for a reload.
  • A learn confirmed in the UI can be discarded by the reload: the reload takes the edit over and drops the group changes the server had not saved yet. The server log lists them.
  • Hot reload of the config file (.cfg) is unchanged.
• A broken group file locks instead of guessing. Every player's chest panel shows only malformed group yml – see server log (or group yml changed on server – reload) in the name field, the four buttons are hidden and only the reload button is there. After a failed reload the player who pressed it reads reload failed – malformed group yml. Every group change is refused while the file is locked.
• The sorter pauses while the group file is locked, tidy-up and group reconcile included, so a start with a broken file can no longer empty Input and group chests into Misc. Input chests fill up until the file is repaired and reloaded.
• Strict check of the group file — this can lock files that loaded in 1.0.0. One line the server cannot read now locks the whole file, even next to readable groups: a line without name: value, a group line without indentation, anything after the block, an empty group name, input/misc as a group, an empty item name (- ""). 1.0.0 skipped such lines and used the rest; the next save then dropped them without a trace.
• Content after a closing ] is an error. Only a # comment may follow an item list; bau: [Wood] Stone or test: [] :: lock the file. 1.0.0 ignored the rest of the line, so Stone was lost without a word.
• An item name with spaces is an error. No prefab name contains a space, so bau: Wood Stone, - Wood Stone or [Wood Stone, Resin] lock the file (quoted names too); write one item per entry or [Wood, Stone]. Before, such an entry was read as the single unknown item Wood Stone and removed.
• A list inside a list entry is an error. A - entry holds one item name, so - [Wood], - [Wood, Stone], - [], - {} or - wood: Wood lock the file; write - Wood per line or bau: [Wood, Stone]. Before, - [Wood] was read as the unknown item [Wood] and removed. A quoted - "[Wood]" is still read as an item name and removed as unknown.
• The group file must be UTF-8 (with or without BOM). A file saved as Latin-1/ANSI or with a UTF-16/32 byte order mark is not read at all: the file locks, the log says "the group file is not valid UTF-8 (saved as Latin-1/ANSI?) - save it as UTF-8 and reload" and names the first bad byte, no hint is written into it and it stays untouched; a byte-exact .broken-* copy is made. 1.0.0 read such a file with � in place of every umlaut and saved that on the next change.
• Hint at the top of a locked file. The server writes two # ACS-PROBLEM: comment lines at the top of the group file naming the first problem and its line (the rest of the file stays as it was), so the admin finds it without the log. Written once, only with a quarantine copy in place and only into UTF-8 files (a file that is not UTF-8 is locked without a hint); removed by the first save after the repair.
• Autocorrect of item mistakes on start and reload. An item in two groups stays in the first one, an item or a group listed twice is merged, and an item name the game does not know is removed (in 1.0.0 it was only warned about). The corrected file is saved right away, every fix is logged with group and line. The original goes into a .broken-* copy first — the admin's comments and layout survive only there. Nothing is corrected when that copy cannot be written.
• Safety net for unknown items. If all items are unknown, more than half of them or more than 20, nothing is removed and the file locks instead ("prefab check looks unreliable or the file lists mostly unknown items"): that looks like a missing mod, not like typos. While the game cannot answer the check yet, nothing counts as unknown.
• Backup and quarantine next to the group file. Before every save the previous version is kept as <world>.yaml.bak — always a clean, loadable version, and an empty one never replaces a .bak that holds groups; a corrected original never becomes the .bak. A broken file, or one that is about to be corrected, is copied as <world>.yaml.broken-yyyyMMdd-HHmmss before anything else happens, at most five copies.
• New answer codes between client and server for the lock (malformed, reload failed, changed on disk) and a new request for the reload. A 1.0.0 client cannot talk to a 1.1.0 server, and the other way round.
• Beautify waits 20× closeCooldownSeconds instead of 60× — one minute at the default instead of three. The log line for a chest that is not quiet yet names the quiet window, the time left and the last change (quiet window 60 s, 42 s left, last change 18 s ago), and is written again when the window restarts because the chest changed.
• Spreading: among chests of equal size the least movement wins. When several chests of a group have the same usable room, the planner now picks the assignment of item types to those chests that moves the fewest items (an exact least-movement assignment instead of a tiebreak). This stops the ping-pong where a whole stack type moved between two equal chests because a few stacks of another type tipped the tiebreak. After the update a group may reorder itself once - small types can move to the equal chest where they now belong; after that the layout stays put. Not covered: a tie between chests of different size that happen to have the same usable room (a bigger chest partly taken up by gear the mod does not move, for example). That case is known and can still cost the odd extra move; the cycle guard stops a real back and forth.
• The spreading plan is kept while a chest of the group is open or settling. No more rebuilds and repeated "equal chests reassigned" lines while somebody fills a chest; the next plan is worked out once every chest of the group is quiet again, and compared with the kept one.
• ACS's own writes keep the plan valid. A beautify rewrite, a merge of partial stacks inside a chest and the spreading moves themselves no longer throw the plan away. An Input or tidy-up move into a group chest does change what the group holds, so the plan is rebuilt; the debug log tells such an own move apart from a change from outside.
• The "cannot be sorted any further" line is keyed by the content of the group, so a beautify rewrite no longer repeats it.
• acs_sort status and acs_dump have a new line sorter distribution planning: ...: plan changes N (content changed N, inside one class of equal chests N, cross-class split ties N), reassigned among equal chests N, plan build max X ms, last Y ms, cycle stops N, plan builds skipped while blocked N. A plan change after a real change of content is counted as content changed, not as a change inside a class of equal chests.

Requirements: BepInExPack 5.4.2351, Jotunn 2.30.2, Valheim 1.0.x (tested on 1.0.15 and 1.0.16).

1.0.0 (2026-09-18)

First public release.

• Name chests in the chest window; chests with the same name form a group.
• Teach a group with +: the item types lying in that chest now belong to the group.
• The server empties every Input chest, one stack per second, into the matching group chest nearby, or into Misc, or leaves the stack where it is.
• Chest-to-chest tidying: items in the wrong chest move to their group, unassigned items to Misc.
• Clusters: chests within graphEdgeRadius (default 12 m) of each other form one sorting area.
• Spreading stage: a group with several chests is filled so that one chest holds one item type wherever possible, with stack top-ups and buffer moves.
• Optional beautify pass (beautifyChestItemOrder, off by default): tidies each group chest, same items side by side, full stacks first.
• Server settings in a BepInEx .cfg with Jotunn admin sync and hot reload; acs_* console commands for status, dump and diagnostics.
• allowVanillaClients (default false): a server refuses clients without the mod. Set it to true for mixed play.
• Every move is checked: add at the target, remove at the source, read back and verify. Counters for lost, duplicated and unbalanced items in acs_sort status.

Requirements: BepInExPack 5.4.2350, Jotunn 2.30.0, Valheim 1.0.x (tested on 1.0.12 and 1.0.14). The mod has to run on the server and, unless allowVanillaClients is on, on every client.