Show authored container size classes in object names

[mamoru]

Important

This issue is implemented in the fresh MIT-licensed Go server under the replacement program. Its gameplay and content-design decisions remain authoritative. C, CPython, classic packet, file-path, and enum details below are historical evidence only; do not copy, translate, or structurally port GPL implementation code.

Replacement implementation contract

Preserve explicit authored size classes and every exclusion. Go sends typed visible metadata or localization keys; Rust composes presentation. Stable identity and game logic never depend on rendered English.

The server remains authoritative, consumes versioned compiled content, and exposes bounded generated Game Protocol 1 messages. Pure rules may use an approved typed CEL environment; Starlark is not required.

Required verification

• Preserve every observable rule and exclusion in the specification.
• Add deterministic Go unit/property tests and wrapper-managed scenarios.
• Add bounded content/protocol/persistence failure cases.
• Demonstrate zero runtime Python and no copied GPL source or tests.

Preserved product/design specification and historical implementation notes

Summary

Show a container's meaningful physical capacity class directly in its displayed object name—for example “small spruce chest” or “large locker”—so players can distinguish variants without examining each one.

Examine now reports an identified container's exact weight limit, which is useful detail but does not replace this at-a-glance enhancement.

Current behavior

• Containers store their maximum carried weight in object::weight_limit, in grams.
• server/src/types/player.c reports the exact limit when an identified container is examined.
• server/src/server/item.c builds server-authoritative short/display names from material, name, title, quantity, and status.
• The internal object name is also used by scripts, lookups, recipes, and content, so rewriting every base name or deriving identity from English text would be fragile.
• Container sub_type already owns behavior such as normal, corpse, quiver, player-owned, and party-owned containers; it should not also encode visual capacity.

Proposed design

Explicit capacity class

Add an authored container_size field with a small enum:

• none/unspecified;
• tiny;
• small;
• medium;
• large;
• huge.

The value describes the obvious physical capacity class shown to a player. Keep exact weight_limit and magical weight reduction as separate mechanics.

Do not derive the displayed class at runtime solely from weight_limit. A magical bag, fixed locker, quiver, corpse, bank proxy, or unusually dense container may have a mechanical limit that does not match its apparent size. A source audit may suggest initial classes from capacities, but authored data owns the final classification.

Display-name composition

Extend the central object-name builder so normal visible containers with a nonzero class include the localized class adjective in the natural name order. Preserve:

• quantity, material, base name, title, ownership, curse/unpaid/applied, and other status text;
• the canonical internal name and archetype ID;
• script/quest/recipe matching by stable identity;
• exact Examine output for identified capacity and weight reduction.

Capacity class is a visible physical property and should not require identification. Magical reduction and restricted contents remain identification-gated as today.

Do not add a client-only name heuristic. Item packets already receive server-rendered names, so the initial implementation should need no wire-format change.

Lookup behavior

Audit object lookup and command matching so both the displayed decorated name and canonical base name resolve predictably. Exact matching should prefer canonical identity/selected tag where available; free-text commands may accept the generated name without making scripts depend on it.

Personalized containers, corpses, quivers, system containers, and non-pickable fixtures need explicit inclusion/exclusion rules. Corpses should not become “large corpse” merely because they reuse CONTAINER.

Authoring migration

Inventory all authored CONTAINER archetypes and group them by base family, dimensions/face, weight_limit, pickability, and behavior. Assign size classes to player-facing storage variants that would otherwise be visually/name ambiguous.

Add editor metadata and documentation for the new field. The collector/map checker should report:

• invalid enum values;
• size applied to an excluded container behavior;
• multiple same-name/same-face player-facing variants with materially different capacities but no distinguishing class;
• suspicious family ordering, such as a “small” variant holding more than its “large” sibling, while allowing reviewed exceptions.

Do not automatically rename authored object names or generate compatibility aliases.

Delivery plan

1. Add the enum/field to object loading, saving, comparison, cloning, docs, Python bindings, and editor metadata.
2. Add a container-aware display-name helper with focused grammar/status tests.
3. Audit lookup paths and keep canonical matching separate from presentation.
4. Classify the current authored player-facing container families.
5. Add collection/checker diagnostics and runtime-test representative containers.

Acceptance criteria

• Same-name container variants show distinct tiny/small/medium/large/huge names without Examine.
• Exact weight limit and magical reduction remain available through identification/Examine.
• Capacity class is explicit authored metadata, not inferred from display text or runtime weight alone.
• Internal names/archetype IDs remain stable for scripts, quests, recipes, saves, and lookups.
• Materials, titles, ownership, quantities, and status suffixes compose grammatically with the size adjective.
• Corpses, quivers, personalized/system containers, and fixtures follow documented rules.
• Load/save/clone/compare, Python access, editor metadata, collection, and checker support are updated together.
• Existing content is audited so materially different visible variants are distinguishable.

Validation

Add unit tests for every class, identified/unidentified state, material/title/status combinations, personalized containers, excluded subtypes, canonical/displayed text lookup, and load/save/clone behavior. Run a source audit of all container archetypes, collect resources, run relevant map checks, and inspect representative chest, locker, bag, quiver, corpse, and bank containers in the client.

Historical request: distinguish different-capacity lockers and chests directly in their names rather than requiring Examine.

Content-schema dependency

This issue is a registered consumer of atrinik/content#15's authoritative schema/field metadata and atrinik/content#8's authored-source migration. Its new fields, registries, reference rules, editor descriptions, loader/compiler tables, Python exposure, documentation, and checker rules must be generated or consumed from that shared source of truth rather than added as a second hand-maintained catalog. If a temporary legacy adapter is required before migration completes, it must be generated from the atrinik/content#15-owned metadata and removed by atrinik/content#8.