Player Appearance And Equipment Persistence
Appearance and equipment persistence connect client customization, catalog-backed loadout rules, durable character rows, and realtime snapshots. Presentation systems render the result, but runtime authority owns which appearance state and equipped items are accepted.
Purpose
Use this page when changing character customization, adding equipment slots, debugging failed equipment commands, or deciding how paperdoll visuals become durable player state.
Durable State Shape
Character appearance is stored on the character record as JSON. Equipment state is stored in character_equipment_state as a normalized equipment snapshot. Bootstrap loads both into the player's initial snapshots so the client can render the avatar before live replication catches up.
Appearance Customization Validation
Client appearance state is packet-validated before runtime accepts it. The server decodes the appearance payload into the shared world type, validates field limits and enum values, updates authoritative session state, persists the JSON, and emits the updated appearance or player snapshot.
Never treat a UI-selected appearance value as already valid just because the editor can render it. Runtime validation still protects field budgets and compatibility.
Equipment Loadout Command Flow
Equipment changes flow through gameplay authority catalogs. The server validates expected revision, owned inventory item, equipment slot, level or tag requirements, and catalog loadout rules before accepting the command.
The resulting equipment snapshot is normalized before persistence and emission. Derived values, such as equipped tool identity, should come from the accepted equipment snapshot rather than from a separate client hint.
Expected Revisions
Equipment commands use revision checks to avoid applying stale UI actions over newer server state. A rejected revision is not a persistence failure. It means the client should refresh from the latest equipment snapshot and resubmit only if the user's intent still applies.
Persistence Retry Jobs
Appearance and equipment writes can be retried through the shared persistence retry system. Retry jobs carry character, realm, zone, payload, and idempotency metadata. If a write fails after the session state was updated, operators should inspect retry queues before assuming the player's state is lost.
Bootstrap And Replication
The bootstrap manifest sends appearance through the player snapshot and equipment through the equipment section. Later updates use realtime packets and UI sync paths. A client that renders the right equipment after login but loses it after a command likely has an authority or persistence issue, not a bootstrap issue.
Failure Modes
Invalid appearance usually points to packet validation. Equipment rejection usually points to stale revision, missing inventory ownership, unknown catalog item, slot mismatch, or unmet level/tag requirements. Persistence failures should appear in retry jobs or dead-letter inspection.