Fix Player Aura Bars filtered bars rendering every buff when the engine identity gate is degraded - #1375
Closed
dfrisone wants to merge 3 commits into
Closed
Fix Player Aura Bars filtered bars rendering every buff when the engine identity gate is degraded#1375dfrisone wants to merge 3 commits into
dfrisone wants to merge 3 commits into
Conversation
A hide/re-show of an engine aura container re-parses its groups, and a re-parse landing while the teardown's filter state is still degraded renders the FULL buff set on a filtered bar, which then sticks until a reload. Only the cinematic edge was handled; the same recovery now runs on every container visibility edge (hooked OnShow), on loading screens, and on vehicle enter/exit.
- the default Buffs container rebuilt on a spell-list change had no visibility watch, so it ran the rest of the session without recovery - a resync now skips bars whose container request is still queued, which would otherwise queue a second request against the same parent - the resync events arm from PAB_SetEnabled too, so a live enable does not wait for a reload
Checked against the 12.1 source: Blizzard_AuraContainerUtil's
DoesAuraPassCandidateFilters skips includeSpellIDs/excludeSpellIDs whenever
CanApplyIdentityCandidateFilters says no, which for a helpful group means
any moment UnitCanAssist("player", "player") reads false. That, not a
hide/re-show, is what parses the whole helpful set into a filtered bar.
Comments rewritten to cite the gate, and PLAYER_CONTROL_LOST/GAINED added:
control handover is what flips the gate, and it brackets vehicles, taxis
and mind control.
Owner
|
fix is in |
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
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.
Reported: External Defensives (Externals filter) shows unrelated buffs at login until a /reload, after entering a vehicle, and after an unlock-mode round trip.
Cause: Blizzard_AuraContainerUtil.DoesAuraPassCandidateFilters only applies includeSpellIDs/excludeSpellIDs when CanApplyIdentityCandidateFilters passes, and for a helpful group that gate is
isHelpful and not UnitCanAssist("player", unit). Any moment the player is not assistable to itself (unit flags not streamed at login, control handed to a vehicle) parses the whole helpful set into a bar that asked for four spells, and group membership is cached per aura instance, so it sticks until a reload.Fix: re-run the group config for every live container after those edges. SetAuraGroupCandidateFilters calls UpdateAllAuras, which marks FullAuraRebuild and re-evaluates membership with the gate settled. Edges: hooked container OnShow, container creation (login), PLAYER_ENTERING_WORLD, PLAYER_CONTROL_LOST/GAINED and vehicle enter/exit. Coalesced one-tick pass, no polling; the cinematic handler this replaces did the same thing for one edge.
Test: logged in on a druid, mounted and took a vehicle, entered and exited unlock mode: the Externals bar keeps only its filtered buffs.