AD group indicators fade out of range, and aura rows confirm their retarget re-parse - #255
Open
Krathe82 wants to merge 4 commits into
Open
AD group indicators fade out of range, and aura rows confirm their retarget re-parse#255Krathe82 wants to merge 4 commits into
Krathe82 wants to merge 4 commits into
Conversation
Field report: a shaman's own Earth Shield stayed on a frame and could not be cleared without a reload. The log's last three entries are buff, debuff and defensive all retargeting party3 -> party2, out of combat, and then nothing at all -- so the stale icon survived a retarget that should have cleared it. NativeBackend:setUnit already does a partition bounce out of combat, which is supposed to make the container drop the previous occupant's parse. The evidence says it does not always land, and a long-lived buff nobody re-casts generates no UNIT_AURA on the new unit, so a missed re-parse has nothing to correct it. The icon then sits there indefinitely, which is exactly the report. Handle:Refresh is the addon-callable re-parse and returns whether a genuine one happened, so this is a fix and an instrument at once: it forces the parse, and a "did NOT happen" line identifies a failed bounce rather than leaving an unexplained icon. Source-confirmed combat-safe, and unreachable in combat anyway since the retarget itself defers to regen. Only fires on an actual unit change, so it costs nothing per pass.
An indicator stayed at full brightness on a faded frame and nothing ever corrected it. In element-fade mode the slot-owner anchor is the ONLY thing that fades Aura Designer indicators, and the pass that writes it runs on a range EDGE -- but the owner is stood up lazily, on first slot acquisition. An anchor created while the unit is already out of range has missed the only trigger it gets, and UpdateAuraDesignerAppearance skips its whole slot-host block when GetSlotOwnerAlphaHost returns nil: no write, nothing queued, nothing to retry. ⚠ Not a regression, though it looks like one. This area has been fixed three times -- 22086f4 gave the fade a legal target, 2a8507e stopped the squared fade and retried denied hosts on combat drop, 7116380 hardened the pass against throws and added the restriction-lift retry. All three address a write being ATTEMPTED AND REFUSED. This is the path where it is never attempted, which is why none of them covered it. Diagnosed from the field rather than reasoned: /df debug adalpha showed the pass had run and seen inRange=false, nothing refused, anchor still 1.00 -- and a forced ApplyOORAlpha took it to 0.20 immediately. Writability was never the problem. Applying the appearance at owner creation is idempotent and a no-op in whole-frame mode, where the cascade already covers the anchor.
Element-mode fade: a layout/filter group's indicators sat at full brightness on a faded frame while a placed indicator next to them faded correctly. Krathe's differential located it -- "my AD single PI is working, it's a group that doesn't fade" -- after four wrong theories from me about the slot-owner anchor path, which was never broken. The Factory keeps one container handle per enabled group in store.fgroups and store.dgroups; its own retarget walk names all eight stores. The alpha walk's AD_STORE_KEYS named six -- groups were absent -- so group containers had NO alpha writer in element mode: the frame is pinned at base there, the cascade that covers them in whole-frame mode never runs, and nothing else touches them. Whole-frame mode working is what proved the containers themselves fade fine. Adding the two keys is the entire fix. Group handles are row handles, so entry.handle.button is nil and the walk's existing callback routes them onto the fade branch -- and base-only in whole-frame mode, where the cascade already fades them, so no squared fade. No competing writer exists on a group wrapper (verified: the Factory's two wrapper-alpha writers are placed indicators, which stamp _dfADBaseAlpha for exactly this composition, and missing badges). If the Factory ever grows a ninth store it goes in BOTH lists -- the comment at the key list says so, naming the retarget walk's location.
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.
Against stable. Independent of #254 apart from a trivial
CHANGELOG.mdoverlap — both add an[Unreleased]section; whichever merges second resolves by keeping both bullets.AD group indicators fade out of range ✅ confirmed in game
With element-specific out-of-range fading, a layout/filter group's indicators sat at full brightness on a faded frame while a placed indicator beside them faded correctly.
The Factory keeps one container handle per enabled group in
store.fgroups/store.dgroups; its own retarget walk names all eight of its stores. The alpha-fade walk's store list named six — groups were absent — so group containers had no alpha writer at all in element mode: the frame is pinned at base there, and the whole-frame cascade that masks the hole in the other mode never runs. That masking is also why whole-frame fading worked throughout, which made this look like a regression of the 22086f4 slot-anchor fix. It was not — that fix is intact, which is why placed indicators kept fading.The fix is adding the two keys. Group handles are row handles, so the walk's existing callback routes them onto the fade branch — and base-only in whole-frame mode, where the cascade already fades them, so no squared fade. Verified no competing writer exists on a group wrapper. The comment at the key list now states the rule: a ninth Factory store goes in both lists, or its containers silently skip either fades or unit reassignment.
Credit where due: the differential that located this — "my single placed indicator fades, the group doesn't" — was Krathe's, after the anchor-path theories had all come up empty.
Slot anchor seeded at birth — defensive, honestly labelled
The slot-owner anchor (the legal fade target for slot-backed indicators) is stood up lazily on first slot acquisition, and the pass that fades it runs on a range edge — so an anchor born while its unit is already out of range would start at full alpha with no further trigger. One idempotent appearance call at owner creation closes that ordering hole. ⚠ The comment states its honest status: this shipped mid-hunt as a diagnosis of the group bug above and was not that bug; the hole it covers is real but was never proven to bite, and deleting the call is safe if ever suspected.
Aura rows: force and confirm the re-parse on a retarget — built, not yet field-confirmed
Field report: a shaman's own Earth Shield stayed on a frame (frozen, no duration) after the frame changed hands, uncleaable without a reload. The log's last entries were the three rows retargeting
party3 -> party2, out of combat, then nothing — the backend's out-of-combat partition bounce onSetUnitis supposed to drop the previous occupant's parse, and the evidence says it did not land. A long-lived buff nobody re-casts fires noUNIT_AURAon the new unit, so nothing ever corrects it.Handle:Refreshis the addon-callable re-parse and returns whether a genuine one happened, so the retarget path now forces it and logs a warning when it reports false — a fix and an instrument in one. Source-confirmed combat-safe; unreachable in combat anyway since the retarget itself defers to regen. Fires only on an actual unit change. Built after the reporter's stuck icon was gone, hence unconfirmed; no changelog entry until it is.Verification
luac -pclean on every changed file, CRLF intact.Frames/AuraContainer.luaandFeatures/ElementAppearance.luaare byte-identical to the tested tree on their non-debug content (the tested tree additionally carries locally-held diagnostic tooling, deliberately excluded here). Changelog entry included for the confirmed fix only.