WardrobeSection

Remarks

Per character, where the collection it draws on is per account. A mount earned on one character is owned by all of them and lives in IAccountGrain; which of them is wearing the Tabard of the Ninth is one character's business. That split is why only the wardrobe is here — the unlocks are not this section's to write, and storing them twice would be two records of one fact that can disagree.

⚠ Slots are written as names and never as tag indices, and this is the same class of bug as writing a gameplay PlayerId to the database. A GameplayTag is an index into a pre-order walk of the build's tag tree, so adding one tag renumbers every tag after it. A wardrobe stored by index and read back on the next patch is a character whose helm override has silently become their boots.

⚠ The appearances are DefIds and those are safe, because a DefId is a hash of an address rather than a position in a table — the same property that lets two builds agree without being told.

⚠ Nothing is checked on the way in, and here that is the correct behaviour rather than merely a safe one. Wardrobe.Resolve and Wardrobe.Worn re-check the unlock every time they are asked, so an appearance a patch has taken back stops showing on its own — and if it is granted again the player's choice is still there. Checking at load instead would throw that choice away for good.

Fields and properties (3)

• public const int Version

  The format this reads and writes.

• public ProfileSectionId Id

  What names it.

• public int UnknownSlots

  How many stored slots this build has no tag for.

Methods (4)

• public WardrobeSection(Wardrobe wardrobe, GameplayTagTable tags, CheckpointPolicy? checkpoint = null)

  Makes one over a character's wardrobe.

• public void Touch()

  Says something moved, so the next checkpoint writes.

• public ReadOnlyMemory<byte> Save()

  Writes what it holds.

• public void Load(ReadOnlyMemory<byte> bytes)

  Reads what it held.

Used by (1)

• WardrobeSectionTestsVixen.Live.Gameplay.Tests