1 player appearance equipment persistence
forgejo-actions edited this page 2026-07-11 12:38:13 +00:00

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.