Feature request: configurable "buff sets" with a missing-buff indicator, as a new breakout window

[Frankthetankk]

Summary

Add a way to define a set of buffs I expect to have running at all times, and have EQBuddy show me when one of them is missing — whether because it expired naturally, or because it got overwritten by a debuff. With enough buffs running at once (self-buffs, group buffs, class buffs, item procs, etc. all stacked on the same character), it's genuinely hard to notice at a glance that one specific buff has dropped off, especially mid-fight when attention is elsewhere.

The problem this is trying to solve

I've noticed that some buffs I'd consider "permanent" (self-buffs with no real duration, cast once and expected to stay up indefinitely until death or a deliberate removal) get overwritten by certain debuffs — and some of my regular-duration buffs get overwritten by debuffs too, not just naturally expiring on their own timer. I'm not sure if this is intended EQ Legends game design (e.g. certain debuff categories deliberately displacing a buff slot as part of their effect) or an unintended bug on the game's side — I'm not trying to report that part here, just noting it as the actual reason this problem exists and is hard to track manually. A buff bar with a dozen-plus entries doesn't make it obvious which single one just vanished, especially when it happened silently in the middle of combat and nothing visually flagged the loss.

The practical impact: I might be fighting for several minutes without realizing my AC buff got stripped, or without a haste buff I thought was still active, and only notice after the fight is already going badly (or is over) — at which point the information is much less useful than it would have been in the moment.

Suggested behavior

• Let the player define a set of buffs they want EQBuddy to actively watch for — "these are the buffs I expect to have running." Fully configurable — the player decides exactly which buffs (including which "permanent" self-buffs) belong in a given set. Nothing should be auto-assumed or auto-populated without the player's input; the player builds the list themselves from whatever buffs matter to them.
• A "missing buffs" indicator that only appears when something from the current set isn't currently active. When every set buff is up and accounted for, the indicator disappears entirely — it's not meant to be a persistent always-on display, just a targeted "something's wrong" flag that only shows up when it's actually needed.
• Separately, an option to warn when a set buff is about to expire (not yet missing, but getting close) — configurable by the player for how many minutes/seconds before expiry it should start showing, similar in spirit to how a "low on X" warning might work elsewhere in a game UI. This gives the player a chance to recast proactively rather than reacting after the buff has already dropped.
• Removing a buff from a set (e.g. the player no longer cares about being reminded for it — maybe they respecced, or just don't use that spell line anymore) shouldn't affect the rest of the set or require rebuilding it.

Sets scoped to class COMBINATIONS, not just individual classes

Since EQ Legends characters can play 2–3 classes at once, a "set" should really be tied to the specific combination of classes currently active, not just a single class considered in isolation — a Cleric/Paladin/Warrior loadout has a meaningfully different buff kit than a solo Cleric, and the set should reflect the whole combination the player is actually running.

If I swap one class out of my loadout for a different one (say, dropping Warrior for Rogue), that's effectively a different combination and probably warrants being tracked as its own set — but ideally EQBuddy could remember each individual class's buff configuration underneath the combination, so swapping one class slot doesn't mean rebuilding the entire set from scratch. The unaffected classes' buffs in the set should stay exactly as they were configured; only the swapped class's portion would need reconfiguring. Practically, this might mean storing buff preferences per-class internally, then assembling the active set by combining whichever classes are currently active — rather than storing one flat list per unique combination the player has ever used.

Sets should persist and be remembered until the player explicitly changes them — no need to reconfigure on every login or session start.

Auto-selecting the active set based on detected class combination

If EQBuddy can detect which class combination I'm currently playing, it could automatically load the matching saved set instead of me manually swapping sets every time I change characters or edit my loadout. Reading /who output was one idea for detection, since it should show my own character's classes when I target/who myself — though there may be a more reliable signal already available elsewhere in the log that I'm not aware of (e.g. something that fires specifically on a class loadout change, if that's a distinct in-game event).

New idea: detect newly unlocked buff spells while leveling, and offer to add them to a set

While leveling up, if EQBuddy detects a new buff spell being unlocked (presumably visible in the log the same way other spell-learning events are), it could proactively ask the player whether they want to add it to their current class/set, rather than the player having to remember to go update their set manually every time they level.

This would need some logic to figure out whether the new spell:

• Replaces/upgrades a spell already in the same spell line the player has previously used as a buff (e.g. a rank 2 version of a buff already in the set) — in which case it probably should just swap in as the new version of that same slot in the set, keeping the set's structure intact rather than adding a duplicate entry, or
• Is a genuinely new/different buff line that would stack alongside existing ones rather than replace anything — in which case it's a new addition to the set, not a replacement of an existing slot.

Getting this distinction right matters, since treating every new spell as a fresh addition would clutter the set with redundant rank-up duplicates over time, and treating every new spell as an automatic replacement could incorrectly discard something that should have stacked.

Further idea: proactively suggest buffs the player may have forgotten to add

Beyond just detecting new unlocks, EQBuddy could also suggest known/common buffs that aren't currently in the player's set at all — especially commonly-important categories like AC, hit points, HP/mana regen, and haste — in case the player simply forgot to add them, or didn't realize they already had access to a relevant spell. This would be framed as a suggestion/prompt the player can accept or dismiss, not something silently auto-added to their set without confirmation — keeping with the "fully configurable, player decides" principle above.

Format: a new breakout window, in line with the other breakout windows

After thinking about it, I'm leaning toward requesting this as its own breakout window (matching the pattern of the existing combat/damage breakout, healing breakout, etc.) rather than folding the entire configuration UI into the Buffs card itself. The missing-buff indicator and expiry warnings could still show as a compact summary inline on the Buffs card (similar to how other cards surface a headline number with more detail available on click/expand), while the breakout window would offer the fuller expanded view — set configuration, per-class buff lists, the level-up suggestion prompts, etc. — without needing to cram all of that into the main card's limited space.

Should this reuse the existing alert banner system instead?

Separately from the breakout-window idea above — EQBuddy already has a draggable "Alert banner..." anchor for positioning alerts, letting the player choose where on screen alerts appear. Would it make more sense for the missing-buffs indicator specifically to piggyback on that same anchor/banner system instead of (or in addition to) living in a breakout window? I'm asking both because I'm not sure which approach fits better with how the rest of the app's alerting is structured internally — this question is about the general alert banner system, not about the slow-alert chips specifically (those already have their own separate anchor discussion happening).

Default alerting behavior — no "ping," just a persistent visual indicator

By default, I don't think this needs to actively ping/alert the player (sound effect, popup notification, spoken alert, etc.) when a buff goes missing — the visual indicator itself, appearing and staying visible until the buff is reapplied, should be enough on its own to catch the player's attention without being disruptive. An optional toggle for an actual sound/spoken alert could be considered if there's interest from other players, but I suspect most players (myself included) wouldn't need or use it for something like this — it's meant to be informational rather than urgent, unlike something like the slow alert where an active debuff might warrant a stronger nudge.

Interaction with the existing "expiring only" buff display mode

The Buffs card already has a toggle to only show timers once a buff is close to expiring, with a configurable threshold, rather than always showing every active buff's countdown. My "about to expire" warning idea above sounds conceptually similar — worth clarifying whether this should just reuse that existing threshold/setting, scoped specifically to buffs in the player's set, or whether it should be a separate, independently configurable warning tied specifically to this missing-buffs feature (which might make sense if a player wants a different threshold for their "important" set buffs versus their general buff bar). Open to whichever makes more sense on the implementation side — just flagging that the two features seem related and might want to share logic rather than duplicate it.

Optional: a history/log of lost buffs (secondary idea, not core to this request)

Separately, it might be useful to have a history or log button showing what happened to a buff that dropped from the set — expired naturally vs. overwritten by a specific debuff, and if overwritten, ideally which debuff caused it. I don't think I personally need to know the exact cause in the moment during a fight (that's what the missing-buff indicator itself is for), but having a history to look back on afterward could be useful for two separate reasons:

1. Reporting to EQ Legends devs whether a specific debuff overwriting a specific buff is intended behavior or a bug — having concrete before/after data ("Buff X was active, NPC Y cast debuff Z, Buff X was gone") would make for a much stronger bug report than "I think this NPC removes my buffs."
2. Knowing ahead of time, next time fighting a given NPC, that it tends to strip a certain buff — so the player can plan around it (recast preemptively right before/during the fight, avoid engaging while already low on a critical buff, bring a cure/dispel-capable groupmate, etc.).

This feels like a nice-to-have rather than a core requirement of the missing-buffs indicator itself, and could reasonably be scoped as a separate/later addition if the core feature is more work than expected.

Scope: excluding short-duration song/HoT effects

I don't play a bard, so I'm not fully sure how bard songs would interact with this feature, but as I understand it, duration heals (HoTs) are technically buffs but get filed under EQL's "song effects" category rather than the main buff list. I don't think those need to be part of this feature's scope — they're short-duration, used tactically right around combat (before/during/after a fight), and not really the "did I forget to reapply this and not notice for ten minutes" problem this request is trying to solve. Happy to be corrected if that assumption about how songs are categorized is wrong, or if a bard player thinks songs should actually be included.

---

EQBuddy 1.70.0 · Windows 19045

[DranakCorps-bot]

This is one of the best-specified feature requests this project has received — you've done half the design work, including the hard parts (rank-up vs. new-line disambiguation, per-class storage under combos, the "player decides everything" principle). Committing to building it, in stages, because the honest version of this feature has a real dependency on what the log can actually tell us. Here's the plan and the constraints:

What the log gives us (and doesn't):

• EQBuddy learns a buff is up from its landing line when cast, and learns it dropped from its fade line — that's what the ⏳ Buffs card already runs on. So a missing-buff indicator is buildable on machinery we have.
• The catch for "permanent" self-buffs: a buff cast before EQBuddy was watching (before login's log started growing, or in a session EQBuddy replayed past) is visible at cast and at fade — but if the fade line is one the game never prints (some strips are silent), the buff can look "up" when it isn't, or we simply never saw it land. The indicator will be honest about this: "not seen this session" is a different state from "seen fading," and it will say which.
• Debuff-overwrite strips: when the game prints the buff's fade line on overwrite, we catch it like a natural fade. Whether Legends always prints it on overwrite is exactly the kind of thing your history-log idea (stage 3) would let us both verify — your instinct that this doubles as dev-report evidence is right.

Stage 1 — the core, coming first: a player-defined buff set (picked from buffs EQBuddy has seen you cast, plus a search over the full buff catalog), a "missing: X, Y" line on the Buffs card that only appears when something's missing, and expiry warnings reusing the existing warn-threshold setting scoped to set buffs. Per-character, persisted, no auto-population — your rules. No sound by default, matching your read of it as informational.

Stage 2 — sets per class combination: stored per-class underneath and assembled by combination, exactly as you proposed (swap Warrior for Rogue, keep the other two classes' picks). Auto-detecting the active combo needs a class signal in the log — /who output does get logged and carries class lines, so "detect from your own /who" is plausible; whether there's a loadout-change line to hook is an open question. If you (or anyone reading) changes a class loadout soon: the log lines around that moment would answer it.

Stage 3 — the extras: new-buff-unlock suggestions (rank-up folding into the same slot vs. genuinely new line — the AA/spell-learning log lines plus the spell catalog's line families should support the distinction you outlined), and the lost-buff history with cause where the log names one.

On placement: stage 1 lands on the Buffs card (compact, appears-only-when-wrong — your "targeted flag" framing). The full breakout window arrives with stage 2 when there's configuration enough to justify it. The alert-banner system stays out of it for now per your own "informational, not urgent" call — if field use proves a missed buff needs a louder nudge, the banner hookup is easy to add behind a toggle.

Songs/HoTs stay out of scope, as you suggested — your read on how they're categorized matches ours.

No promise on a date — this is bigger than a same-day build and it'll queue behind the current bug batch — but it's on the roadmap with your name on the spec. Stage 1's shape is settled enough that feedback on the above (especially the "not seen this session" honesty state) is welcome now.

[DranakCorps-bot]

Stage 1 is BUILT and live in v1.78.0 - your spec, faithfully: define your set in Options → Alerts & chips (search covers every buff EQBuddy knows, the ones it's seen you cast float first), and the ⏳ Buffs card grows a line that exists only when something's wrong - "⚠ missing: X · expiring: Y · not seen: Z". The honesty state you and we discussed made it in exactly as designed: "not seen" is its own state with its own explanation, because a buff cast before the log was watched is genuinely unknowable, and the app says so instead of guessing. Expiry warnings reuse your existing warn threshold, scoped to set buffs. No sound, no popup - informational, per your own framing.

Stages 2 and 3 remain committed: per-class-combination sets with the breakout window, then the unlock suggestions and the lost-buff history. And a down payment on that history arrived in the same release: EQBuddy now parses "Your X spell did not take hold. (Blocked by Y.)" and keeps a per-character ledger of measured stacking conflicts - the exact evidence base your debuff-overwrite reporting idea needs.

Thanks for writing half the design, Frankthetankk. Walk it and report anything that reads wrong.

(Rollout note: portable + Linux/macOS builds are on the release now; the Windows installer channel completes within hours.)

[DranakCorps-bot]

And now the REST of the spec - stages 2 and 3 are live in v1.79.0, same day as stage 1:

Stage 2: sets are stored per class and assembled to your active class combination - swap Warrior for Rogue and the other classes' picks survive, exactly as your design called for. The new Buffs breakout window (⭐ on the Buffs card) shows every set buff's live state with in-place add/remove per class, so configuring never requires Options. One honest limit: class detection uses the classes EQBuddy already knows for your character (Quest Tracker picks, else combat inference) - there's no /who parsing yet, and the UI names its source rather than pretending.

Stage 3: level into a genuinely NEW buff line and a quiet suggestion row offers it for your set (✓ add / ✕ never ask again - rank-ups need nothing, the set already covers them, which was your rank-up-vs-new-line question answered structurally). And the breakout's "lost this session" fold answers WHY each set buff dropped: expired, faded, lost on death, or "lost as Plague landed (a swamp rat)" - correlated conservatively, only when a named hostile spell landed on you within seconds of the fade. That last form is exactly the before/after evidence your dev-report idea needed, and there's a ⧉ copy button on the fold to take it straight to a bug report.

From your spec to fully shipped in one day. Walk it and tell us where it reads wrong - you've earned naming rights on anything we missed.

[Frankthetankk]

Started testing this today — two things worth flagging.

Bug: class dropdown isn't showing the full roster

Opened the new Buff set breakout (⭐ on the Buffs card) to build my first set, and the class picker only offers "(any class)" and "Berserker" — not the full class list. It looks like it's only surfacing the class it inferred for me ("Blank · BER (inferred)") rather than letting me pick any class to build sets for other members of my combo. This is blocking me from actually testing per-class assembly (stage 2) since I can't add buffs under classes other than the one it guessed.

Feature idea: auto-detect buffs into the set instead of typing each one

Right now stage 1 is fully manual — search and type each buff in. Would it be possible to have EQBuddy watch for You begin casting X followed by the landed-on-self emote, and when that buff isn't already in the set for the inferred class, prompt to add it (or auto-add, with a "✕ never ask again" per buff like the stage 3 level-up suggestions already do)? Keep the manual search-add too — that's still useful for buffs I want tracked before I've ever cast them this session. This is basically the same suggestion machinery stage 3 already built for level-up unlocks, just triggered by "any landed buff not yet in the set" instead of "newly unlocked spell."

Open question: do AA buffs count?

Long-duration AA-granted buffs (e.g. Wizard's Improved Familiar I, ~6hr) — are these expected to work with buff sets already? I'm not sure they follow a normal "begin casting" line the way spell buffs do, since AA effects are often instant/passive rather than a cast. Flagging as a question rather than assuming either way.

---

EQBuddy 1.79.1

[DranakCorps-bot]

Thanks — and the class-picker one is a fair hit. Fixed.

Class dropdown (bug, fixed). You're right that it was only offering (any class) plus the class it inferred for you. That was deliberate once and wrong on reflection: the reasoning was "parked classes are the Options editor's business, this window shows the assembled set" — but it made a guess load-bearing. Class detection is best-effort (Quest Tracker picks, else combat inference), so a character read as Berserker alone could only ever build a Berserker set, which is exactly the per-class assembly stage 2 exists to provide. You were blocked from testing the feature by the feature's own guess about you.

The picker now lists (any class), then your detected classes, then every remaining class. Yours stay at the top where they're one click away; the rest are simply reachable instead of hidden behind a correct inference. Shipping in the next release, and thank you — this was the right thing to be annoyed about.

Auto-detect buffs into the set (idea). I like this a lot, and you're right that the machinery already exists — stage 3's level-up suggestion row is precisely the shape, just triggered by "newly unlocked spell" instead of "buff landed on you that isn't in your set". The one thing I'd want to get right before building it is the noise floor: in a group you receive a great many buffs you have no intention of tracking, so a naive "anything that lands" prompt would be unusable in a raid. Probably wants to key off buffs you cast on yourself first, which is also the case where the You begin casting X line you mention is actually available. Flagged to David with that caveat rather than promised.

AA buffs (question). Good question, and honestly answered: it depends on whether the effect produces a landing line in the log at all. Buff sets are driven entirely by what the log says — a landing message starts the timer, a fade message ends it. A long-duration AA like Improved Familiar that lands with a normal "you feel..." emote should behave like any other buff; one that's purely passive with no log line at all is invisible to EQBuddy and always will be, because there is nothing to read. If you add one to a set and it sits permanently at not seen, that's the tell — and that state is deliberately distinguishable from "missing" for exactly this reason. Paste the AA name and what the log shows when you use it, and I can say definitively for that one.

[DranakCorps-bot]

The class picker fix is shipped in v1.82.0 — every class is selectable now, with yours sorted first, so stage 2 is properly testable. Thanks for pushing on it. The auto-detect idea and the AA question are still open above; no need to re-raise them.

[Frankthetankk]

Testing today's build — five things worth flagging from working through the buff set search/config flow, a broader question about permanent-buff tracking, a spell-line feature suggestion, and an answer to the open AA-buff question from earlier in this thread.

Bug: buff clicked from search under a specific class doesn't add to the set, and then disappears from future searches

Steps to reproduce:

1. Open the Buff set breakout, select a specific class in the class picker (tested with Paladin).
2. Start typing a buff name — e.g. "Armor of Faith". Autocomplete correctly finds and displays it.
3. Click the buff in the search results.
4. Nothing happens — the buff is not added to the set. No entry appears in the set list.
5. Search for the same buff again — it no longer appears in the search/autocomplete results at all, even though step 4 never actually added it anywhere.

Compare against the working case, in the same window:

• With "(any class)" selected instead of a named class, searching for and clicking the same buff (Armor of Faith) works as expected — it's added to the set immediately, is visible in the set list, and can be removed via ✕ cleanly. After removal, searching for it again correctly shows it as available in autocomplete.

So the failure appears specific to having a named class selected (at least Paladin) rather than "(any class)" — clicking a searched buff silently fails to add it to the set, but the search index behaves as though the buff was consumed, hiding it from subsequent searches even though it was never actually added anywhere. This effectively makes it impossible to build a Paladin-specific set via search once a buff has been "clicked away" this way, since it can't be found again to retry.

Bug: "seen this session" label appears on buffs not actually cast this session

While searching for a buff to add to my Paladin set (searching "Armor of Faith"), the autocomplete also surfaces earlier-rank spells from the same spell line — Holy Armor and Spirit Armor — which is expected/useful, since I do still use some lower-rank spells in cases where no higher-level version exists yet.

The issue: both Holy Armor and Spirit Armor are tagged "seen this session" in the search results, but I have not cast either of them this session. I did use them a long time ago while leveling — they're older, lower-level spells in the same line I've since replaced with Armor of Faith now that I'm level 50 — but that was in a past session, not the current one.

So the "seen this session" tag appears to be based on whether the spell has ever been observed/cast by this character (all-time), rather than being properly scoped to the actual current session. This is a mislabel rather than a functional blocker — the buffs still search and presumably add correctly — but the label itself is misleading, since "seen this session" should mean what it says.

Question/possible bug: buff set duration for Armor of Faith doesn't match expected +15% from focus item

Testing the Buff set breakout's duration display against a known focus effect, and the numbers don't line up the way I'd expect — flagging as a question rather than a confirmed bug, since there's a plausible in-game explanation I can't fully rule out myself.

Details:

• Spell: Armor of Faith, level 48 Paladin
• Where observed: duration shown for this buff inside the Buff set breakout window
• Focus effect active: Extended Enhancement II — "increases the duration of beneficial spells by 15%," with a note that it decays on spells over level 44
• Controlled for: I do not have any ranks of Spell Casting Reinforcement (or any other AA that extends beneficial spell duration) — so the displayed duration should be attributable to the focus item alone, not a combination of item + AA.

Numbers:

	Duration	Seconds
Base duration	1h 3m	3780s
Displayed in buff set (with focus item)	1h 10m 30s	4230s
Expected at a flat +15%	1h 12m 27s	4347s

• Actual increase shown: 4230 − 3780 = 450 seconds, or ~11.9% over base
• Expected increase at the item's stated 15%: 3780 × 0.15 = 567 seconds (4347s total)
• Shortfall vs. expected: 117 seconds (~2.6 percentage points below the stated 15%)

Possible explanations:

1. The focus item's own "decays on spells over level 44" clause is legitimately reducing its effectiveness on a level-48 spell, and EQBuddy is calculating/displaying this correctly — in which case this isn't a bug, just an item mechanic I wasn't accounting for.
2. EQBuddy's duration calculation doesn't fully account for the item's stated decay curve and is under/over-applying the bonus.

What would help narrow this down:

• Whether EQBuddy's displayed duration is parsed directly from something the game/UI reports, or computed by EQBuddy from base duration + known modifiers. If it's the latter, knowing what decay formula (if any) is currently applied for "decays on spells over level 44" would clarify whether ~11.9% is expected math or a miscalculation.
• I don't currently have a way to test the same spell fully un-buffed (no focus item at all) to confirm the 1h 3m base is accurate on EQBuddy's side too, rather than assumed from the spell's tooltip — can try to get a clean unfocused cast logged if that'd help isolate whether the discrepancy is in the base value or the modifier math.

Not sure which of these it is without more visibility into EQBuddy's calculation. If it's parsed directly from something the game reports, this may just reflect real in-game behavior and isn't a bug at all — but wanted to raise it either way since the numbers didn't match my naive expectation.

Bug/feature gap: buff sets don't seem to account for "permanent" buffs getting overwritten by debuffs, even though this is exactly the scenario the original request (and stage 3's lost-buff correlation) was meant to catch

I use a number of "permanent" (no real duration, cast-once) self-buffs regularly, and in my experience several of them get silently overwritten by specific debuffs rather than naturally expiring. This may well be an EQL-side bug rather than intended design (a debuff category that displaces a buff slot as a side effect) — I'm not asking EQBuddy to fix EQL's behavior, just to track and surface it, which was the original point of this whole feature request.

Observed overwrite pairs, from my own play:

Debuff	Overwrites
Malaise	Elemental Shield
Blood of Pain	Chloroplast
Dooming Darkness	Spirit of Elh'Li
Asystole	Rage
Spine Chill	O`Keil's Levity

There may be more pairs I haven't caught yet.

Sample log evidence for the Malaise → Elemental Shield pair, pulled from my own log — landed emote is You feel protected from fire and ice., fade emote is Your elemental armor fades.:

Timestamp	Cast on me	Elemental Shield fade	Gap
Sat Aug 08 00:01:05	A glare lord begins casting Malaise	00:01:08	3s
Sat Aug 08 18:11:34	A glare lord begins casting Malaise	18:11:37	3s
Mon Aug 10 23:31:46	A spite golem begins casting Malaisement	23:31:51	5s
Tue Aug 11 16:23:19	A forsaken revenant begins casting Malaise	16:23:22	3s
Tue Aug 11 19:02:55	A forsaken revenant begins casting Malaise	19:02:58	3s

Out of 34 total Your elemental armor fades lines in my log, these 5 have a Malaise-family cast landing 3-5 seconds beforehand — the rest have no debuff cast in the preceding window at all, so this reads as a real but not universal overwrite (natural duration expiry accounts for most fades; the overwrite is a distinct, secondary cause). Worth noting one of the five was cast by something named "Malaisement" rather than "Malaise" itself — possibly a related/variant-named debuff with the same overwrite behavior, which might mean the family of debuffs causing this is a little broader than the single spell name suggests.

I also recall a ghoul scribe casting Malaise on me and overwriting Elemental Shield in-game — I found the cast line in my log (Thu Jul 30 16:55:24 — A ghoul scribe begins casting Malaise.), but it landed during a chaotic multi-mob pull (several other ghouls casting simultaneously) with no matching Your elemental armor fades line nearby, so I can't confirm from the log alone whether it actually landed and caused the overwrite that time, or whether it resisted/missed instead. Flagging as an unconfirmed/recalled data point rather than a sixth verified instance — included mainly to show the source isn't limited to one specific NPC type (undead, golem, and revenant all seem capable of triggering this).

I don't yet have equivalent log-confirmed pairs for the other four (Blood of Pain/Chloroplast, Dooming Darkness/Spirit of Elh'Li, Asystole/Rage, Spine Chill/O`Keil's Levity) — those are from my own in-game observation, not confirmed against log timestamps yet, though I can go pull them the same way if useful.

Why this matters for buff sets specifically: if a "permanent" buff is in my set and gets overwritten this way, I need the missing-buff indicator to actually catch it — that's the entire point of tracking "permanent" buffs in a set to begin with (per the original request: catching the case where a buff drops silently mid-fight and isn't noticed until it's cost something). If the set isn't reliably flagging these as missing when they get overwritten, the feature isn't doing its job for exactly the buffs it matters most for.

Given stage 3 already built the "lost this session" fold that correlates a buff's fade with a hostile spell landing within seconds — this Malaise/Elemental Shield pair looks like exactly the case that fold should already be catching. Does the fold correctly surface this one in-app? If so, that's the evidence needed for a bug report to the EQL devs too (which I'd like to file once there's concrete before/after data, same as the original request's motivation).

Real-world example: click-effect items can overwrite permanent buffs too, not just NPC debuffs

A related case worth including in scope, since it's a different source of the same underlying problem: I recently obtained Sandals of Alacrity, a click-effect item that casts Alacrity — a spell that isn't part of any of my class loadout sets or spellbook; it's a purely item-granted effect I didn't previously have access to.

Alacrity overwrites my Paladin level 44 permanent buff Valor of Marr (landed emote: You feel valorous., fade emote: Your valor fades.). Unlike Valor of Marr, Alacrity has a real, set duration — so once it expires, I'm left with neither buff active until I notice and manually recast one of them.

This is a newly-acquired item for my character, so I don't have a log-confirmed before/after pair for this specific overwrite yet — flagging as a forward-looking scenario rather than a verified log instance, since the item was only just created (merged) near the very end of my current log.

The reason I think this is worth tracking distinctly: it's not just "detect the buff is missing," it's "know why it's missing and suggest the right fix." When Alacrity expires:

• If the player still wants the permanent buff back, EQBuddy could suggest recasting Valor of Marr.
• If the player wants to keep re-clicking the item for its duration instead (e.g. Alacrity might just be strictly better while it's active), suggest recasting Alacrity instead.

Either way, this seems like the same underlying "buff displaced, needs recovery" pattern as the NPC-debuff overwrite cases above — just triggered by a player's own item click instead of a hostile spell. Might be worth the missing-buff indicator (and its eventual suggestion logic) treating "buff slot displaced by a set buff or by another buff I cast" as one general case, rather than something scoped only to debuff-vs-buff conflicts.

Feature idea: buff sets should understand spell lines — search by line, show level next to name, and grey out unusable ranks

A few related asks that build on the search/config flow, since spell lines (the same buff at different ranks as you level, e.g. Elemental Shield → the next rank up) aren't currently something the set UI seems to understand as connected:

1. Search by spell line name should surface every rank in that line. Right now searching seems to require knowing the exact current name/rank of a buff. If I search a spell line by its general name, I'd expect every rank I've encountered (or that exists) to show up together, rather than needing to know which specific rank name is "current" for my level.

2. Show the spell's level requirement next to its name in search/set results. Helps distinguish ranks at a glance without needing to already know the level table for that line.

3. Grey out (but still show) ranks that aren't currently usable, specifically:

   • Ranks the player doesn't have scribed in their spellbook.
   • Ranks above the player's current level (can't be memorized yet).

   Greyed-out rather than hidden, so the player can still see the full spell line and what's coming, without being able to select something not actually usable right now.

4. Level-up suggestions should check for an existing set entry in the same spell line before treating a new unlock as a fresh addition. This is partly already covered by what shipped in stage 3 (the ✓ add / ✕ never-ask-again suggestion row for genuinely new buff lines, with rank-ups apparently needing no action since "the set already covers them") — but I wanted to make sure the underlying spell-line-awareness this depends on is solid, given the search/grey-out gaps above suggest the set UI doesn't fully model spell lines as connected groups yet. If a new rank unlocks in a line I already have a lower rank of in my set, the prompt should recognize that connection explicitly (e.g. "replace level 44 Elemental Shield with level 48 version?") rather than only avoiding a duplicate silently — I want to actually see and confirm the swap, not just trust it happened correctly in the background.

Basically: treat a spell line as one connected concept the UI understands (search, display, and set logic all spell-line-aware), rather than each rank being an independent, disconnected entry that happens to share similar wording.

Answering the open AA-buff question from earlier in this thread

You asked for the AA name and what the log shows when it's used — here's Improved Familiar I (Wizard AA), pulled directly from my log:

[Sat Aug 01 18:51:42 2026] You begin casting Improved Familiar I.
[Sat Aug 01 18:51:42 2026] Your familiar departs.
[Sat Aug 01 18:51:42 2026] You channel pure magic into the form of an improved familiar.

Breakdown, since the three lines aren't all part of one event:

• You begin casting Improved Familiar I. — the cast starts.
• Your familiar departs. — the previous familiar (from an earlier cast, or a manual dismiss) leaving. Not a fade of the AA buff itself — this line also appears standalone whenever a familiar is manually removed, independent of recasting.
• You channel pure magic into the form of an improved familiar. — the actual landed confirmation of the new cast succeeding.

So the buff-relevant pair for tracking purposes is You begin casting Improved Familiar I. → You channel pure magic into the form of an improved familiar. — same "begin casting" → landed-emote shape as a normal spell buff. This AA should behave like any other trackable buff in a set.

I don't yet have a clean example of the actual fade line for Improved Familiar I specifically (i.e. what prints when the ~6hr duration runs out naturally, as opposed to Your familiar departs. from a recast/manual dismiss) — can go find one in my log if that'd help confirm the full up/down cycle.

---

EQBuddy v1.82.0

[DranakCorps-bot]

Working through these — the first one is fixed, the second I can explain and will fix, and the third I want to answer honestly rather than guess at.

1. Buff clicked under a named class doesn't add — fixed

Your reproduction was exact, and the cause is more annoying than a simple failure: it was adding it every time. The pick went into the Paladin bucket correctly, which is also why the next search stopped offering it — a buff already in the target bucket is deliberately excluded. What never happened was showing it.

The breakout builds its rows from the active class combination. Your character isn't detected as Paladin, so the Paladin bucket was stored, correctly excluded from search, and rendered nowhere. Stored, hidden, unremovable — exactly "clicked away", as you put it.

The trap was set by the v1.82.0 fix that made the class picker offer every class (which was itself your report). Options already handled "parked" buckets — classes with picks that aren't in the current combination — and kept working. The breakout composed its own list and didn't. Two editors, two answers to the same question.

There's one answer now, shared by both, with tests for the parked case. Your Paladin picks are not lost — they've been in settings.json the whole time, and they'll appear in the breakout as a parked section as soon as you're on the next build.

2. "seen this session" on spells you didn't cast — you're right, it's mislabelled

That tag is driven by the set of buff casts EQBuddy has observed for the character, and the label overpromises: it's closer to "seen for this character" than "seen this session". Holy Armor and Spirit Armor showing up tagged, when you last cast them while levelling, is that gap exactly.

Two ways to fix it and I'd rather you pick: either the label becomes honest ("seen before" / "you've cast this"), or the data becomes session-scoped so the label is already true. The second sounds better but is worse in practice — the tag exists to float your spells above a catalog of hundreds, and scoping it to the current session would make it useless in the first ten minutes of a login, which is exactly when you're most likely to be building a set. My inclination is to fix the words. Say if you'd rather have it the other way.

3. Armor of Faith duration ~11.9% instead of 15% — the honest answer is that EQBuddy is guessing

To your direct question, which is the right one to ask: the duration is not parsed from anything the game reports. EQBuddy has no access to your spell window or your focus effects — it only reads the log, and the log never states a buff's duration. What you're seeing is a learned value: EQBuddy watches how long buffs actually last on you and remembers it per spell.

That reframes your numbers. The 4230s isn't "3780 base plus a modifier EQBuddy computed" — there's no decay formula in there to be wrong, because there's no formula at all. It's closer to a measurement of one or more real casts. So ~11.9% is most likely what your item actually delivered on a level-48 spell, decay clause included — your explanation (1) rather than (2).

Two caveats worth knowing before you trust it: a learned duration is only as good as the observation behind it (a buff that faded while EQBuddy wasn't running, or that you recast early, can skew it), and the 1h 3m base you compared against came from the spell's tooltip rather than from EQBuddy, so it's an assumption in the comparison rather than a fact in the calculation.

If you want to settle it properly, the clean experiment is the one you offered: a cast with the focus item off, logged start to fade. If EQBuddy learns ~3780s unfocused and ~4230s focused, that's your item's real decayed value measured twice, and the mystery closes.

4. Permanent buffs overwritten by debuffs

Agreed that this is squarely what the original request was about, and it isn't handled. Noting it as real rather than closing it out — but it needs its own thinking, since "permanent" buffs have no duration for the tracker to reason about and the displacement isn't announced in the log as anything distinguishable from a normal fade. If you can catch a log excerpt where one gets displaced, that would move it from "known gap" to "fixable", the way your charm log did for #135 today.

Thanks for testing this thoroughly enough to find the first one — a bug that silently succeeds is much worse than one that fails loudly, and it would have sat there a long time.

[DranakCorps-bot]

Following up on point 3, because I went and checked the code rather than leaving you with my recollection — and the check makes the answer stronger, plus adds one thing you should know.

Confirmed: the duration is either learned or estimated, never computed from a focus item. BuffTracker keeps a per-character store of durations it has actually observed, and uses a wiki base value only as a fallback when it has never seen that spell run its course.

And your own numbers prove which one you're looking at. The wiki base for Armor of Faith is the 1h 3m you quoted. If EQBuddy were falling back to the estimate, it would have shown you exactly 3780s. It showed 4230s — a number that can only have come from watching one of your casts. So that ~11.9% is a measurement of your character, focus item and decay clause and all, not arithmetic EQBuddy did on a base value. Explanation (1) in your list.

The one thing I got incomplete above, and it matters for your controlled test: there is one modifier EQBuddy applies itself — Spell Casting Reinforcement, from your AA ledger, at +5/15/30/50% by rank. You said you have no ranks of it, so it's not in play for you, and it's deliberately applied to the estimate only — a learned duration already contains the character's real extensions, and applying it twice would overshoot every countdown. Worth knowing anyway, since it's the one place a formula does touch these numbers.

So the unfocused test would still be clean for you. If it lands near 3780s learned, you'll have measured your item's real decayed value twice and closed it yourself.

[Frankthetankk]

Following up on the four points from your last two replies.

1. "Seen this session" label — going with fixing the wording

Agreed with your inclination: fix the label rather than scope the data to the actual session. You're right that a truly session-scoped version would be near-useless in the first ten minutes after login, which is exactly when set-building happens. Something like "seen before" or "you've cast this" sounds right — whatever reads as accurate without implying a specific timeframe.

2. Armor of Faith duration — the math now checks out, but there's a gap in how you said EQBuddy got there

I went and pulled two things that weren't available to me when I first raised this:

The wiki confirms the base duration exactly matches your fallback description. Armor of Faith's page (https://eqlwiki.com/Armor_of_Faith) lists Duration: 1 hour 3 minutes — precisely 3780s, exactly what you said the estimate would show if that's what I was looking at.

Extended Enhancement II's own page spells out the decay clause precisely (https://eqlwiki.com/Extended_Enhancement_II): "Limit Max Level: 44 (lose 5% per level after)." Armor of Faith is level 48 for Paladin — 4 levels over the cap. Working the decay both plausible ways:

• 5% of the bonus lost per level (multiplicative): 15% × (0.95)^4 ≈ 12.2%
• 5 percentage points of the original 15% lost per level: 15% − (4 × 0.75%) = 12%

Both land close to my observed ~11.9% — well within reasonable margin. So the actual decayed value is almost certainly correct, and your explanation (1) — the item's own decay clause accounts for the gap from a flat 15% — looks right.

Here's the part that doesn't fit, though. You said the 4230s figure "can only have come from watching one of your casts" reach a natural fade, since a fallback would show exactly 3780s and a learned value implies EQBuddy observed the real duration play out. I went back through my full log and searched every instance of Armor of Faith (60+ casts across the whole session history) — every single one is followed by a You forget Armor of Faith line within seconds to a few minutes of casting it, which I now understand is a spellbook un-memorize event (freeing the spell slot), not a duration timer expiring. None of these casts ever ran anywhere close to the 1+ hour duration needed to fade naturally.

So if EQBuddy's shown duration really is a learned value, it doesn't look like it could have come from watching this spell fade in the log I have — there's no natural fade in it to have learned from. A few possibilities I can think of, but wanted to flag rather than guess at which:

• It was learned from an earlier session/log not included in what I've shared with you
• There's a code path where a duration gets attributed as "learned" from something other than an actual observed fade
• Something else in how the learning mechanism works that I'm not accounting for

To be clear, I'm not doubting the number anymore — the decay math backs it up convincingly. I'm just flagging that the explanation of how EQBuddy arrived at it doesn't match what I can find in my own log, in case that's worth a second look on your end.

3. Wiki correction spotted along the way

Unrelated to the bug itself, but worth flagging while I was on the page: Elemental Shield's wiki entry (https://eqlwiki.com/Elemental_Shield) lists its wear-off message as "Your elemental shield fades." — but my actual log consistently shows "Your elemental armor fades." instead. Looks like the wiki page may just have the wrong wear-off text on file. I'll raise this with the wiki editors separately, but flagging here too in case it's relevant to anything EQBuddy's wiki-sync tooling keys off of.

4. Permanent buffs overwritten by debuffs — a concrete detection mechanism, not just more log evidence

Wanted to lay out the actual mechanism this could run on, since I think it's more buildable than "known gap, needs more thinking" suggested.

The pattern, using data EQBuddy already parses:

1. An NPC casts a detrimental spell on the player — logged as "X begins casting Y."
2. Within a few seconds, the permanent buff's own wear-off line appears — even though nothing should have caused it to fade (no duration to expire, no death, no manual removal).
3. The detrimental spell's own "cast on you" landed message appears around the same time.

Concrete example with wiki-confirmed message text:

• Elemental Shield (https://eqlwiki.com/Elemental_Shield) — Duration: Permanent. Landed: "You feel protected from fire and ice." (Wear-off per my log: "Your elemental armor fades." — see point 3 above on the wiki's own text being wrong here.)
• Malaise (https://eqlwiki.com/Malaise) — a detrimental NPC-cast spell. Landed on me: "You feel somewhat vulnerable." (confirmed matching the wiki page exactly.)

When Elemental Shield's fade line appears within a few seconds of an NPC's Malaise landing, that's strong enough correlation to flag with reasonable confidence — not proof beyond doubt, but enough to (a) mark the set buff as "lost — possibly overwritten by Malaise" in the missing-buff indicator and set history, and (b) hand the player a ready-made before/after snippet to paste into an EQL bug report, exactly as stage 3's existing "lost this session" fold already does for other cases.

Why I think this deserves priority over "known gap, needs more thinking": a permanent buff's own wear-off line firing at all is itself the anomaly worth flagging, precisely because it has no duration and shouldn't fade under normal circumstances. The tracker doesn't need to compute or predict anything here — it just needs to notice "this buff's fade line appeared, and I have no natural-expiry explanation for it (no timer to have run out), so something displaced it" and then check whether a detrimental cast landed on the player in the preceding few seconds to attribute a likely cause.

My honest opinion on the underlying game behavior: setting the feature request aside, I think this points to a real EQL-side bug rather than intended design. If a buff's own tooltip and wiki page say "Duration: Permanent," it shouldn't be something an NPC's debuff can strip as a side effect. I think it's genuinely EQBuddy's (and by extension the community's) responsibility to surface this kind of pattern clearly enough that it can be reported to the EQL devs with real evidence — which is exactly what this detection mechanism would provide. I'm not asking EQBuddy to change EQL's behavior, just to make the pattern visible and reportable, the same way the stacking-conflict ledger already does for "did not take hold" cases.

Happy to keep pulling more confirmed pairs (I have Malaise → Elemental Shield well-documented; still need clean instances for the other four I've observed in-game) if that would help move this forward.

---

EQBuddy v1.82.0

[DranakCorps-bot]

You were right to push on point 2 — I checked, and the answer is that both of us were looking at the right thing from different ends. Your log does contain the fades. They just don't say "Armor of Faith".

The missing fades

EQBuddy identifies buffs by their landing and fade messages, not by spell name, because that's all the log gives it. For your spell line, the catalog entry is:

• Landing: You feel the favor of the gods upon you.
• Fade: You no longer feel blessed.
• Spells sharing those messages: Armor of Faith (3780s), Shield of Words (4320s), Guard (2700s), Holy Armor (1620s)

So searching your log for "Armor of Faith" finds the casts and the You forget Armor of Faith lines — and cannot find a single fade, because the fade line never contains the spell's name. Search for You no longer feel blessed instead and I expect you'll find them.

The other half: "You forget X" un-memorises the spell from your spellbook — it doesn't remove the buff. It frees the slot; the buff keeps running its full duration and fades on its own an hour-plus later, which is why you have forget-lines minutes after each cast and fades nowhere near them.

Two things corroborate that the 4230s is genuinely learned:

1. The catalog's own base for Armor of Faith is exactly 3780s — I checked the data file, and it matches the wiki page you found. So 4230 cannot be a fallback; a fallback would have shown you 3780 precisely.
2. 4230 ÷ 6 = 705, exactly. Learned durations are floored to the 6-second server tick before being stored. A number that lands dead on a tick boundary is the signature of that code path. A coincidence at that precision would be quite something.

So: explanation (1) from your original list, and your decay maths — both readings landing near 11.9% — is almost certainly what your item really delivers on a level-48 spell. Thank you for doing that legwork; it's a better answer than either of us had separately.

1. "Seen this session" — agreed, fixing the wording

Settled then. It'll read as something that doesn't promise a timeframe it can't keep.

3. Elemental Shield's wear-off text

Good catch, and yes it matters to us: our fade-message catalog is what maps a log line back to a buff, so a wrong wear-off string means that buff's fade is invisible to EQBuddy. Please do raise it with the wiki editors — that's the fix that reaches every tool, not just this one. Post the correction here too when it lands and I'll make sure our catalog carries the text your log actually shows.

4. Permanent buffs — you've moved this from "gap" to "buildable"

You're right, and the reframing is the useful part: a permanent buff's fade line appearing at all is itself the anomaly. There's no timer that could have run out, so its very existence needs explaining. That's a much sharper trigger than trying to detect displacement directly, and it uses only what's already parsed.

Your Malaise → Elemental Shield pair with both messages wiki-confirmed is exactly the shape of evidence needed. More confirmed pairs would genuinely help — particularly ones where the debuff differs, so the correlation window can be tested against more than a single case.

One thing I'd want to get right: EQBuddy would be saying "possibly overwritten by X", and the honest version has to stay possible rather than drift into certain. The stacking-conflict ledger is the right precedent — it reports what it saw and leaves the conclusion to you.

I'm flagging this to David with your mechanism attached rather than my earlier "needs thinking", because it now has one.

[DranakCorps-bot]

Your mechanism is built — the correlation half of it, anyway. Here's exactly what landed and what didn't.

What now works

Your Malaise → Elemental Shield case reads "lost as Malaise landed" instead of "faded".

The interesting part is that most of what you described already existed: the lost-buff history has been able to blame a hostile landing since stage 3. What it accepted as evidence was the problem — a named damage line, or a slow. Malaise is neither. It drops strength and AC, deals no damage, isn't a slow, and its only trace in the whole log is that flavor line. So there was nothing to correlate, and the loss fell back to "faded" with the cause you actually wanted silently dropped.

So the fix was the missing catalog, not new logic: 615 detrimental spells across 397 cast-on-you lines, generated from the same wiki harvest as everything else. The generator proves those messages collide with no other catalog, because a line that parsed as two different events would be a worse bug than the one being fixed.

Two constraints I kept, both from your own framing about dev reports:

• The window stays 2 seconds. A debuff landing thirty seconds before the fade explains nothing, and a loose window would cheerfully blame an unrelated one.
• A shared line names every candidate, not one of them. If a message belongs to both Cripple and Incapacitate, it says so. You're going to paste this into a bug report — a confident wrong cause is worse than an honest vague one.

Worth noting a deliberate asymmetry with the other fix that went in today. For the buff catalog I loosened a filter to admit spells the wiki leaves blank, because the cost was missing real buffs. Here blanks stay out: the cost of a mistake runs the other way, and inventing a hostile cause out of your own casting would be exactly the kind of confidently-wrong output this feature exists to avoid.

What did NOT land, and why it matters to you specifically

Permanent buffs still aren't tracked at all. They have no duration, so they never enter the buff timer, so they never transition to Missing — which means there's no transition for this correlation to attach to.

You were ahead of me on this: "a permanent buff's own wear-off line firing at all is itself the anomaly worth flagging." That's right, and it's the other half. It needs permanent buffs to exist in the tracker as something with no countdown, which is a real change to how the tracker thinks about duration rather than a catalog addition.

So concretely: if a timed set buff of yours gets displaced by a debuff, you'll see the cause from the next release. Elemental Shield specifically still won't, until that second half is done. I'd rather tell you that than let you find it.

Two smaller things from your list

"Seen this session" — the wording fix is agreed and queued.

Elemental Shield's wear-off text — please do raise it with the wiki editors. Our fade catalog is generated from those pages, so while the wiki says "Your elemental shield fades" and your log says "Your elemental armor fades", EQBuddy cannot see that buff drop at all. That one correction unblocks your own case on our side too, which is a neat argument for fixing it upstream rather than us special-casing it.

Thanks for turning "known gap" into something with a shape. The correlation was buildable in an afternoon precisely because you'd worked out what the evidence actually is.

[Frankthetankk]

Testing today's build — found a cluster of issues around the Buff set breakout's search and class detection, plus a genuinely interesting root cause on one of them.

Bug: Symbol of Pinzarn permanently shows "missing" even when actively cast on myself — root cause was a wrong wiki entry, now fixed

Tested this directly: removed Symbol of Pinzarn, then recast it on myself, confirmed it landed and is active in-game, and the breakout still showed it as missing.

Dug into why. My log shows this on cast:

You begin casting Symbol of Pinzarn.
The symbol of Pinzarn flashes before your eyes.

The eqlwiki page (https://eqlwiki.com/Symbol_of_Pinzarn) had the "Cast on You" message listed as "A mystic symbol flashes before your eyes." — which doesn't match what actually prints in the log at all. I've already corrected the wiki page to the real text: "The symbol of Pinzarn flashes before your eyes."

If EQBuddy's buff-landed detection is built from wiki-sourced message text (per the weekly knowledge-refresh process), this would fully explain the bug — it was watching for text that never appeared in any log, so the buff could never register as landed no matter how many times it was actually cast. Now that the wiki is corrected, is there a way to trigger an early refresh so this fix reaches EQBuddy sooner than the normal weekly cycle? And separately — is this landed-message text sourced from the wiki as the sole source of truth anywhere in the detection pipeline? If so, a single wrong wiki entry silently breaking a buff's detection permanently (with no error, just an always-wrong "missing" status) seems like a fragility worth knowing about for other spells too.

Bug: search for correctly-spelled "Endure" returns zero results for Endure Magic, Endure Poison, or Endure Disease

Confirmed with the correct spelling (not a typo) — searching "Endure" in the Buff set breakout's search box under Paladin returns nothing for any of the three Endure-line spells, despite Endure Magic being a valid, documented Paladin spell (https://eqlwiki.com/Endure_Magic, level 29 Paladin). These are common, well-known buffs, so this isn't an obscure catalog gap — worth checking whether the search index is missing this spell line entirely or whether something else in the matching logic is failing on it specifically.

Bug: class detection stuck on "Berserker" despite my actual class being something else entirely

The Buff set breakout still shows "BERSERKER (inferred)" as a detected class section, with nothing picked for it. My actual class is not Berserker — I believe I very briefly swapped into it during pre-level-10 leveling and have been a different class ever since. It looks like whatever signal EQBuddy used to infer this got set once early on and never got refreshed against my actual, current class.

Worth noting: as far as I know Berserkers don't cast buffs at all (unless there are AA-granted ones I'm not aware of), so a Berserker section showing up in a buff-tracking window is a strange result on its own, independent of whether the inference itself is accurate.

UI complaint: empty "(any class)" and empty inferred-class sections make the breakout window unnecessarily large

Related to the above — with "(any class)" showing "nothing picked for this class yet" and the incorrectly-inferred "BERSERKER" section also showing "nothing picked for this class yet," the window ends up roughly twice as tall as it needs to be before I've even added anything. Given "(any class)" and a wrongly-detected class are both empty, it might be worth collapsing or hiding genuinely empty sections by default (maybe with a small "+ add a class" affordance) rather than always reserving full vertical space for sections with nothing in them yet.

Feature idea (reinforcing the one already raised in #120): auto-detect landed self-cast buffs and prompt to add them

I have to manually search and add every buff I want tracked, including ones I've clearly already cast on myself and can see active in-game (Armor of Faith, Valor, Divine Vigor, Vision Shift are all currently up and correctly showing in my Paladin section — so EQBuddy clearly already detected these landing). Since the detection is evidently already happening for buffs that do get added, it seems like a small step to extend that into a proactive suggestion: after a buff I cast on myself lands and isn't already in my current set, show a small "+" prompt next to it (or in a summary list) offering to add it, with a way to dismiss/never-ask-again per buff, matching the pattern the stage 3 level-up suggestions already use. I understand from the earlier thread that the noise-floor concern (getting buffed by others in a group) was the sticking point — scoping this specifically to buffs the log shows me casting on myself should sidestep that, since a self-cast in the log is an unambiguous signal separate from received-buffs from other players.

---

EQBuddy v1.82.0

[DranakCorps-bot]

Five things, and you found a root cause I'd have taken a long time to reach. Going through them in order of what's now true.

1. Symbol of Pinzarn — fixed, using your wiki correction

You were exactly right about the mechanism, and thank you for fixing the source rather than just reporting it.

I verified your correction is live, updated EQBuddy's harvest record from it, and regenerated the catalog. Pinzarn is now its own entry keyed on "The symbol of Pinzarn flashes before your eyes." with its 45-minute duration — and the shared A mystic symbol flashes before your eyes. line correctly holds the four spells that genuinely do share it (Naltron's Mark, Marzin, Naltron, Transal).

No need to wait for the weekly refresh; it converges with it, since the next full harvest reads the same corrected page.

On your structural question — yes, and you've identified a real fragility. The landing message is the sole source of truth for detection, sourced from the wiki, and a wrong one disables that buff's detection silently: no error, no warning, just a buff permanently reported missing. Nothing currently notices, and nothing could — EQBuddy can't distinguish "you never cast it" from "I'm watching for text that doesn't exist."

I don't have a good answer yet. The shape of one might be: when a spell is cast and no landing line follows within the usual window, that's suspicious, and a spell that never resolves across many casts is very suspicious. That's exactly the evidence you gathered by hand. Worth its own thread, and I've noted it as a gap rather than pretending it's covered.

2. "Endure" returning nothing — already fixed, you're on an old build

Endure Magic, Poison, Disease, Cold and Fire were all missing from the catalog entirely until this morning. The cause was a filter that dropped any spell whose wiki page leaves the "beneficial" field blank — 200 of ~1,900 pages do. DeusSilvam hit the same wall from the shaman side (#162).

Fixed in 1.86.0, which recovered 42 spells including the whole Endure line. You're on 1.82.0 — updating should make all three searchable.

3. Class detection stuck on Berserker

Not investigated yet and I'd rather say so than speculate. Your reasoning is sound, though — a class you played briefly before level 10 and never since shouldn't outrank years of evidence, and a Berserker section in a buff window is a tell on its own.

If you can say roughly what the log would show — do you still have any line naming Berserker in a recent log, or is this purely historical? — that would tell me whether the inference is reading stale data or persisting a stale conclusion. Different bugs.

4. Empty sections making the window tall

Fair, and worth flagging that I made this slightly worse today: fixing your earlier "buff added under a non-active class vanishes" bug means the breakout now also shows parked class buckets. That was necessary — a pick you can't see is a pick you can't remove — but it's more vertical space.

Collapsing empty sections behind a small affordance is the right answer and I'll take it. It also makes #3 much less annoying even before the inference is fixed.

5. Auto-suggest self-cast buffs

Your scoping argument is the one that unlocks it. The objection was never the idea, it was the noise floor — a group buffing you would bury the signal. Restricting it to buffs the log shows you casting on yourself removes that entirely: a self-cast is unambiguous, and it's already parsed, since that's how the ones in your set get detected at all.

That's a genuinely small step from what exists, and the level-up-unlock suggestions already establish the pattern for offering something without nagging. Flagging to David with your framing attached — it's a better version of the request than the original.

---

Items 1 and 2 are in the next release. 3, 4 and 5 are on the list, and 5 is the one I'd expect to happen soonest.

[Frankthetankk]

Answering your question on point 3 (class detection stuck on Berserker):

Checked my full log — every single "berserker stance" line (the likely inference source) is from the very start of the log, Tue Jul 28, five occurrences between 18:29 and 19:23, and nothing since:

You assume a berserker stance.

Nothing else in the log mentions Berserker in connection with my own character at all — the rest is other players' chat, an NPC's "goes into a berserker frenzy" flavor line, and one unrelated player named Kainite casting a spell called "Berserker Strength."

So it looks like this isn't reading stale data repeatedly — it read a real signal exactly once, on day one of the log, and never got refreshed against anything since. That's about 2+ weeks of no reinforcing (or contradicting) evidence, if that timing helps narrow down whether the inference is "stale data" vs. "persisting a stale conclusion" as you put it.

One more thing worth flagging: "You assume a berserker stance" sounds like it could be a combat stance toggle rather than proof of being the Berserker class itself — I don't actually know if other classes can also access a "berserker stance" as a general combat mechanic. If so, that might be worth reconsidering as a class-inference signal at all, separate from the staleness issue.

---

EQBuddy v1.86.0

[DranakCorps-bot]

That's the answer I needed, and it points somewhere worse than "stale data" — thank you for going back through the whole log rather than just the recent part.

What the inference actually does

Class detection is frequency-weighted evidence: a small table of class-unique signals, three sightings before it will say anything at all, and the most-seen class wins. The table is deliberately tiny, because a wrong inference filters your quest list wrongly.

Here it is, in full:

Backstab → Rogue · Harm Touch → Shadow Knight · Lay on Hands → Paladin · Flying Kick, Round Kick, Tiger Claw, Eagle Strike, Dragon Punch → Monk · Frenzy → Berserker

Two things fall out of that, and the second is the actual bug.

1. It isn't the stance line. "You assume a berserker stance" isn't in the table — stances are tracked for combat-time attribution, not class. What tagged you is Frenzy, which your dabble would also have produced. So your reading was right in substance: a real signal, from day one, five-ish times, never revisited.

2. Every class in that table is a melee class. There is no signal for Shaman, Cleric, Enchanter, Wizard, Magician, Necromancer, Druid — none. So a caster who once levelled a melee alt past three Frenzies is tagged with that melee class permanently, because there is nothing a caster can ever do that the table counts as evidence to the contrary. It isn't that the old evidence outweighs the new; it's that the new evidence doesn't exist. The count also never decays, so even a same-class-family signal wouldn't help.

That's a design flaw, not a tuning problem, and it explains why it looked stuck rather than merely wrong.

What I'd do about it

Two changes, and I'd like your view on the second:

• Give casters signals. Class-unique spell lines exist and EQBuddy already has the wiki spell catalog to draw them from — a Shaman-only or Enchanter-only spell is exactly as diagnostic as Backstab. This is the substantive fix; it's what makes contrary evidence possible at all.
• Let recent evidence outweigh ancient evidence, so a class you played months ago loses to the one you're playing now, instead of being tied forever at whatever count it reached.

The thing I want to avoid is a manual "set my class" box. It would fix your symptom, but a widget that has to be told what it's looking at has given up on reading the log — and every player who never finds the setting keeps the bug.

Your other points

• Symbol of Pinzarn — fixed and shipped in 1.87.0, using your wiki correction.
• Empty class sections doubling the buff breakout's height — still open, and I made it slightly worse in the interim by correctly showing parked buckets. It's on the list.
• Auto-suggesting self-cast buffs — still the one I most want to build, and your scoping argument is why: a self-cast is unambiguous in a way "someone buffed me" never is.
• A wrong landing message in the wiki silently disabling a buff's detection forever — this is the one that has stayed with me. You're right that it fails with no error anywhere, and "the catalog is complete" and "the catalog is wrong" look identical from inside EQBuddy. I don't have a good answer yet. The honest version is probably that a tracked buff which is cast but never lands, repeatedly, is evidence the landing line is wrong — EQBuddy sees both halves and could notice the mismatch instead of waiting silently forever.

[Frankthetankk]

On the recency question — here's my take.

Recency-weighting, in general: yes, but I'd lean toward decay over a hard cutoff. A flat "only count evidence from the last N hours/sessions" risks the opposite problem — a player who takes a week off shouldn't have their class silently forgotten the moment they log back in. What I'd actually want is evidence that fades in weight over time rather than expiring outright: a Frenzy cast six months ago should count for very little, but not literally zero, so a returning player with no new evidence yet still gets their last known class rather than reverting to "no idea."

One thing I'd flag as a real risk with recency alone, separate from decay curve details: the caster-signal fix (giving Shaman/Cleric/Enchanter/etc. their own diagnostic spells) is doing the actual heavy lifting here, and I think it should land first regardless of how recency gets tuned. My specific bug was really "a caster has literally no way to ever out-evidence a stale melee tag" — that's a missing-evidence problem, not a stale-evidence problem. Recency weighting helps once there's something for a caster to weigh in favor of — without the caster signals, a caster still has zero contrary evidence no matter how fast old evidence decays. So I'd frame recency as the thing that makes class-swapping feel responsive once both classes have signals, not as the fix for my original bug on its own.

On implementation, no strong opinion on the exact curve/half-life — that's your call to make on what's cheap to compute and easy to reason about. Just want to flag one edge case worth deciding on purpose rather than by accident: someone who plays two classes roughly equally (alt-swapping every session, not a one-time dabble like my Berserker case) — does recency mean the detector just flip-flops between them constantly, or is there some stickiness/hysteresis so it doesn't visibly thrash? Not sure it matters much in practice, just wanted to name it as a case worth thinking through rather than discovering later.

Two smaller things from your last reply, while I'm here:

• Empty class sections / window height — still happy to see this land whenever it fits in; not blocking anything for me.
• Auto-suggest self-cast buffs — glad this is still the one you want to build soonest. No new input from me, just wanted to say I'm still looking forward to it.

[DranakCorps-bot]

Closing the loop on the recency question — what you described is what got built, and your instinct about decay-over-cutoff is exactly how it works.

Class inference now derives signals for all sixteen classes from the shipped spell/skill catalogs (the caster-signal fix you flagged as the prerequisite — no more melee-only table where casters had no way to vote), and the evidence decays with a half-life rather than expiring: sightings halve in weight every ten minutes of log time. So an hour-old handful of lines is worth about 1/64 of what you're casting right now, but never literally zero — and a class whose only tells are on long reuse timers still holds a lead it has earned.

Two details that answer your specific worries:

• The returning player keeps their class. Decay runs on log time, not wall clock — a week away isn't a week of decay. And when EQBuddy re-reads the log it re-infers exactly what it inferred live, so your last known class emerges from the replay rather than reverting to "no idea".
• The confidence guards you wanted are there: a sighting floor before it says anything at all, corroboration required for anything an item could have cast, and a minimum lead margin below which no class is named. The UI always says "(inferred)", never states it as fact.

And the original feature this thread asked for — buff sets with a missing-buff line — shipped too: define the buffs you expect running (per class, plus an any-class bucket) and the Buffs card shows what's missing, whether it expired or got overwritten.

Left open: nothing on this one from our side. If the inference ever wears the wrong class for you again, that's a bug report we want — with the log, which is all it takes to replay exactly what it saw.

— Dranak (Claude Code)

[Frankthetankk]

This is great — thanks for building it exactly to the decay-over-cutoff framing, and for the honesty guards (sighting floor, corroboration, minimum lead margin) on top of it. Glad the "(inferred)" labeling stays honest too.

One thing from my original reply I don't see explicitly addressed: the alt-swapping edge case, where someone plays two classes roughly equally rather than a one-time dabble like my Berserker situation — does the half-life decay handle that gracefully (recent evidence for whichever class you're actually playing right now wins cleanly), or is there a real risk of visible flip-flopping session to session for someone who genuinely splits their time? Not sure if the minimum lead margin already covers this implicitly or if it's a case worth testing separately. No urgency either way — just want to make sure it didn't fall through the cracks rather than being a deliberate non-issue.

Everything else here is exactly what I was hoping for. Thanks for such a thorough build across the whole thread — this one covered a lot of ground.

[DranakCorps-bot]

It didn't fall through the cracks — but you were right that it needed testing separately rather than reasoning about, so it got a test.

Short version: no flip-flop, and the lead margin turns out to be only half the reason.

The margin does the work you expected — a class is named only when its weight is at least twice the runner-up's. But on its own that would still permit exactly what you're describing: two classes trading the lead, each briefly clearing 2×. What actually prevents the flicker is the other outcome. When the margin isn't met the answer is "" — "don't know" — not the next best guess. So the reading only ever has two states: the class you're currently playing, or nothing.

Which means an even splitter never sees the label name the class he isn't playing. He sees it go quiet during the handover, then name whatever he's actually casting.

What the test drives, because everything above was a reading of a constant until it was: four alternating twenty-minute stretches — two half-lives each, which is what an alt-swap night looks like rather than a one-line dabble — 120 events per stretch, recording the answer after every single one. It asserts two things:

1. Every answer it ever gave was "", Rogue or Wizard. It never once named the class not in hand.
2. Every change of mind passed through "". A direct Rogue→Wizard swap is precisely the visible flicker you were asking about, and the test fails if one ever happens.

The honest limitation, since it's the flip side of the same rule: during the handover the label really does go quiet for a while, so on a fast swap you'll see (inferred) disappear rather than update. That's deliberate — quiet is the honest state when the evidence is genuinely split — but it's a real behaviour and you would notice it. If it turns out to be annoying in practice, that's worth its own report; "say nothing" and "say the wrong thing" are the two options there and we picked the first.

One aside that may be reassuring: decay can never cause a flip on its own. It's uniform, so it scales both classes equally and can't reorder them. The only thing that reorders them is you casting something.

— Dranak (Claude Code)