Conversation
…d none pending Krathe, 2026-09-21 raid: a burst of Aura Designer indicators going stale -- zero duration, stuck on frames -- that recovered on their own. The passive recorder had the shape: seventeen frames whose slot owner sat on the PREVIOUS occupant's raid token with no retarget pending, nine of them in one wave when the roster shifted by one mid-pull (19:28:43-56), two for three minutes across an out-of-combat window, three for four minutes. A frame on raid16 rendering raid17's auras is exactly an indicator whose duration reads zero and does not clear. What the log could not say is whether SetSlotOwnerUnit was ever reached for those frames. The aura rows log their retargets; the placed indicators never did. Now they do, one line per owner retarget, marked when combat defers it. The recorder's WRONG-AD-SLOTS row carries the walk's preconditions with it: how many placed entries the frame's store holds, how many of their handles belong to this owner, how many are parked, whether AD and the factory are on for the frame, whether it is visible, whether the unit exists, and when SyncFrame last ran on it (stamped at its entry). The next raid names the gate the walk fell at instead of only that it fell. Diagnostic only; no behaviour change.
…t and end Krathe, 2026-09-24, after an Aura Designer aura went stale briefly and the recorder had nothing: "the log should find the problem -- it's pointless if it keeps missing it." It missed for three reasons, all fixed here: 1. It sampled only in combat. It now samples all the time -- every second in combat, every two seconds out of it. 2. Saved rows were merged by key with no date, and the detail was written once and never refreshed. A repeat in a later session looked like the old row with a bigger count, and new diagnostic fields never appeared on a key that already existed. Rows now carry their session, and the detail is always the latest. 3. Every check trusted DF's own bookkeeping. Two new checks ask the engine: ENGINE-UNIT (the container's own GetUnit differs from the frame's unit, so it is parsing someone else's auras) and SHOWN-DISABLED (the window is shown but the container is disabled, so it is not listening for UNIT_AURA). They cover every lane: aura rows, dispel, the dispel icon row, every Aura Designer container store, and the AD slot owner. Every finding now goes into the debug log as well, under a new UNITSCAN category: one START line when a problem appears and one CLEAR line with its duration when it goes away. That is the timeline, next to the roster, latch and retarget lines, so a reload is the whole report. Hidden frames are skipped (a frame nobody can see cannot show a stale aura; the old version filled the log with frames whose unit had left). Test mode is skipped. Whether a container is still registered for UNIT_AURA cannot be checked: IsEventRegistered is refused on containers by the EventRegistrations forbidden aspect, as proven in game; SHOWN-DISABLED is the readable half. A mock harness caught one bug before this shipped: `okE and en or nil` turns a disabled container's false into nil, so SHOWN-DISABLED could never fire. Explicit ifs now. The panic snapshot (MarkAuraFault) records the engine binding and enabled state per lane too.
…icted The range-crossing aura snapshot moves to the RANGE channel (noisy, off by default). It fired on every crossing of every unit and filled ~78% of a raid evening's log, and the log evicts oldest INFO first. The recorder's start, clear and snapshot lines are now WARN so they outlive the INFO chatter, and each session leaves a heartbeat row in DandersFramesDebugDB.unitscanRuns (armed, samples, last sample, findings), so an empty findings list can be told apart from a recorder that never ran. Also records why a shown-but-stale aura icon cannot be detected: the engine secret-wraps button visibility and icon, out of combat too.
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.
Summary
Diagnostics only, no behaviour change for users. Three commits make the stale-container recorder (
Debug/AuraUnitScan.lua) catch what it was missing, and keep its findings in the log:AD slots: log every owner retarget. The aura rows logged their retargets and the placed indicators never did. The
WRONG-AD-SLOTSrow now also carries the preconditions the Factory's retarget walk needs, so a field log names the gate it fell at.Ask the engine, sample always, log start and end. The recorder now samples out of combat as well (1s in combat, 2s idle), keys saved rows by session with the latest detail, and adds two checks that ask the engine instead of DF's bookkeeping:
ENGINE-UNIT: the container's ownGetUnitdiffers from the frame's unit;SHOWN-DISABLED: the window is shown but the container is disabled, so it isn't listening forUNIT_AURA.Findings go to a new
UNITSCANdebug category as a START line and a CLEAR line with duration. This is what caught the roster-renumbering bug fixed in its own PR.Keep findings from being evicted. The range-crossing aura snapshot moves to the
RANGEchannel (noisy, off by default). It was ~78% of a raid evening's log, and the log evicts oldest INFO first. Recorder lines are now WARN, and each session leaves a heartbeat row inDandersFramesDebugDB.unitscanRuns, so "nothing caught" can be told apart from "never ran". The file header also records why a shown-but-stale icon can't be detected: the engine secret-wraps button visibility and icon, out of combat too.How to test
Enable the debug console, play a session,
/reload./run DandersFrames:DumpAuraUnitLog()prints the session heartbeat and any findings, andUNITSCANSTART/CLEAR lines sit in the log timeline.