Add an opt-in tier+category-aware inventory Sort Order — 155-item spec attached, 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.