Conversation
Live report (5.3.3, M+): "Sometimes when someone dies, a random person just falls off my party frames as if they left the group. Then mid fight you have to /reload to get their frame back up." The party header runs in NAMELIST mode by default (self position FIRST), and the secure header hides any unit whose name is not in the list. BuildPartyNameList added UnitName's answer as-is: UNKNOWNOBJECT for a member whose player object is not loaded, a literal that matches nobody, and a secret string in restricted content, which the list's table.concat cannot take. The FrameSort integration's party path dropped both silently. Either way the member was missing from the header, and a name resolving fires no roster event, so nothing re-sorted until a reload. The arena header already had the fix for exactly this (BuildArenaNameList's incomplete flag, INDEX fallback, retry, UNIT_NAME_UPDATE nudge). Party now uses the same shape: both name-list builders report an incomplete build, the header shows everyone in INDEX order meanwhile, and a capped retry plus the name-update nudge re-sort once the names resolve. Combat defers through the existing regen replay; with FrameSort active the retry re-requests FrameSort's order. A "Hide from Main Frames" pinned member shows too during that window. One frame too many for a moment is the right side to err on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Live report (5.3.3, M+): "Sometimes when someone dies, a random person just falls off my party frames as if they left the group. Then mid fight you have to /reload to get their frame back up."
The party header runs in NAMELIST mode by default (self position FIRST), and the secure header hides any unit whose name isn't in the list.
BuildPartyNameListaddedUnitName's answer as-is. For a member whose player object isn't loaded that isUNKNOWNOBJECT, a literal that matches nobody. In restricted content it is a secret string, which the list'stable.concatcan't take. The FrameSort integration's party path dropped both silently. Either way the member was missing from the header, and a name resolving fires no roster event, so nothing re-sorted until a reload.Change
The arena header already handles exactly this (
BuildArenaNameList's incomplete flag, INDEX fallback, retry,UNIT_NAME_UPDATEnudge). Party now uses the same shape:Combat defers through the existing regen replay. With FrameSort active, the retry re-requests FrameSort's order.
During that window, a "Hide from Main Frames" pinned member shows too. One frame too many for a moment is the right side to err on.
Live impact
In 5.3.3, so this is a candidate for stable.
How to test
Hard to force on demand. Zoning into a key with a party member still loading is the most reliable trigger. With the debug console on,
HEADERS/FRAMESORTlog "nameList incomplete" when the fallback engages, and every member should stay visible.