Loothing

The Loot Picker finally sees the loot. A real 20-man raid last night showed that items ML won through group-loot rolls never appeared in the picker — only instant-drop reagents like Spark of Radiance made it through. Tracing the Blizzard interface code revealed three overlapping bugs that combined to consistently drop group-loot wins; this release fixes all three, and while we were in there, it also cuts the non-ML "I have a tradeable item" comm chatter to near-zero for auto-roll raids.

Fixed

• Items won by the ML via group-loot rolls now appear in the picker. Loothing was relying on a 30-second post–boss-kill bag scan to find items and on ENCOUNTER_LOOT_RECEIVED to notify of new drops. Neither worked for group-loot rolls in WoW 12.0: ENCOUNTER_LOOT_RECEIVED only fires for personal-loot items (Blizzard's BossBannerToast.lua:183 is its sole consumer in the live client), and the 30-second scan window exactly matched WoW's 30-second group-loot roll timer, so items delivered to the winner's bag at T+30-33s arrived after the final scan tick at T+29s. The ML now also hooks LOOT_ITEM_ROLL_WON — the event that fires on the winner's client the instant the roll resolves — and routes the item straight into the session buffer. The 30-second bag-scan backstop is extended to 60 seconds to cover any delayed delivery.
• Identical items with different bonusIDs no longer drop out of the picker. The bag scan was diffing inventory by raw itemLink string. Post-roll gear carries bonusID / upgrade-track / crafting-socket metadata that doesn't string-match the link the snapshot captured at encounter start, so the scanner saw them as never-present and then couldn't probe trade time for them via the same broken link comparison. Item identity is now keyed on itemID throughout — snapshot, diff, dedup, and the trade-time lookup all use the canonical base ID. This is the same bug that caused the session to occasionally double-add the same item when the ML won the roll and the bag-scan then rediscovered it a tick later.
• Session state-transitions no longer leak "already reported" flags into the next boss. reportedTradeableItems is now wiped on ENCOUNTER_START in addition to the existing wipe at bag-scan start. Previously, a wipe-then-kill sequence could leave stale dedup entries that silently suppressed re-drops of the same item on the next boss.

Changed

• Non-ML raiders no longer broadcast "TRADABLE" notifications when the ML is auto-rolling the raid. This was a significant chunk of the comm noise during raids: every non-ML client was telling the ML about items in their own bags, but in an auto-roll raid (Loothing ML auto-NEEDs, Loothing non-ML auto-PASS) non-ML clients win nothing — every TRADABLE they sent was pure channel noise. The scan now checks the ML's broadcast MLDB: when the ML signals handleLoot=true and groupLootMode="active", non-ML clients suppress TRADABLE entirely and let the ML detect their own wins directly via LOOT_ITEM_ROLL_WON. Suppression is conservative — if the MLDB hasn't arrived or says otherwise, non-ML clients keep sending TRADABLE as before, so nothing is lost during ML handoffs or passive-mode raids.

Under the hood

• Profile migration rolls forward to schema v5 with an idempotent cleanup pass. If your profile still carried stale settings.sessionTriggerAction, settings.sessionTriggerMode, ml.onlyUseInRaids, voting.hideVotes or similar legacy keys from earlier migrations that never fully ran, they're now reconciled against the canonical keys and then nilled. Scope and voting-privacy values are re-derived from the legacy flags before those flags are dropped, so downgrade paths preserve whatever the user originally configured.
• Stale Test Mode council members are purged from profiles on load. Users who experimented with /lt test council previously ended up with phantom raiders like Stormstorm, Thunderguard, Firehunter sitting in their live council roster after disabling Test Mode. The migration now removes every council row carrying the isTestMode=true flag.