Feature request: attack speed debuff alert with cure/dispel guidance

[Frankthetankk]

Feature request: attack speed debuff alert with cure/dispel guidance

Summary

Add an alert that fires when the player's attack speed % is reduced by a known spell/item slow, showing:

• the numeric % the attack speed is currently reduced by
• how to remove it (cure line, dispel, class-specific ability, etc.)
• the debuff's counter count, and roughly how many casts of the relevant cure/dispel/ability it would take to fully remove it
• ideally, which of the player's own known abilities can do the removal, ranked by fastest/fewest casts if more than one option applies

This is specifically about attack speed debuffs (slows), not movement speed (snares) — worth being explicit since debuff names/log lines can look similar at a glance.

Example

Level 50 Beastlord spell Sha's Lethargy: a 40% slow with 12 disease counters, removable via the Cure Disease spell line (repeat casts needed depends on how many counters each cast of the cure removes). A Paladin with Purify Body available would ideally see that option surfaced directly rather than just "cast Cure Disease," since it may clear more counters per cast or be more mana/time efficient for that class. This one's not just theoretical either — Master Yael is sometimes a Beastlord on higher difficulties, so a raid or group could realistically eat a Sha's Lethargy mid-fight without expecting it.

Why this matters

With how long the buff/debuff list can get, it's easy to miss that an attack-speed debuff has landed on you — it doesn't always stand out visually the way a big damage-over-time tick or a stun does, especially in a busy fight with multiple buffs/debuffs scrolling past. If it goes unnoticed and stays on too long mid-fight, a 40%+ slow can meaningfully change how the fight goes: less DPS output, longer fight duration, more incoming damage taken over that extended time, and in a close fight, potentially the difference between winning and wiping. This matters more in group/raid content where a slow on the group's primary melee DPS can ripple into the whole encounter's pacing, not just that one player's output. An alert that surfaces it immediately — with the "how do I get rid of this, and what's my fastest option" answer attached — turns a silent, easy-to-miss DPS loss into something the player can actually notice and react to in the moment, rather than realizing after the fight that a fight took twice as long as expected.

Could the new regex watch rules (v1.51.0, #83) get partway there today?

Now that Match boxes support full regex, I could probably build a manual watch rule alerting on known slow-spell landing lines using an alternation pattern (e.g. Sha's Lethargy|Tarew Marr's Insects|...), the same way #83's example alternated "CH -->" and "CH on". That's useful as a stopgap, and I may try it myself. But it still requires the player to know and maintain the full list of slow-spell names, their % and counters, and cure-line mappings by hand — which is the same "too impractical to expect per-player setup" problem as before, just made slightly more powerful by regex rather than solved. I think this still argues for the default/built-in catalog approach below, with regex watch rules as the underlying matching mechanism the built-in alert could use internally.

Account for the player's own known cures, not just the generic cure line

Rather than only pointing to a generic cure-disease/dispel spell line, consider checking the player's own spellbook and AA list for class-specific abilities that can remove the debuff type in question — for example, a Paladin's Purify Body. Different classes have different tools for this (cure spells, AAs, disc-style abilities, certain items), and what's "fastest" for one class may not apply to another. If EQBuddy already knows (or can infer, e.g. from spell-cast lines already appearing in the log) what the player has available, the alert could point to the fastest/most relevant option the player actually has, rather than a generic suggestion that may not apply to their class or may not be their most efficient option.

If the suggested cure is on its own reuse timer (particularly for AAs/discs like Purify Body), it would help if the alert could account for that too — recommending an ability the player can't actually use yet would be misleading. Not sure how feasible it is to track ability cooldowns from the log, but worth considering if it's already something EQBuddy has visibility into.

Why default behavior instead of per-spell setup

Given how many slow spells exist across classes and expansions — and that new ones get added as the wiki catalog grows, similar to how the quest catalog keeps expanding — asking players to manually configure a watch rule for each one seems impractical, even with regex making each individual rule more powerful. Most players wouldn't know all the relevant spell names/counter counts to set them up correctly even if they wanted to. Would it be feasible for EQBuddy to ship with known attack-speed debuffs (name, % slow, counter type/count, matching cure line/ability options) built in as a default alert, rather than requiring the player to set each one up individually the way custom watch rules currently work? This could potentially reuse or extend the same kind of catalog approach already used for quests and wiki data — i.e., a maintained dataset the app ships with and periodically refreshes (the same weekly knowledge-refresh pipeline that already updates quest and spell catalogs), rather than something built entirely from user-submitted rules.

Could this build on the existing spoken-alert system?

v1.47.0 already shipped a buff fade picker and spoken alerts feature (#71), and as of v1.51.0 spoken alerts work cross-platform (Windows SAPI and macOS say). Rather than building an entirely separate alert system, it might make sense for this to piggyback on that existing infrastructure — both conceptually (a debuff landing/fading is similar in shape to what that system already tracks) and practically (less new code, more consistent experience for the player, and it would inherit cross-platform support for free).

Consider a raid-only toggle

It might be worth adding a toggle to enable this alert only during raid instances, rather than always-on. Group/open-world slows are usually lower stakes and easier to just notice/react to normally, while raid encounters are where a missed slow is most likely to actually swing the outcome — and raids are also where the alert would be most useful given how much else is happening on screen at once. A toggle would let players who don't want the extra alert noise in casual solo/group play opt in only where it matters most.

Important caveat: stacking debuffs and removal order

If a player has multiple debuffs stacked (e.g. a disease debuff AND something else, like a poison or curse effect from a different NPC or AoE), a cure or dispel typically strips from the top of the stack down — so it may clear other, unrelated debuffs before it reaches the attack-speed one. This means a naive "cast X to remove this" instruction could be misleading if the player has several debuffs active at once, since the actual number of casts needed to reach and remove the slow could be higher than the slow's own counter count alone would suggest. Any alert/guidance around removal should ideally account for this — either by noting "you have other debuffs active which may need clearing first" when detectable, or at minimum flagging that stack order can affect how many casts are actually needed in practice.

Additional caveats worth considering

• Multiple attack-speed debuffs stacking: on the rare chance a player has more than one slow active at once, the effective total isn't simply additive — if the alert reports a %, it should ideally reflect the combined effective slow rather than just whichever landed most recently.
• Haste interaction: if the player has a haste buff active alongside the slow, their actual current attack speed isn't just the raw debuff %. Worth deciding whether the alert should show net effective speed (haste minus slow) or the raw debuff value — either is reasonable, but worth being explicit about which.
• Alert frequency: since combat/buff lines can be frequent in the log, the alert should probably fire once when the debuff lands (and again only if the effective % changes, e.g. from stacking), rather than repeating on every tick while it's still active — otherwise it risks becoming noisy rather than useful.

Open questions

• Does EQBuddy currently track incoming debuffs/buffs landing on the player specifically (versus buffs landing on NPCs, which the wiki-pack work has focused on)? Not sure if the existing SpellFade watch-rule infrastructure already has enough visibility into this to build on, or if this would need new log parsing to detect debuffs landing on the player and their associated counter counts.
• Does EQBuddy have visibility into the player's known spells/AAs already (e.g. from spell-cast lines seen in the log over time, or some other source), or would this need to be entered/configured somewhere by the player?
• Is there a reliable source (in-game or wiki) for per-spell counter counts and matching cure-line/ability counter removal rates across all classes, or would this need to be crowd-sourced/verified the same way the eqlwiki stat-block data has been? If it's the latter, happy to help test/verify entries the same way the NPC stat-block fields have been getting field-tested.

---

EQBuddy 1.53.2 · Windows 19045

[DranakCorps-bot]

First: apologies for the quiet — this landed the same hour as a release flurry and sat unanswered longer than it should have. It deserved better, because it's another exemplary report: the caveats section (stack-order, haste interaction, alert frequency) reads like a design review we didn't have to run.

This is happening. And your three open questions all have good answers:

1. Does EQBuddy have the visibility? Yes — better than you might hope. Our weekly wiki spell harvest already carries, for every spell page: the slot effects (so "Decrease Melee Haste by 40%" and "Increase Disease Counter by 12" for Sha's Lethargy), the landing-on-you message ("You feel lethargic…"), and the fade line (the fade side already powers the buff-fade picker — Sha's Lethargy is in that catalog today). Filtering the harvest for attack-speed debuffs yields ~40 slow spells; no snares in the set (your slow-vs-snare distinction is enforced by the effect text itself).

2. Player's own cures? Partly, and honestly: the log tells us every spell you cast, so EQBuddy can learn your cure repertoire from observation. What the log does not reliably expose is reuse timers, so cooldown-aware ranking is out of scope for now — the alert will never recommend by cooldown state, rather than pretend to know it.

3. Counter data source? The same harvest: ~24 cure spells with counters-removed-per-cast (Cure Disease 1, Counteract 2, Abolish 4…), plus the AA catalog for the likes of Purify Body. It flows through the same weekly refresh + review pipeline as the quest catalog — and yes, your verification offer is accepted: the new catalog will ship with a report you can check entries against.

The build, in two phases:

Phase 1 (in progress now): a built-in slow alert — no per-spell setup, exactly as you argued. When a slow lands on you: a chip appears with the % and counters ("40% slow · 12 disease counters"), an optional spoken alert fires once (again only if the effective % changes — your frequency caveat, encoded), and it clears on fade. Cure guidance v1 is by counter type, with the whole line's efficiency listed. Includes your raid-only toggle. Where the wiki lacks a landing message or ranks share one, the chip says the honest range rather than guessing.

Phase 2: ranking by your observed cures, so the Paladin sees Purify Body first. Stack-order gets a truthful treatment: when we can see other counter-debuffs active, the alert notes "other debuffs may absorb cures first" — a flag, not a fabricated cast count, for exactly the reason you gave.

Watch this thread — Phase 1 should land in the next release or two.

[DranakCorps-bot]

Now live in v1.68.0 — your widget will offer the update on its own.

Exactly as scoped upthread: a slow lands on you → a 🐌 chip with the honest % ("Slowed 40% · 12 disease counters", or the range when ranks share a landing line), an optional voice that speaks once per landing, cure guidance strongest-first on hover (Legends numbers: Abolish Disease strips 36/cast, Counteract 8, Cure 4), your raid-only toggle (detected from raid chat), and clean clearing on fade/expiry. All 34 known slows, zero setup. One correction to the example upthread you'll enjoy: in Legends, Purify Body is the Monk AA — the Cleric one is Purify Soul (72 counters, 30-min refresh). Phase 2 (ranking cures by what you've been seen casting) is still queued.

The catalog report you offered to verify lives at scripts/harvests/eqlwiki/slows-report.md — the landing lines are wiki-verbatim, and any that differ from a real log are exactly what we want to hear about.

[Frankthetankk]

First field report on the slow alert (#94) — good news, it's working as designed.

Chip + tooltip screenshot attached: landed a shared-line slow ("You feel drowsy.") and the chip correctly showed the full candidate list (Drowsy, Tagar's Insects, Tigir's Insects, Togor's Insects, Turgur's Insects, Walking Sleep), the honest 23–75% range, 3–16 disease counters, and cure guidance ranked strongest-first (Abolish Disease 36/cast, Word of Restoration 9/cast, Counteract Disease 8/cast). Landed at 4:06:54 PM, matched cleanly.

Options screenshot also attached for reference — I have the master toggle and spoken alert on, raid-only off, which is why it fired outside a raid context.

No issues to report yet — first sample lines up exactly with the shared-landing-line group in the catalog. Will keep testing and report back if I hit a mismatch, a mistagged spell, or anything that looks off (per the "landing lines are wiki-verbatim, field reports welcome" note in slows-report.md).

A few suggestions after using the chips for a bit, though — the countdown + progress bar is great, but a few things could make it more useful at a glance:

1. Anchor point for the slow alert banner

The alert banner feature already lets you drag it to choose where alerts appear when Options is open. Could a similar anchor be added for the slow chip stack specifically?

Alternatively — and this might honestly be the simpler/cleaner option — consider just combining the slow alert into the same banner/anchor as the existing alert system, rather than giving it its own separate anchor point. One combined location might read as less cluttered than tracking multiple anchor points on screen.

If both options have merit depending on playstyle, maybe a toggle to choose "separate anchors" vs. "combined" would cover both cases without forcing one approach on everyone.

2. Show the counter type (disease/poison/magic/etc.) on the chip itself, not just on hover

The countdown timer + progress bar on the slow chips look great. The one thing missing is knowing at a glance what TYPE of slow it is (disease, poison, magic, curse, etc.) without having to hover for the tooltip — in the middle of a fight, hovering to check isn't always practical.

Suggestion: an icon on the chip indicating the counter type, distinct enough to tell apart quickly — different colors and/or short text labels per type, so a disease slow and a poison slow are visually distinguishable without reading anything.

3. Show the counter count on the chip itself

Similar to no.2 — if possible, show how many counters the debuff currently carries directly on the chip (not just in the hover tooltip), so both the type and count are visible without needing to mouse over mid-fight.

These are all about surfacing on the chip what's currently hover-only info, since checking a tooltip isn't always convenient when things are moving fast.

[Frankthetankk]

Follow-up on the slow alert chips, after more testing.

Retracting part of my earlier anchor suggestion — having them anchored/movable is actually great. I repositioned mine closer to the middle of the screen so I notice them right away, and that's working well.

The problem: there's currently no way to move/reposition the slow chip anchor until you're actually slowed. Since the chip window only exists while a slow is active, there's no way to drag it into position ahead of time — you have to wait until you get hit with a slow in the middle of a fight, try to reposition it then (not exactly convenient mid-combat), or eat a first slow with the chip wherever it defaults to before you can move it.

Suggested fix: let the anchor be positioned regardless of whether a slow is currently active — either by keeping a persistent (even if invisible/inactive) anchor point that can be dragged anytime from Options, similar to how the alert banner anchor works, or by showing a placeholder/preview chip when repositioning from Options so there's something to grab and drag before ever getting slowed in game.

---

EQBuddy 1.70.0 · Windows 19045

[DranakCorps-bot]

Both remaining asks are built — coming in the next update. And thank you for the retraction note as much as the report; "the anchor idea was wrong, keep it movable" saved us from building the wrong thing.

1. Park the stack before you're ever slowed: while Options is open, an empty chip stack now shows a single draggable placeholder chip ("drag me — chips appear here") — same idea as the alert banner's placement mode. Drag it mid-screen where you noticed chips work best; it vanishes when Options closes, and real 💤/🐌 chips stack exactly there. No more eating a first slow to earn the right to reposition.

2 & 3. Type and count on the chip face: chips now read like 🐌 Slowed 40% · disease 12 — counter type and count visible at a glance, no hover. Shared landing lines show the honest range (disease 6–16), and counterless bard-song slows stay plain rather than inventing a number. One honest limit: the count is the initial counter load from the catalog — cures already applied aren't tracked yet (that's the Phase 2 "rank cures by observed casts" territory), so a half-cured debuff still shows its landing count. Text labels first; if they don't read fast enough mid-fight, color-coding per counter type is the next iteration — tell us how it feels in practice.

Your working-as-designed field report on the catalog matching (candidate list, range, cure ranking) is also exactly the verification the slows-report asked for — noted with thanks.

[DranakCorps-bot]

Now live in v1.72.0: slow chips show type and count ("Slowed 40% - disease 12"), and an empty chip stack becomes a draggable placeholder while Options is open so you can park it before anything is live. Thanks again Frankthetankk.

[Frankthetankk]

Feature request: add an icon in front of the counter type (Poison, Disease, Curse, etc.) shown on slow/debuff chips

Looked into SlowSpells.json and noticed the catalog already tracks counterType per spell — Shiftless Deeds, for example, is correctly tagged:

{
"name": "Shiftless Deeds",
"pctMin": 49,
"pctMax": 65,
"counterType": "Disease",
"counterMin": 12,
"counterMax": 12,
"durationSeconds": 150.0
}

And the cures section separates the cure spells by the same categories (Curse, Disease, Poison), each with its own dedicated spell line and classes that can cast it.

Since this data already exists, would it be possible to show a small icon in front of the counter type word on a slow/debuff chip — not replacing the word, just adding a visual alongside it? Being able to glance at the chip and immediately spot the icon for "this needs Cure Disease, not Cure Poison" would help react faster mid-fight, while keeping the text label for clarity. Since the underlying data is already sitting in the catalog, this looks like it might mostly be a UI/display task rather than needing new data collection.

---

EQBuddy v1.86.0

[DranakCorps-bot]

You're right that the data is already there — counterType is populated per spell in SlowSpells.json, and the cure section is already split by the same three categories, so nothing needs harvesting for this.

The reason it's worth doing is space, which is the part I'd want to get right rather than fast. A slow chip lives on the overlay, and the overlay's whole job is to be small enough to ignore while you're playing. "Slowed 40% - disease 12" is already close to as much text as a chip can carry without becoming something you have to read rather than glance at. Swapping the word for a glyph buys back roughly seven characters on the most crowded line EQBuddy draws, so it makes the chip better, not just prettier — that's a real argument for it rather than a cosmetic one.

Two things I'd want to settle before building it:

Which glyphs. They have to survive at chip size, in both themes, and — the constraint that has bitten us before — under Wine and CrossOver, where font coverage is not the same as on Windows. We've already shipped one fix for missing glyph boxes in a Wine prefix. An icon that renders as a hollow rectangle for the Linux and macOS players is worse than the word it replaced, so whatever we pick needs to be checked there rather than assumed.

Whether the word survives anywhere. My instinct is the icon replaces the word on the chip, and the full text stays in the breakout and the tooltip — so the glance is compact and the detail is still one hover away for anyone who hasn't learned the icons yet. A player who can't remember whether a symbol means disease or poison is worse off than one reading a slightly longer chip.

If you have a preference on the glyphs, say — you've been right about the scoping on every one of these so far, and you're the one who'll be reading them mid-fight.

[Frankthetankk]

On the two things you flagged:

Glyphs, in general: rather than picking specific Unicode symbols, I'd lean toward whatever fits into the same custom-drawn vector icon system EQBuddy already uses elsewhere (card headings in 1.92.0, quest markers in 1.89.0/1.91.0) — built for exactly this reason, since Wine's font coverage bit those before. Extending that same bundled set (and the build-time test that guards it) seems like the safer path than introducing a new Unicode glyph and hoping it renders everywhere. I don't have a strong opinion on the actual shapes/colors themselves — that's design work you're better positioned to call than I am.

Whether the text survives: I'd actually prefer the icon sit alongside the text on the chip itself, not replace it — icon to the left of the label:

<icon> Disease

Rather than the icon swapping in for the word. I get the character-budget argument, but I think there's a real upside to keeping both together on the same surface rather than moving the word to a hover-only tooltip: dual-coding (icon + text together) tends to be more reliable to read correctly at a glance than an icon alone, especially before a player's fully memorized what each glyph means. If someone hasn't learned the icons yet, an icon-only chip means a wrong guess mid-fight instead of just glancing slightly longer at a word — and once someone HAS learned the icons, having the word right next to it costs almost nothing to just not read. Happy to be wrong here if the space savings turns out to matter more in practice than I'm expecting, but that's my preference given the choice.

[DranakCorps-bot]

Both of your calls are the right ones, and they're recorded as the shape this takes when it gets built:

• The bundled vector set, not Unicode. You've named the exact reason the icon system exists — Wine's font coverage already bit the card headings and quest markers, which is why every icon EQBuddy draws is a shipped vector with a build-time test guarding the set. A new slow-type glyph joins that set or it doesn't ship. Shapes and colors stay our problem, as you say.
• Icon beside the text, not replacing it. Agreed, and for a sharper reason than preference: the number and the counter count are the actionable part ("disease 12" tells you how many cure casts), and an icon alone can't carry a number. The icon buys glanceability for which kind of slow; the text keeps the how much.

Not started yet — being straight about that. When the slow-chip work happens, this thread is the spec for the icon half.

— Dranak (Claude Code)