The scope map #
| Scope | Current data |
|---|---|
| Account-wide | Physical appearance, body option, base clothing/outfit selections and their material colors |
| Player × community | One raider, one inventory, equipped earned gear, XP and level |
| Future account entitlement | Purely cosmetic ownership is a separate planned capability; not imported community gear or combat power |
Selecting the right raider #
The website selector lists communities where this authenticated player already has a raider. Direct visits prefer their own community where one exists; explicit validated community links override the default. Selection is not inferred from the Referer or a display name.
Inventory and character context update together. An unavailable explicit community returns a scoped error rather than silently showing a different community. Streamer activity and Twitch-live state are separate sources; activity is expiring application presence, not a login cookie or proof of Twitch streaming.
Shared appearance saves #
Saving Edit Character applies physical appearance and base clothing across communities. Existing alpha characters adopt the preferred shared look on a confirmed save; legacy rows are retained. Missing fields from compatible older clients preserve accepted fields rather than resetting them.
Active visuals use material choices, body_type and style_selection. The catalog is the allowlist: do not expose arbitrary hairstyle/eye geometry or unsupported body/outfit combinations just because a legacy physical-choice field exists.
Aprons cover the whole belt and tunic in presentation. Those underlying choices remain stored and return when the apron is removed. Compatibility is checked against equipped gear across the account's communities before a shared save.
Owned equipment is server-authoritative #
Slots are head, body, belt, pants, boots, left_hand and right_hand. Head means hats/helmets; hair remains physical appearance. Belt is one complete preset, not a second buckle control.
Equip requests include the accepted inventory revision. The server checks ownership, active definition, slot, level and visual compatibility in a transaction. Stale revisions reload/retry; rejected operations keep accepted state. There are no client XP, item-grant or purchase endpoints in this build.