ProfilePityStore

Remarks

Doc 28 is firm that this has to be durable — "a pity counter that resets on a realm crash is a support ticket" — and it is a counter rather than an asset, so it belongs in the profile and not in the ledger. A pity count written twice is the same count; a sword written twice is two swords.

⚠ Synchronous, and it can be, which the ledger could not. A loot roll asks for a count mid-frame and the answer is in memory; what makes it durable is the checkpoint underneath, not a round trip here. That is exactly why counters and assets are stored differently.

⚠ A hit clears the count rather than decrementing it. Pity exists to bound a run of bad luck, and a run that has ended is zero — decrementing would carry a hundred failures into the next hundred attempts and make the guarantee unbounded.

⚠ One of these is one character's, and Player is ignored. A profile already names the character, so the player half is redundant — and storing it would put a realm-scoped gameplay id in the database, which is the one thing IGameplayIdentity exists to prevent. The failure that would cause is quiet and exactly the support ticket doc 28 named: after a transfer the id is different, every lookup misses, and a character's pity counters read zero with the rows still sitting in the profile.

Fields and properties (2)

• public ProfileSectionId Id

  What names it.

• public int Count

  How many tables this character has a run going on.

Methods (5)

• public ProfilePityStore(CheckpointPolicy? checkpoint = null)

  Makes one.

• public int AttemptsOf(PityKey key)

  How many attempts have failed in a row.

• public void Record(PityKey key, bool hit)

  Records an attempt.

• public ReadOnlyMemory<byte> Save()

  Writes what it holds.

• public void Load(ReadOnlyMemory<byte> bytes)

  Reads what it held.

Used by (1)

• PlayerProfileTestsVixen.Live.Gameplay.Tests