Add an opt-in tier+category-aware inventory Sort Order, complements #52448

Hi Keen,

This proposal complements Topic #52448 (Please add an Inventory Sorting Block), where Dax's Best-Answer reply proposes adding a whitelist/blacklist filter tab to inventory-bearing blocks — a great foundation. I'm submitting this as a separate topic because it addresses a distinct gap that #52448 doesn't touch: SE1's default item Sort Order, plus the auto-routing and stock-management layer that sits above per-block filtering to make multi-container fleets manageable without Programmable Block (PB) scripts.

The three tiers below are scoped so each can ship independently. Tier 1 is the highest-value lowest-risk piece and the only part that requires a concrete design decision right now; Tier 2/3 are framed as natural follow-ups.

Tier 1 (Primary) — A better Sort Order

SE1 doesn't sort inventory contents at all — items appear in the order they were first added to the container, and the inventory screen simply renders that list as-is (the display iterates the inventory's item list with no ordering step). In practice a container's contents are effectively unordered from the player's perspective: Steel Plate (the single most-used early-game component) lands in a different slot in every container depending on what arrived first, with no reliable place to look for it. The Iron-only components (InteriorPlate, SmallTube, Girder, Construction, SteelPlate, LargeTube) are never grouped together; Ammo and Foods are scattered the same way. The only alphabetical ordering anywhere in the inventory UI is the container list in the sidebar (by block name) — never the items inside a container.

Net effect: scanning inventory for a specific item is slower than it needs to be, and every dedicated survival player ends up installing a PB sort script to fix it. Players on official servers can't.

Ship a tier+category-aware ordering alongside SE1's current sort, available per-container via an opt-in Auto-Sort toggle (default OFF everywhere — existing saves' inventory arrangements stay exactly as they are today until the player explicitly opts in, matching SE1's established pattern of layering new behavior on top of existing defaults rather than changing them). A complete specification of the new master order — covering all 155 carryable items in SE1 including DLC and hidden items — is published here as a public reference:

ITEM_CLASSIFICATION.md — Full sort spec on GitHub Gist

The headline design of the new sort:

• Top-level categories follow gameplay roles: Ores, Ingots, Components, Tools, Weapons, Ammo, Medical Consumables, Foods, Seeds, Crops, Gas Bottles, Datapads, Packages, Currency, Trinkets, Special, Legacy, Fuel, Misc. These are the words players already use for their inventory — five (Ores, Ingots, Components, Ammo, Seeds) map 1:1 to SE's existing Conveyor Sorter categories, and the rest refine the engine's coarser buckets (e.g. splitting HandTool into Tools and Weapons, separating Foods from Consumables) into gameplay-meaningful groups.
• Within each category, items sort by tier ascending — most basic on top, endgame on bottom. Within a tier, by amount of the tier-defining material; final tiebreaker alphabetical.
• Foods specifically sort by hunger-meter Fill % (the actual gameplay-relevant metric) rather than alphabetical — so the player sees raw meat / drinks at the top, full-meter meals at the bottom.
• Weapons specifically sort by damage-per-shot band (three real bands of anti-personnel damage: 0 / 100 / 500) — Flare Gun first as signaling-only, then pistols and rifles together at 100 HP per shot to character health (300 on headshot), then rocket launchers at 500 AoE. Within a band, family + Mk-ascending. This puts wielded combat capability ahead of crafting cost as the primary sort key for the one category players scan by combat role, not by what to craft next.
• Unrecognized items (modded content, or anything not in the master list) fall to a defined fallback position — a Misc bucket at the end, sub-sorted by TypeId — so the sort degrades gracefully and never hides or drops an item. (Tier 2 refines this with TypeId-based auto-categorization.)

Auto-Sort behavior

Auto-Sort is the per-container toggle that controls whether the new master order is applied to a given block's inventory display. It sits alongside SE1's existing behavior as an opt-in — it does not change the engine's existing sort order or item placement until the player turns it on for a specific container.

• Primary toggle: in the terminal control panel (K-menu when looking at the block, alongside existing per-block settings like ShowOnHUD / ShowInTerminal), available on every inventory-bearing block regardless of conveyor connectivity. Character backpack and cockpit personal inventory have no terminal K-menu, so for those the inventory-screen indicator (below) is the only toggle.
• Inventory-screen indicator: a small "Auto-Sort: ON / OFF" badge at the top of the container's grid area, clickable to toggle. Doubles as an at-a-glance visual cue for the container's current sort state, so the player can tell — while looking at the inventory — why drag-and-drop is or isn't behaving as expected.
• Toggling ON triggers an immediate full sort applying the master order to the container's existing contents. Subsequent item adds/removes insert items at their sorted position (the classic insertion-sort algorithm; O(n) per change, stable in placement) so individual items slide into the right slot without other items visually shifting — important under live updates from refineries, conveyors, and assemblers.
• Manual drag-and-drop within an Auto-Sort = ON container is rejected. On drag-start, a tooltip appears near the cursor (e.g., "Auto-Sort is ON — drop will be ignored. Toggle Auto-Sort off to rearrange.") so the player learns the state before completing the action. Cross-container drags work normally — moving items between containers, or to/from the player's inventory, transfers as expected; the source compacts and the destination's Auto-Sort (if any) inserts the item into its sorted position.
• Damaged or unpowered blocks don't auto-sort. A block below its functional threshold (or unpowered, for block types that draw power) pauses auto-sort the same way refineries and assemblers pause when non-functional; the last-sorted arrangement simply freezes in place. Repairing or repowering resumes auto-sort and re-applies the master order. This matches the engine's existing behavior of grey-disabling terminal controls on non-functional blocks.
• Per-container sort direction (asc / desc) — each container has its own ascending/descending toggle, co-located with the Auto-Sort indicator in the inventory screen and mirrored in the terminal control panel directly below the Auto-Sort toggle. "Asc" follows the master spec's default (basic items top, endgame bottom); "desc" reverses. Greyed when Auto-Sort is OFF (direction is meaningless if items aren't sorted). Per-container scope lets a player have, say, ammo cargo sort one way and component cargo sort another.
• Auto-Sort = OFF also disables auto-stacking in that container, so individual items stay as singles — useful for keeping oxygen bottles as one-per-slot for clean one-at-a-time swap, medkits in dedicated hotbar slots, or any other layout where stack-merging would scramble the player's intent.

The attached spec includes the full 155-item enumeration, sort algorithm, tier justifications against in-game crafting costs, SubtypeId collision handling notes, and an implementation-reference appendix pointing at the relevant source files. A reviewer can copy the master list directly into game data; the per-item ordering is already worked out.

How this relates to #52448: Dax's proposal sits at the filtering layer — which items a container accepts (the same pattern Reactors, Refineries, Assemblers, and Gas Tanks already use at the inventory layer today). This proposal sits at the display ordering layer — how items are arranged when shown, in inventories, the filter-picker UI Dax describes, the Shift+F10 spawn menu, and anywhere else the engine renders an item list. Sort order is orthogonal to filtering; the two changes are independent and stack cleanly.

Tier 2 (Bonus) — Auto-routing & stock-quota layer above per-block filtering

#52448's whitelist/blacklist gives a player manual control over each block. At fleet scale (a few dozen containers across a station, plus haulers) that's still tedious. The category model that drives Tier 1's sort order also supports native cross-container auto-routing and stock-quota management — the functionality players currently get from GOAT Sorter and Isy's Inventory Manager.

Configuration convention: Tier 2 features are configured via CustomName tags, using square-bracket syntax. Tags can apply at either of two scopes — both reuse existing SE UX:

• Per-block — in the block's Custom Name field (terminal control panel). Example: a Large Cargo Container named

  Iron Cargo [Stock] SteelPlate=1000 [P:1]

  identifies itself as the primary fill destination for Steel Plate.
• Per-block-group — in the group's name (Terminal > Groups panel). The tag applies to every block in the group, no per-block edits required. Example: a block group named

  Backup Stockpiles [Locked]

  locks every member container from auto-routing in one stroke; a group named

  Iron Reserves [Stock] SteelPlate=2000

  aggregates a 2000-unit quota across all member containers as a single stock unit.

Tags can be combined within a single CustomName or group name. Per-block tags override per-group tags where they conflict (more specific wins). This is the same convention GOAT Sorter and Isy's IIM have established; players familiar with either will recognize the pattern immediately.

Concretely:

• Category-tagged containers: a category name in the CustomName routes items of that category to the container automatically. Example: CustomName

  Cargo Container Ores

  makes that container the destination for all ore items.
• Stock quotas: a container with [Stock] in its CustomName declares per-item desired levels with modifiers. Example: CustomName

  Components Box [Stock] SteelPlate=1000, Construction=500

  maintains those levels. Per-item modifiers include exact / maintain-min / limit-max / fill-all / pinned.
• Multi-container stock groups: a direct application of the dual-scope rule above — put [Stock] (with quota) in a block-group name and the quota aggregates across all member containers. Example: group named

  Iron Reserves [Stock] SteelPlate=2000

  maintains a 2000-unit total across the group, with the auto-router distributing them across members subject to any per-block [P:N] priorities.
• Exclusion tags in the container's CustomName: [Locked] (auto-route ignores the block; example:

  Private Stash [Locked]

  ), [No Sort] (block excluded from re-routing), [Hidden] (block excluded from counter LCDs).
• Priority: [P:N] tag in CustomName sets fill-order among same-category containers. Example: a container named

  Main Iron Cargo [P:1]

  fills before one named

  Overflow Iron [P:2]

  .
• Docking awareness: special handling when a ship is connector-docked, so the auto-route doesn't aggressively pull items from a hauler's inventory.
• Modded-item learning: auto-categorize items not in the master list based on TypeId, with a Misc fallback.
• Display LCDs: [ContainerLevel] and [Inventory] tag types in the LCD's CustomName for player-facing fill-level / item-total dashboards. Example: an LCD named

  Iron Stock LCD [Inventory]

  shows total Iron-related counts across the conveyor network.
• Rebalance same-tag containers: when two cargo containers share a category tag, distribute items evenly across them.

A small adjacent UX ask: SE1's block-groups UI currently only supports creating new groups — to change a group name today, you save a new group with the new name and then delete the old one. With block-group names becoming load-bearing configuration under the per-group-tag scope, allowing in-place rename of existing block groups (a small Groups-panel change) would substantially improve the iterate-and-adjust workflow. Scope-adjacent rather than blocking — block groups would be more useful in general with this fix, and the per-group-tag pattern here benefits directly.

Tier 2 reuses Tier 1's category model directly. The combination of Tier 1 (correct sort order) + #52448's per-block whitelist + Tier 2 (auto-routing + quotas) covers what GOAT/Isy's give today, but natively, in stock, on official servers.

Connectivity caveat: Tier 2's auto-routing inherently requires conveyor connectivity — items flow through the existing conveyor network. The intent here is to replicate the same routing behavior GOAT Sorter and Isy's IIM already deliver, and those PB scripts share the same conveyor requirement; Tier 2 isn't adding a new restriction. Non-conveyor inventory blocks (Lockers, Weapons Racks, most decorative storage furniture) opt out of auto-routing automatically; their contents remain manually curated. Tier 1's master sort order and Auto-Sort toggle still apply to those blocks though — display ordering is conveyor-independent.

Tier 3 (Bonus) — Production management

The original #52448 post by LJS mentioned an "inventory sorting/autocrafting block" combined; Dax's Best Answer scoped down to filtering only. The production-side piece remains worth doing — it's also a GOAT/Isy's feature today:

• Autocrafting: assemblers queue components based on [Stock] quotas and priority
• Refinery autocrafting: refineries queue ores → ingots based on ingot stock targets
• Special-block fueling: Reactor, O2/H2 Generator, and Irrigation System auto-fill from their conveyor network
• Per-machine exclusion: [Manual] tag opts an individual machine out of automated management
• Diagnostic LCDs: [LogScreen] tag for visible status / error output

Tier 3 is the most ambitious of the three; the framing here is "natural extension once Tier 2 lands," not "ship this in the same patch as Tier 1."

Why ship this natively (vs. recommend the PB scripts)

• Official servers don't allow PB scripts. Players who want to play on Keen-hosted official multiplayer get zero benefit from any community sort solution. This is a meaningful chunk of the player base.
• Console + Safe Mode have the same gap — same reason #52448 frames Dax's filter as Safe-Mode-friendly. Tier 1 inherits that benefit at zero risk; Tier 2/3 inherit it too (at greater implementation cost).
• PB scripts cost SimSpeed. A good Tier-2/3 PB script runs continuously in the background of every save it's installed on. Native code would cost a fraction of that.
• PB scripts are fragile. They break on game updates, sometimes require player setup steps to migrate, and can stagnate when their author moves on. Stock features don't have this problem.
• The community has done the design work for free. GOAT Sorter and Isy's IIM have iterated on the user model for years. The good ideas are stable and well-understood. Native implementation would not be starting from scratch.

On the GOAT Sorter's maintainers

For context: I'm a fan of the maintainers' work, and from what I've seen in the SE community, that sentiment is widely shared. GOAT Sorter has been a go-to script for serious survival players for a long time.

The GOAT Sorter PB script — the design baseline for Tier 2/3 in this proposal — is actively maintained by Katarina (WolfCraft Industries) and Khodrin. Their current guide on Steam Workshop documents the user model, edge cases, and tag conventions in detail:

GOAT Sorter - Inventory Manager Guide (most recent update: 2026-05-04)

I'd suggest Keen consider reaching out to them directly if Tier 2/3 moves forward — they hold years of accumulated design decisions, edge-case handling, and real-world user feedback that a native implementation would otherwise have to rediscover from scratch. Any such conversation about institutional knowledge, design review, or collaboration is strictly for Keen and the maintainers to negotiate directly, on whatever terms they choose. I'm flagging the opportunity, not speaking for them or volunteering their time.

Summary

• Complements #52448 (per-block whitelist/blacklist filter) — distinct, non-overlapping scope
• Tier 1 (primary, low-risk, ship-in-any-patch): ship a new tier+category-aware master Sort Order (specified in the attached 155-item spec), opt-in per-container via Auto-Sort toggle (default OFF — existing saves unchanged)
• Tier 2 (bonus, larger scope): native cross-container auto-routing + stock quotas (the layer above #52448's per-block filter)
• Tier 3 (bonus, follow-up): native production management (assembler/refinery autocrafting, special-block fueling)
• All three tiers reuse the same category model from the attached spec

Thanks for reading. Spec link again for convenience: ITEM_CLASSIFICATION.md (full sort spec)

Happy to discuss trade-offs in the comments. Voting if you want this would be much appreciated.