The party feed fired `PARTY_MEMBERS_CHANGED` only when the list of member guids changed. So an `SMSG_GROUP_LIST` that moved only a member's status, flags or subgroup, the leader or the loot method fired nothing. In particular, when a member out of view logged off, the stock party frame never repainted: their bars stayed coloured and their pet frame stayed up.
**The reference.** `SMSG_GROUP_LIST`'s handler `0x5e6a40` fires `PARTY_MEMBERS_CHANGED` (`0x5e6c61 mov ecx,0xda`, `0x5e6c66 call 0x703e50`) after its member loop on every path, party and raid alike. An empty list jumps straight there (`0x5e6b3c`). Nothing compares against the previous roster, and there is no `ret` before it.
**Changes:**
- `GroupState` counts every applied list, including the all-zero leave list and an identical re-send.
- The feed fires `PARTY_MEMBERS_CHANGED` once per list since its last look, in the same place after the unit and pet snapshots.
- A fresh VM gets one catch-up event if any list landed this session.
- The `/partytest` sandbox counts the lists its intents would be answered with.
- `PARTY_LEADER_CHANGED` and `PARTY_LOOT_METHOD_CHANGED` keep their compares, as `0x4e8250` and `0x4e86f0` do.
**Tests** (in `feed.rs`, each firing the event):
- a status-only list;
- a leader-only list and a loot-only list;
- an identical list;
- three lists in one drain, firing three;
- an empty list;
- a fresh VM's catch-up;
- the sandbox's intents.
`the_stock_party_frame_greys_a_member_who_logs_off_out_of_view` loads the default UI. After a status-only offline list, `PartyMemberFrame1ManaBar` reads `(0.5, 0.5, 0.5)` and the pet frame hides.
Fixes#667🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
