<img width="1274" height="952" alt="druids"
src="https://github.com/user-attachments/assets/7390d7e5-ed99-4eb3-8802-8c2f457d7c86"
/>
Hello playerbots community!! After my pvp gear update, I was itching to
get back to class strategies. I was testing raids, and noticed that
druids... Well, they kinda sucked.
They had glaring issues, would randomly die from bugs, and overall felt
bad. Looking at issues discussed on github/discord, I decided to start
working on a druid update. I started with the boomkin, and made a
boomkin PR, but there were some technical issues with the storing of the
eclipse mapping not clearing, and it was not good...
I closed that PR, and went back to the drawing board, with one goal in
mind: Make the druid class function as best as possible WHILST keeping
the code consistent with what already exists. There is a TON of _yoink
and twist_ (copy and paste with or without slight edits), and anything
that is custom/new is discussed in the section below. I am very proud
and excited to release this though - after 45 days of coding and
testing, the druid finally feels good to have in the group.
Disclaimer - this PR aims to address bugs, utility, and overall
performance of Druids. It will not magically make them top DPS. I have
done hours of testing, and druids can occasionally top the charts - but
inconsistently. Boomkins are inconsistent due to Eclipse (until later
gear phases), and Feral Cats are incredibly dependent on positioning,
timing, combo points, energy, clearcasting procs... The stars have to
align for things to go right for the Cat (It doesn't help that all
movement, targeting, and actions are ran through the same engine, so
cats really suffer in boss fights with scripted movement) But the
changes I have made help those situations occur a fair bit more
frequently. Let's dive in!
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
A druid overhaul across all four specs — new Cat stealth and CC systems,
Eclipse tracking and rotation fixes for Balance, a Bear threat rotation
rework, a Resto healing priority overhaul, and a restructured CC and AoE
strategy architecture.
---
## Talent & Glyph Config
- **Balance:** Moved points out of Improved Moonfire and into Nature's
Reach for threat reduction and extended cast range.
- **Bear:** Moved points out of King of the Jungle (15% enrage damage)
and into Feral Instinct for increased Swipe damage and AoE threat.
- **Cat:** Swapped the Glyph of Typhoon (useless for feral) for Glyph of
Dash, which benefits the cat a ton in prowl.
- **Resto:** Swapped Glyph of Rejuvenation for Glyph of Nourish (better
HPS for difficult content), and Glyph of Typhoon (useless for resto) for
Glyph of Dash. Moved one point from Nature's Bounty to Empowered Touch.
---
## Balance
- **New skill - Typhoon:** Added Typhoon, triggered by "enemy within
melee," using cone targeting logic ported from Cone of Cold. Typhoon is
from the "balance pvp" spec only, and is housed in the shared AoE
strategy.
- **New skill - Cyclone:** Added Cyclone targeting the RTI CC-marked
target (default moon). Incapacitates for 6 seconds with full damage
immunity — cannot be broken by AoE. Priority 24.0f > Hibernate (23.0f) >
Entangling Roots (22.0f). *(See CC Implementation in the code notes
below.)*
- **Bug fix - Eclipse cooldown tracking:** Eclipse procs referenced a
cooldown not registered in the database, so boomkins immediately
reverted to the wrong filler after an Eclipse buff fell off. Fixed with
manual timestamp tracking. *(See Eclipse Cooldown Tracking in the code
notes below.)*
- **Bug fix — Starfall no longer pulls out-of-combat hostile enemies:**
Previously fired on cooldown regardless of surroundings — its 36-yard
radius (the largest AoE in the game) could silently pull entire
unengaged packs. Now suppressed if any non-combat hostile NPC is within
40 yards. *(See Starfall Pull Safety in the code notes below.)*
- **Filler changed to Starfire:** Starfire is now the filler (priority
5.4) over Wrath (5.3). Starfire has a 100% spellpower coefficient vs.
Wrath's 12%, is more mana-efficient per point of damage, and has a 100%
eclipse proc chance on crit vs. Wrath's 40%. In practice this
significantly reduced mana consumption, especially before level 40 when
Moonkin Form's mana-on-crit passive isn't available.
- **Moonfire / Insect Swarm on Attacker rework:** Previously tied to the
light AoE trigger (2+ enemies, 13.0f), causing low-level boomkins to
multi-dot instead of casting fillers — mana-inefficient at low levels
where targets rarely live long enough to tick the full DoT. Re-added as
dedicated on-attacker triggers at lower priority than the fillers, so
they fire only as a movement fallback. The triggers have been changed to
override the TTL check (time to life), similar to the warlocks DoTs.
- **Hurricane channel check rework:** Previously cancelled based on
distance from the bot — enemies could leave the AoE but remain within 30
yards, keeping the channel alive. Now reads the Hurricane
DynamicObject's actual radius and counts only attackers physically
inside it. *(See Hurricane Channel Cancel in the code notes below.)*
---
## Cat
- **Prowl (Stealth):** Implemented using the same logic as the existing
Rogue stealth system. The bot enters Prowl when out of combat and a
target is within range. Engagement distances are:
- 30 yards baseline
- −10 yards if the target already has a victim (engaged in combat)
- −10 more yards if the target is also moving (minimum 10 yards)
- +15 yards in Battlegrounds or Arenas
- Enemy player targets take priority over grind/DPS targets when
evaluating distance.
- **Prowl openers:** The bot approaches the target in Prowl and opens
based on approach angle and level:
- **From behind:** Ravage (learned at level 32). Before Ravage is
learned, Shred is used as the opener.
- **From the front:** Pounce (stun + bleed, learned at level 36). Before
Pounce is learned, Claw is used as the opener.
- **New skill - Maim:** Added Maim as a 5 second stun-finisher at 5
combo points, but only against player targets. It will only fire when
Rip and Savage Roar are already active.
- **Innervate on healer:** Cats now cast Innervate when a healer drops
below the low mana threshold (`AiPlayerbot.LowMana`, default 15%). *(See
Healer Low Mana Framework in the code notes below for the shared
value/trigger infrastructure backing this.)*
- **Predator's Swiftness with CC spells:** Added a twotrigger pairing
Predator's Swiftness (the instant-cast proc from finishing moves) with
the existing CC triggers (Cyclone, Hibernate, Entangling Roots). Feral
cats can now instant-cast CC the RTI CC-marked target (default moon)
after a finisher using the Predator's Swiftness proc.
- **Predator's Swiftness with Rebirth:** Added a twotrigger pairing
Predator's Swiftness with the combat resurrection trigger. Cats can now
use a Predator's Swiftness proc to instantly cast Rebirth on a dead
party member.
- **Bug fix - Autoattack no longer breaks prowl:**
`MeleeAction::isUseful()` now returns false while the bot has the Prowl
aura, preventing autoattack from breaking stealth before an opener spell
fires. The code comment notes this pattern should be reused for a future
Rogue autoattack in stealth fix.
- **Bug fix - Non-prowl skills no longer break prowl:** `isUseful()`
overrides were added to Feral Charge (Cat), Mangle (Cat), Swipe (Cat),
Rake to return false while Prowl is active, preventing accidental prowl
breaks before the opener fires.
- **Bug fix - Clearcasting proc with energy spells:** Added dedicated
`ClearcastingTrigger` / action pairings to ensure Clearcasting procs are
consumed immediately. On single target, Shred is used; on AoE, Swipe
(Cat) is used. This prevents the cat from using it's valuable
clearcasting proc on a low energy spell (rake, feral charge - cat,
cower, etc). This also fixes a bug where Clearcasting would sometimes
linger for 4+ seconds without being used, as energy-based spells do not
recognize the free cast and would not fire until their energy condition
was met.
- **Tiger's Fury rework:** TF previously fired on cooldown as a default
action, meaning the bot would use it at full or near-full energy and
gain no benefit from the energy it generates. The trigger now requires
energy to be below 30 before firing, ensuring the bot recovers the full
60 energy granted by the King of the Jungle talent.
- **Faerie Fire (Feral) rework for cat:** With Omen of Clarity, spams on
cooldown to fish for Clearcasting procs. Without it, applies as a normal
debuff and does not reapply while active. *(See Faerie Fire (Feral)
Trigger in the code notes below.)*
- **Feral Charge toggleable strategy:** Feral Charge (Cat) is now housed
in a dedicated `feral charge` strategy, enabled by default for Cat
druids. It can be disabled with `co -feral charge` and re-enabled with
`co +feral charge`. Disabling this strategy can be useful for encounters
where charging in would be unfavorable.
- **Rake on Melee Attackers removed:** The Rake on Melee Attackers
action was removed from the Cat AoE strategy. Applying Rake to multiple
attackers and spreading out combo points produced far lower AoE DPS than
simply continuing the single-target rotation.
- **Antiquated Omen of Clarity framework removed:**
`OmenOfClarityTrigger` and `CastOmenOfClarityAction` were not functional
and have been removed. The `ClearcastingTrigger` appropriately tracks
Omen of Clarity procs. I believe this was from TBC when Omen of Clarity
was a spell.
---
## Bear
- **Berserk tracking for Mangle:** A `berserk active` trigger fires
Mangle (Bear) at priority 25.0f while Berserk is up. Previously, Mangle
sat at 5.5f in the default actions while Swipe (Bear) sat at 25.0f on
the light AoE trigger — meaning in any 2+ enemy encounter, Swipe would
always win regardless of Berserk. Now Mangle (25.0f) sits above the AoE
triggers (24.5f), so it takes priority during Berserk. It's pretty cool
to see a Bear's dps on pull!
- **Faerie Fire (Feral) rework:** Previously applied once and stopped.
Now spams on cooldown for continuous threat generation (~3.5k threat per
cast at level 80), and serves as a ranged soft-taunt fallback on the
`lose aggro` trigger when Growl is on cooldown. *(See Faerie Fire
(Feral) Trigger in the code notes below.)*
- **Lacerate rework:** Previously, lacerate was a low priority default
action and bears had no duration awareness. They would occasionally let
5 stacks of Lacerate fall off, resulting in pretty significant threat
loss. Now, `LacerateTrigger` fires when the target has no Lacerate
debuff, the stack count is below 5, or the remaining duration is ≤ 6
seconds.
- **Demoralizing Roar on single target:** Previously, Demoralizing Roar
only fired on the medium AoE trigger (3+ enemies, skipped on bosses). A
dedicated trigger now applies it in any encounter, provided Vindication,
Demoralizing Shout, or Curse of Weakness are not already present, as
they don't stack with Demoralizing Roar.
- **Bug fix - Rebirth on bears:** Bears no longer attempt to cast
Rebirth in combat. The generic combat resurrection trigger was firing
for all druid specs, causing bears to shift out of Dire Bear Form
mid-fight to cast Rebirth — dropping their armor and HP while still
holding aggro. Lots of sudden tank deaths...
- **Feral Charge toggleable strategy:** Feral Charge (Bear) is now
housed in a dedicated `feral charge` strategy, enabled by default for
Bear druids. It can be disabled with `co -feral charge` and re-enabled
with `co +feral charge`. Disabling this strategy can be useful for
encounters where charging in would be unfavorable.
---
## Resto
- **Blanketing strategy:** Added a `blanketing` strategy (enabled by
default, `co -blanketing` to disable) that pre-HoTs group members with
Wild Growth and Rejuvenation regardless of current health, prioritizing
tanks → melee → ranged to maximize Revitalize uptime. *(See Blanketing
Strategy in the code notes below.)*
- **Nature's Swiftness → instant Healing Touch combo:** Nature's
Swiftness was previously included in the boost strategy, where it would
fire proactively on cooldown regardless of context. This wasted the proc
on situations where it provided no benefit. It is now exclusively
reactive — triggered at high priority (56.0f) when a party member hits
critical health. A paired `nature's swiftness active` trigger then
immediately fires Healing Touch (55.0f) on the lowest-health party
member, consuming the proc as an instant-cast emergency heal.
- **Lifebloom priority lowered (29.0f → 13.0f):** Lifebloom on the main
tank is cast on Omen of Clarity procs. At 29.0f it previously
outprioritised all low health reactive healing (21.4f), meaning a
Clearcasting proc while a party member was at 25–44% HP would cause the
bot to cast Lifebloom on the tank instead of Swiftmend or Nourish on the
injured target. Lowered to 13.0f so it fires only when no reactive
healing is queued.
- **Healing spell priority order reworked:** All three reactive
categories (critical, low, medium) now follow the same sequence:
Swiftmend → Wild Growth → Nourish → Regrowth → Healing Touch.
- **Tranquility toggleable strategy:** Tranquility is now housed in a
dedicated `tranquility` strategy, enabled by default for Resto druids.
It can be disabled with `co -tranquility`. In raids, Tranquility only
heals the druid's own group — not the full raid — making it
situationally poor during raid-wide damage or heavy movement phases.
Disabling this strategy lets players suppress the cast on those
encounters without affecting the rest of the healing rotation.
---
## CC & Strategy
- **Boost strategy:** The boost strategy is assigned to all druid specs
by default. It is spec-gated internally — Balance druids use it for
Force of Nature (treants on cooldown), and Feral druids (both cat and
bear) use it for Berserk.
- **CC strategy enabled by default:** The CC strategy was previously not
assigned to druids by default. It is now enabled for Balance and Feral
Cat, with behavior gated by spec:
- Balance receives the full RTI CC trigger set (Cyclone, Hibernate,
Entangling Roots).
- Feral cats only receive RTI CC triggers when Predator's Swiftness is
active (see above).
- **AoE strategy reorganized:** All AoE spells — Hurricane, Starfall,
Typhoon, Swipe (Cat), and DoTs on attackers (Moonfire, Insect Swarm) —
are now handled by the shared AoE strategy, consistent with how the rest
of the playerbot project structures AoE logic. This does not affect Bear
druids.
- **Aquatic Form while submerged:** The non-combat strategy now shifts
into Aquatic Form when the bot is fully submerged out of combat
(`LIQUID_MAP_UNDER_WATER`). If the bot is in another shapeshift (Bear,
Cat, Moonkin, Tree), it first shifts to caster form as a prerequisite
before entering Aquatic Form. The trigger intentionally does not fire at
the water surface (`LIQUID_MAP_IN_WATER`), or use the "swimming"
trigger, because it caused the druid to loop caster form and aquatic
form endlessly while surfaced.
---
## Code Consolidation & Refactoring
- The Bear, Cat, Heal, and Caster strategy files have been renamed to
Bear, Cat, Balance, and Resto respectively, to match the naming
conventions used elsewhere in the project.
- The Melee and Offheal strategy files have been deleted. The offheal
healing logic is preserved in full — it now lives as an optional
strategy (`CatOffhealStrategy`) inside `CatDruidStrategy`, sharing the
same action node factories as the base cat strategy rather than
duplicating them.
- All action relevance values across the druid strategies have been
converted from named constants (e.g. `ACTION_NORMAL`, `ACTION_HIGH + 4`)
to explicit numerical floats (e.g. `10.0f`, `24.0f`). This makes
priority ordering immediately visible in the source without needing to
cross-reference the constant definitions.
---
## New Code & Project References
### Eclipse Cooldown Tracking (`DruidActions.cpp`)
The previous implementation tracked the Eclipse cooldown using
`EclipseSolarCooldownTrigger` and `EclipseLunarCooldownTrigger`, both of
which extended `SpellCooldownTrigger` and called
`bot->HasSpellCooldown(48517/48518)`. `SpellCooldownTrigger` is the
standard project pattern for this — it works correctly for spells whose
cooldowns are registered in the database. However, Eclipse (Solar) and
Eclipse (Lunar) both have **Cooldown: n/a** in the DB.
`HasSpellCooldown` always returned false, so boomkins never respected
the cooldown and would revert to the wrong filler immediately after an
Eclipse buff fell off.
Since the cooldown can't be read from the DB, the fix tracks it
manually. When `CastWrathAction::isUseful()` or
`CastStarfireAction::isUseful()` detects that the corresponding Eclipse
aura has become active, it records the current timestamp and suppresses
the opposing filler for 30 seconds — the actual in-game cooldown
duration.
The timestamps are stored using `ManualSetValue<time_t>`, the same
pattern as `LastSpellCastTimeValue`
(`src/Ai/Base/Value/LastSpellCastTimeValue.h`), which is already used
throughout the project to record when spells were last cast. Two new
value classes — `EclipseSolarProcTimeValue` and
`EclipseLunarProcTimeValue` — are registered in a new
`DruidValueContextInternal` factory inside `DruidAiObjectContext.cpp`,
following the same factory pattern as `DruidTriggerFactoryInternal` and
`DruidAiObjectContextInternal` in the same file. Because these values
live in the per-bot `AiObjectContext`, they are automatically destroyed
when the bot logs out — no manual cleanup needed, and no shared state
between bots.
---
### Healer Low Mana Framework (`PartyMemberToHeal.h/.cpp`,
`HealthTriggers.h/.cpp`, `ValueContext.h`, `TriggerContext.h`)
`HealerLowMana` and `HealerLowManaTrigger` are added to the shared base
framework rather than the druid-specific code. Currently used by the Cat
Innervate trigger; designed so Mana Tide Totem, Hymn of Hope, and
similar spells from other classes can hook into the same trigger without
duplicating the group-scanning logic.
The pair follows the same pattern as the existing `PartyMemberToHeal` /
`PartyMemberLowHealthTrigger` — the project's standard design for "scan
the group for the most in-need member, then trigger when that member
crosses a threshold."
**Value** (`HealerLowMana : PartyMemberValue`): `Calculate()` walks the
group reference list, skips non-healers via the existing `IsHeal()`
check, and uses `MinValueCalculator` to return the lowest-mana healer as
a `Unit*`. Registered in `ValueContext.h` under the key `"healer low
mana"`.
**Trigger** (`HealerLowManaTrigger : Trigger`): `GetTargetName()`
returns `"healer low mana"`, which the base `Trigger::GetTarget()`
resolves against the value context — exactly how
`PartyMemberLowHealthTrigger::GetTargetName()` returns `"party member to
heal"`. `IsActive()` calls `GetTarget()` and checks
`GetPowerPct(POWER_MANA) < sPlayerbotAIConfig.lowMana`.
The trigger doesn't extend `HealthInRangeTrigger` because that class is
specifically for health (it reads the `"health"` value). Mana requires a
direct `GetPowerPct(POWER_MANA)` call, so a plain `Trigger` with a
custom `IsActive()` is used instead.
Both are registered in the global `ValueContext.h` and
`TriggerContext.h` rather than a class-specific factory, consistent with
how all other `PartyMemberValue` subclasses are registered in the
project.
---
### Blanketing Strategy (`RestoDruidStrategy.h/.cpp`,
`DruidActions.h/.cpp`, `DruidAiObjectContext.cpp`)
**Strategy structure:** `DruidBlanketStrategy` is a standalone
`Strategy` overlay, not embedded inside `RestoDruidStrategy`. This is
the same pattern as `DruidTranquilityStrategy`, `DruidBoostStrategy`,
and `DruidCcStrategy` — additive overlays that layer behavior on top of
the base strategy and can be toggled independently via `co
+/-blanketing`.
**Triggers:** Both `"wild growth blanket"` and `"rejuvenation blanket"`
are instantiated as `BuffOnPartyTrigger(ai, spellName)` — the project's
existing class from `GenericTriggers.h` for party-wide buff maintenance,
used throughout the codebase for things like Blessings and Mark of the
Wild. `BuffOnPartyTrigger` extends `BuffTrigger` and fires when any
party member is missing the named aura. No custom trigger class was
needed.
**Actions:** Both actions inherit from a shared `CastBlanketHotAction`
base that itself extends `CastSpellAction`. Inheriting from
`CastSpellAction` means `isPossible()` is handled for free — spell
known, off cooldown, target reachable, resources available. The
constructor sets `range = botAI->GetRange("heal")` to use the standard
healing range.
**`GetBlanketTarget(auraName)`:** The custom part of the implementation.
Walks the group in three prioritized passes — tanks first, then melee
non-tanks, then ranged — returning the first eligible member found.
Eligible is defined as: alive, not a GM, within `spellDistance`, and
`!botAI->HasAura(auraName, member, false, true)` (not already carrying
the HoT). Returns nullptr if every member is already covered.
**`isUseful()`:** On both actions simply returns `GetTarget() !=
nullptr` — fires as long as `GetBlanketTarget` finds someone without the
HoT, and suppresses itself the moment all targets are covered.
---
### CC Implementation — Cyclone, Hibernate, Entangling Roots
(`DruidTriggers.h/.cpp`, `DruidActions.h/.cpp`,
`GenericDruidStrategy.cpp`)
The druid CC spells use the project's strict RTI-only pattern rather
than the fallback "best candidate" pattern used by other classes (e.g.,
Mage Polymorph).
**`"rti cc target"` value:** A direct raid icon lookup. Reads the `"rti
cc"` string value (default `"moon"`, configurable per-bot via `rti cc
<icon>`), converts it to a raid icon index, and returns the live `Unit*`
for that GUID. If no CC icon is set, it returns `nullptr`. There is no
fallback to a best-candidate scan.
**Triggers** (`CycloneTrigger`, `HibernateTrigger`,
`EntanglingRootsTrigger`): All three extend `HasCcTargetTrigger` and
override `IsActive()`. The first check is always `"rti cc target"` — if
it returns `nullptr`, the trigger is immediately silent. If an icon is
set, it checks `"cc target"` (with the spell name as a qualifier) to
verify the RTI target matches and delegates to
`HasCcTargetTrigger::IsActive()`, which handles the "don't re-cast while
already CC'd" check.
**Actions** (`CastCycloneCcAction`, `CastHibernateCcAction`,
`CastEntanglingRootsCcAction`): All three extend
`CastCrowdControlSpellAction` rather than plain `CastSpellAction`. The
action names are `"cyclone on cc"`, `"hibernate on cc"`, `"entangling
roots on cc"` — not the raw spell names. This matters because
`CastSpellAction` stores its constructor argument as both the action
name and the spell name, and `isPossible()` calls `CanCastSpell(spell,
target)` using that string. Passing `"cyclone on cc"` to
`CastSpellAction` would resolve to spell ID 0 and silently return false
forever. `CastCrowdControlSpellAction` keeps the spell name separate
from the action name, avoiding this. `GetTargetValue()` on all three
returns `context->GetValue<Unit*>("rti cc target")` directly.
**Form prerequisite:** The action nodes for `"cyclone on cc"` and
`"hibernate on cc"` have `NextAction("caster form")` as a prerequisite,
so the bot automatically shifts out of Bear, Cat, or Moonkin form before
casting. Entangling Roots has the same prerequisite.
**Priority order:** Cyclone (24.0f) > Hibernate (23.0f) > Entangling
Roots (22.0f). Cyclone is preferred because it works on any target type
and the target is immune to all damage and healing while cycloned — it
cannot be broken by AoE. Hibernate is beast/dragonkin only. Entangling
Roots can be broken by damage.
**Feral Cat CC:** Wired through `TwoTrigger` pairings with `"predator's
swiftness"` (see Cat section above). Because the Predator's Swiftness
proc makes the spell instant-cast, no form shift is needed — the cat
casts directly from Cat Form after a finisher.
---
### Ferocious Bite Execute (`DruidTriggers.h`, `DruidCatActions.h`,
`CatDruidStrategy.cpp`)
Two separate triggers fire the same `CastFerociousBiteAction`, which is
a plain `CastMeleeSpellAction` with no custom logic — all the
intelligence lives in the triggers.
**`FerociousBiteTimeTrigger`** ("ferocious bite time", 22.5f) — the
normal rotation path. Requires 5 combo points, Savage Roar active with
>10 seconds remaining, and Rip active on the target with >10 seconds
remaining. The duration checks prevent spending combo points on
Ferocious Bite when either buff is about to fall off and needs to be
refreshed first.
**`FerociousBiteExecuteTrigger`** ("ferocious bite execute", 24.0f) —
the execute window, higher priority than the time trigger. Requires only
1 combo point, and fires when the target is below **both** 25% HP and
20,000 absolute HP. The dual condition is the key design detail: the 25%
threshold alone would trigger on a raid boss at 25% health — which could
still be millions of HP remaining. The 20,000 HP cap ensures the execute
behavior only activates when the target is genuinely close to death, at
which point dumping even a partial combo point buildup into Ferocious
Bite is better than continuing a normal builder-spender cycle.
---
### Faerie Fire (Feral) Trigger (`DruidTriggers.h`)
A single `FaerieFireFeralTrigger` class handles both Bear and Cat with
spec-branched behavior inside `IsActive()`. It extends `DebuffTrigger` —
the project's standard class for debuff maintenance on the current
target — but overrides `IsActive()` to produce three distinct behaviors
depending on form and talent state:
**Bear:** Bypasses `DebuffTrigger::IsActive()` entirely. Returns true
whenever the target is alive and in world, regardless of whether the
debuff is already present. Every cast generates immediate threat and
damage, so there is no reason to wait for it to fall off before
recasting.
**Cat with Omen of Clarity (talent aura 16864):** Same bypass — spams on
cooldown to fish for Clearcasting procs. Faerie Fire (Feral) has no
energy cost, making it a free input that can proc Omen of Clarity on any
hit.
**Cat without Omen of Clarity:** Falls through to
`DebuffTrigger::IsActive()` — the standard base class behavior, which
checks: target alive and in world, debuff not already present
(`!botAI->HasAura("faerie fire (feral)", target)`), and estimated
remaining lifetime of the target is at least `needLifeTime` seconds
(default 8.0f — no point applying a 30-second debuff to something about
to die). Applied as a normal debuff; does not reapply while active.
Both spam paths additionally guard against Prowl — `IsActive()` returns
false while the bot has the Prowl aura to prevent casting from breaking
stealth.
**Strategy wiring:**
- Bear: standard rotation slot at 17.0f, plus wired into the `"lose
aggro"` trigger at 25.5f as a soft-taunt fallback when Growl is on
cooldown.
- Cat: low-priority filler at 5.0f.
---
### Starfall Pull Safety (`DruidActions.cpp`)
Starfall's 36-yard AoE radius is the largest in the game. A single cast
near an unengaged patrol or mob pack would silently pull everything in
that area. The previous implementation fired on cooldown with no
awareness of the surrounding area.
`CastStarfallAction::isUseful()` now applies two guards before allowing
the cast:
**CC safety check** (standard project pattern): reads `"current cc
target"` and `"aoe position"`; suppresses the cast if the CC'd target is
within `aoeRadius` of the bot's AoE position.
**Unengaged hostile NPC scan (custom)**: reads `"nearest hostile npcs"`
(`NearestHostileNpcsValue`), which uses the project's standard
`Acore::AnyUnitInObjectRangeCheck` + `Cell::VisitObjects` grid searcher
at `sightDistance` (~50 yards). The value pre-filters via
`AcceptUnit()`: non-players only, and `unit->IsHostileTo(bot)` must be
true — this excludes neutral-faction trigger creatures, dummies, and
invisible spawns that would otherwise appear in a raw range scan. The
loop then applies four additional filters:
- Skip null / dead / out-of-world units (standard guard).
- Skip the current target — it is the reason we're in combat; its
in-combat flag is already covered.
- Skip `!bot->IsValidAttackTarget(unit)` — safety net for
hostile-faction trigger creatures carrying `UNIT_FLAG_NON_ATTACKABLE`
that `IsHostileTo` alone doesn't filter.
- Skip units beyond 40 yards — Starfall's listed radius is 36; 40 adds a
small buffer for patrols about to enter range.
If any remaining unit is `!unit->IsInCombat()`, the cast is suppressed —
that mob is unengaged and would be pulled.
**Why `"nearest hostile npcs"` and not `"attackers"`:** `attackers` only
contains units currently targeting the bot. We need to scan all hostile
units in the area, not just those already aggro'd.
---
### Hurricane Channel Cancel (`DruidTriggers.h/.cpp`,
`GenericDruidStrategy.cpp`)
The previous cancel condition checked whether fewer than 3 enemies were
within 30 yards of the bot. This is a poor proxy — enemies could scatter
laterally but still sit within that radius, keeping the channel alive
while none of them were taking damage.
The replacement is `HurricaneChannelCheckTrigger`, which locates the
actual Hurricane `DynamicObject` on the field and measures from it
directly.
**`IsActive()` logic:**
1. Checks `bot->GetCurrentSpell(CURRENT_CHANNELED_SPELL)` — if the bot
isn't channeling at all, returns false immediately. If it is channeling
but the spell isn't a Hurricane rank, also returns false. This check is
necessary because `CURRENT_CHANNELED_SPELL` is a slot, not a specific
spell — the same cancel action is reused for other channeled spells in
the codebase, so the trigger must verify it's specifically Hurricane
before acting.
2. Iterates through `HURRICANE_SPELL_IDS` (all five ranks: 16914, 17401,
17402, 27012, 48467) calling `bot->GetDynObject(spellId)` until a
non-null result is found. Hurricane places a `DynamicObject` on the
field that the server uses as the actual AoE cylinder — each damage tick
queries which units are inside it. The DynamicObject is keyed by spell
ID, so the trigger must try each rank to find whichever one the bot
currently has learned and placed.
3. Reads `dynObj->GetRadius()` — the actual radius stored on the
DynamicObject itself rather than a hardcoded constant. This matches
exactly what the server uses to calculate damage, so the trigger's
cancel condition is spatially identical to the server's hit detection.
4. Walks the `"attackers"` GuidVector and counts how many live attackers
are within `dynObj->GetRadius()` of the DynamicObject's position using
`unit->GetDistance(dynObj->GetPosition()) <= radius`.
5. Returns `count < minEnemies` (default 3). The trigger fires —
cancelling the channel — when fewer than 3 attackers are physically
inside the Hurricane AoE.
**Why `"attackers"` and not a full area scan:** Hurricane only deals
damage to units that are attacking the bot (or in its threat list).
Scanning all nearby hostile units would cause premature cancellation if
non-aggro'd enemies happened to be standing outside the AoE. Attackers
is the right scope.
**Strategy wiring:** The trigger is paired with `NextAction("cancel
channel", 22.0f)` in the AoE strategy for both Balance and Resto druids.
The cancel priority (22.0f) sits below the Hurricane cast priority
(23.0f), so if the medium AoE trigger re-activates on the same tick the
cancel fires — meaning enemies came back into range — the new cast wins
over the cancel.
---
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
Most new triggers are simple aura or cooldown checks. The heavier ones
are the group scans (for the blanketing HoTs and the healer mana check),
but these are identical in cost to group scans already running
throughout the project (all of the party member health checks). The
Starfall safety check is the only genuinely new scan — it looks for
nearby hostile NPCs before allowing a cast, using the same grid search
the project already uses elsewhere. That being said, it's loaded on the
end of the trigger/action pairing - so in the StarfallNoCDTrigger, the
bot has to already have learned starfall, already be in combat, and have
Starfall off of cooldown and ready to use. The Hurricane cancel check
only runs while the bot is actively channeling, so it's tightly gated.
- Describe the **processing cost** when this logic executes across many
bots.
Negligible for almost everything in this PR. The vast majority of new
logic is aura/buff/debuff lookups and cooldown checks that cost nothing
at scale. The group scans for blanketing and healer mana follow the same
pattern as existing party scans that already run on every healer bot
every tick. No new unbounded operations, no shared state between bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
All druids perform a bit better now - I'd say test the branch out with
the druids y'all currently use. JUST REMEMBER TO DO reset botAI or
talents spec "x" again, since there have been some strategies changed!!
The big one being the blanketing strategy for resto druids. They heal so
much better now. Also being able to control when they pre-hot is really
great.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
Tested before an after with the same performance logs. I tested it with
a 25 man group of only druids versus my normal 25 man group on several
raid bosses - no difference in pmon.
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
Druid bots currently have several bugs/issues with them. This doesn't
exactly change the skills they were already using - just refines the
scenarios in which they should be used. For example, a boomkin won't use
starfall when there is a pack within range but not aggro'd. You can turn
off feral charge for cat druids now, so they don't fly into a bosses aoe
(locust swarm on anub, overload on iron council). Bear druids don't
battle rez anymore. They just feel less clunky and heal/hold aggro
better.
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
There are only 2 changes to files outside of the druid strategy, which
is the healer low mana framework and the modification to autoattack not
being used while in prowl.
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
AI was used heavily in the process to make this PR. First in the
research necessary into how systems work, to the initial code
implementation, to the testing results (explaining the outcome/why it
sucks), to the fix, and then to the review of the code at the end. I
will say that after I started researching how to use AI, use .md files
for context, clearing sessions, I got a lot better results.
I'll be the first to admit that it is 10 times easier to introduce a bug
with AI than it is to solve one or implement something new. That is why
every time it proposed a change, I asked it if the code was consistent
with the project (Already present somewhere else) and if it wasn't, it
was heavily scrutinized.
It was written with Claude Code with Sonnet 4.6 (high), and peer
reviewed by Github copilot. AI also made the description part of the PR,
in which I modified myself.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
**Wiki commands**
@Dreathean
While this PR does add strategies, they are all enabled by default:
co +feral charge (feral druids, both cat and bear) - enabled by default,
allows/prevents the use of feral charge
co +tranquility (resto druids) - enabled by default, allows/prevents the
use of tranquility
co +blanketing (resto druids) - enabled by default, allows the druid to
pre-hot with wild growth and rejuvenation
But it would be worth a mention on the wiki - there are scenarios where
having these strategies disabled would be beneficial.
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
@kadeshar
@Celandriel
@brighton-chi
Thank you for taking the time to look this over. There is a lot of
copied code, a bit of new code (which is explained in the code
explanation part of it, but please still ask questions), and a lot of
refactoring. Please remember to reset the bot strategies before/after
you test this branch, due to the several changes (blanketing, feral
charge strategies). Reset with reset botAI or "talents spec balance pve"
for any testers out there that didn't know. If/When this PR goes to the
master branch, it will need to be noted to the people this same thing
about resetting strategies.
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Death Knights were not using weapon stones. This PR lets them use and
initialize with weapon stones.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
Create an rndbot DK. They should be init with weaponstones and use them
on their weapon.
Or give a weapon stone to an altbot. They should use it on their weapon.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Adds arcane barrage as the alternate for arcane blast so level 60 arcane
mages who dont have arcane blast yet will use arcane barrage whenever
available.
For level 60 arcane mages, its actually better dps to alternate between
arcane barrage and arcane missiles to fish for Missile Barrage procs.
Before:
<img width="576" height="403" alt="Screenshot_20260518_024601"
src="https://github.com/user-attachments/assets/567f198f-3655-4449-86e6-2cfffd19a529"
/>
After:
<img width="579" height="381" alt="Screenshot_20260518_025040"
src="https://github.com/user-attachments/assets/803f5380-58d3-490a-a3b1-e2941e2f0048"
/>
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
Have a level 60 arcane mage dps a dummy. To compare to the old
"rotation" of just using arcane missiles you can "ss Arcane Barrage"
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Replaced hardcoded bot text with translationable.
Related with: #1295
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
1. Invite bots
2. Check that text after "follow" and "stay" return texts "Following"
and "Staying"
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Summary hardcoded text and checking that they already exists to reuse.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Mages have a "bdps" strategy to use Molten Armor (default for Fire and
Arcane) and "bmana" strategy to use Mage Armor (default for Frost). The
existing code uses a series of alternatives for armor
(Molten->Mage->Ice->Frost), which is needed for Mages that have not
learned Molten or Mage. However, I was noticing that sometimes my Fire
and Arcane Mages would end up with Mage Armor, presumably because there
could be a situation in which the casting of Molten Armor failed and the
fallback to Mage Armor kicked in (for example, due to there being not
enough mana to cast Molten Armor). This PR makes bdps always mean Molten
Armor, if it is learned, and bmana always mean Mage Armor, if it is
learned, by gating through triggers.
Other changes:
- Added bdps and bmana to default Mage combat strategies (still bdps for
Fire and Arcane and bmana for Frost) so that Mages will reapply armor if
it expires in combat.
- Deleted Arcane Explosion strategy--it was not fully implemented
because there was no associated action (such as through a
CastArcaneExplosionAction class). I debated implementing it, but there
isn't a suitable targeting mechanism that exists in the code from what I
can tell. Arcane Mages generally just use Blizzard for AoE (and
Flamestrike with PoM); Arcane Explosion is useful to use if (1) a player
is moving or (2) mobs are almost dead in an AoE situation. Scenario (1)
is irrelevant for bots since they cannot cast while moving. With respect
to scenario (2), the existing AoE triggers in fact look for highest HP
mobs so to implement Arcane Explosion in a useful manner would probably
require a new Value, and that is not worth it for what would be
miniscule benefit anyway.
- General cleanups of Mage code (e.g., deleted empty ActionNodes). These
were based on a quick review; I did not do any sort of detailed or
comprehensive review and have no desire to with this PR. Note: I know
that FrostMageStrategy.cpp had a Fireball alternative for Frostfire
Bolt, but I deleted it anyway because the same ActionNode is already in
GenericMageStrategy.cpp.
- General cleanups of AiFactory default combat/noncombat strategies
(e.g., removal of deprecated bdps and bmana strategies for Shamans).
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
Added getAlternatives for the armor strategies; this approach already
exists for Druids. Added one new trigger for Molten Armor that is
throttled by 10s like the existing Mage Armor trigger.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
Give a Mage the "bdps" strategy. They should cast Molten Armor. Make
them cast a different armor. After the trigger throttle period (10s),
they should reapply Molten Armor. Same goes for bmana and Mage Armor.
Try this in combat, and it should work too.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
The point of this PR is to fix the default Mage armor buffing behavior.
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
I had GPT-5.4 present a couple of possibilities to fix the issue of Mage
Armor being cast with bdps, and from there I settled on the
getAlternatives approach. I did everything else.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
@Dreathean Perhaps the wiki can be updated to document the bdps and
bmana strategies for Mages?
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Back when I did the Stones/Oils PR, I gave Wizard Oil to Prot Paladins.
I was operating based on their mechanics in TBC and have since realized
that their damage is much more physical-based in WotLK as opposed to
spell-based in TBC. So I've changed them to now get stones upon
maintenance and apply stones.
I also reduced weapon oils given during maintenance from 4 to 2 stacks.
I did 4 originally because oils stack to 5 so it would align with the
amount given of stones and poisons (which stack to 20). But 4 inventory
slots taken up by oils is excessive, and 2 still last far longer than
buffing reagents in a raid context. So this is just to reduce inventory
clutter.
Other stuff is just little code stuff like reformatting or reordering
things to be more efficient.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
There's nothing new--essentially with respect to consumables, prot
paladins now are lumped with ret.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
Create a prot paladin, turn on selfbot. Use maintenance and the paladin
should be given stones and no oils. The paladin should then apply the
stone to its weapon (if it is equipping a level-eligible weapon).
Create a caster, turn on selfbot. Use maintenance and they should be
given 2 stacks of oils.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
Prot paladins will now use stones in their inventory and will not use
oils in their inventories. This is better for their mechanics.
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
