Conversation
…rmed memo Two 5.3.2 reports (2026-09-13): a player who dies and takes a battle res has every Aura Designer indicator vanish until the fight is over. The death latch parks each of the unit's slots with the maxDuration=0 candidate-filter lock and the rez restores the live candidates. Both pushes are value-tracked, because SetAuraSlotCandidateFilters has no engine-side equality guard and reparses on every call. The guard compared against _cfPushed, which is recorded only out of lockdown so that the audits never believe a push a secure setter may have refused quietly. A death is in combat. So the park push landed -- the setter does work in combat; the helper gate measured deferred=0 across a raid -- and went unrecorded, and the rez's dark-to-live pass compared the live stash against the pre-combat live stash, found them identical by table identity, and skipped. The engine kept the park on every indicator until the regen replay cleared the memo. The comment on the guard said dark always records the park constant so the transition can never compare equal; that was true out of combat and false exactly when the latch fires. _cfWant now records every attempt, in or out of lockdown, and is what the guard tests. _cfPushed keeps its meaning for the slot audit and the AD dump. The regen replay clears both, so a quietly refused combat push is still re-pushed fresh. The birth seed, ApplyTuning's live push and the helper gate's direct push record the ask too, so none of them is followed by a redundant reparse from _pushFilter. Same guard is in v5.3.2 stable and in main. (cherry picked from commit e4b6bc0b105711cc6c7d5414f2b2512b0a20eb20)
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.
Field report (5.3.2)
Two reports on 2026-09-13: a player who dies and takes a battle res has every Aura Designer indicator on them vanish until the fight is over. Reproduced from the code, not yet verified in game — a mid-fight BR is the test.
Mechanism
The death latch parks each of the unit's slots with the
maxDuration = 0candidate-filter lock and the rez restores the live candidates. Both pushes are value-tracked inSlotHandle:_pushFilter, becauseSetAuraSlotCandidateFiltershas no engine-side equality guard and reparses on every call.The guard compared against
_cfPushed, which is recorded only out of lockdown so that the slot audit never believes a push a secure setter may have refused quietly. A death is in combat. So the park push landed (the setter does work in combat) and went unrecorded, and the rez's dark→live pass compared the live stash against the pre-combat live stash, found them identical by table identity, and skipped. The engine kept the park on every indicator until the regen replay cleared the memo — exactly "till the fight is over".The comment on the guard said "dark always records the park constant, so the transition can never compare equal and skip." True out of combat; false exactly when the latch fires.
Buff/debuff rows are unaffected: they hide and show via the DF window frame and the container's
OnShow_Intrinsicre-arms and re-parses. Slots hide the same way, but their content is the candidate filter, and that push was the one skipped — which is why HoT indicators were the whole of what vanished.Fix
_cfWantrecords every attempt, in or out of lockdown, and is what the guard tests._cfPushedkeeps its meaning (OOC-confirmed) for the slot audit and the AD dump._replayTuningclears both, so a quietly refused combat push is still re-pushed fresh at regen.ApplyTuning's live push and the helper-gate push record the ask too, so none is followed by a redundant reparse from_pushFilter.A standalone model of the guard reproduces it: old → stuck parked until regen, new → live on the rez.
Verified: compiles, no global-name change, CR/LF and no BOM.