20260603#14
Merged
Badgermilk0 merged 13 commits intoJun 3, 2026
Merged
Conversation
<!--
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 -->
Implement RBAC Permission system in checks.
Claude flagged the following
PlayerbotMgr.cpp:751 <= SEC_PLAYER
SecurityCheckAction.cpp:27 == SEC_PLAYER
In these two cases a moderator level account has access to these
commands. This was preserved in PR. The question is whether mods should
maintain the override.
## 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.
-->
## 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.
-->
<!--
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.
-->
## Pull Request Description <!-- Describe what this change does and why it is needed --> Big thanks to @kadeshar for providing the bis list for many raids and ilvls :D Video demo for ICC 25HC: https://studio.youtube.com/video/nACyjn817iQ/edit Video demo for autogear bis chat command: https://www.youtube.com/watch?v=2YqyVBaSb2g split main IccActions.cpp into sperate per boss .cpp files changed style to be more aligned with https://www.azerothcore.org/wiki/cpp-code-standards (WIP) added bisicc chat command for bots to gear with ICC bis gear if autogear and bisicc is enabled in cfg https://gist.github.com/metal0/0bb094bf65d27e17044308ad0646cae1 bis list used LM Added multiple spike marking and focus for faster spike clearing, each spike will get its own kill group, tank spike will never get melee bots (only assist tank and ranged dps) Added coldflame detection so that melee bots dont go for spikes that are in flames During bonestorm assist tank will go far away spot so that once bonestorm is fixed, LM will bounce back and forth from MT to AT (atm it targets randomly, it should always pick furthest target) Coldflame avoidance is handled by avoid AOE, important to keep it on in cfg Tested on ALL diffs LDW Improved skull marking of adds, add handling by tanks and dps Changed 1st position for ranged bots for easier adds handling in HC and NM Improved tanking logic for tanks, assist tank will focus on collecting adds and bring them near boss Real players will also get cyclone aura when mind controlled Improved ranged position during 2nd phase, they should not get stuck in corners/walls anymore Tanks will remove LDW ToI aura in HC (really hard to tank with it since many things are happening at once) Added Cheat for LDW fight to help tanks with agro in 2nd phase of heroic modes Changed tank position in phase 2 closer to pillars opposed to stairs (bots love to fall thru floor and run thru walls if near them) this fixed the issue Fixed edge case for escaping from shades, it could happen that multiple shades would target bot, and it was running from 1st one he found, now it will run form all that are targeting it Hunters will cast viper sting now, to increase shield draining speed Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) In short cleared LDW without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. GS Changed triggers and actions to enable cross faction play Assist tank will now actually tank adds on friendly ship Dps will properly jump to attack mage and go back to their ship, if stuck on enemy ship /p reset, /p summon or /p follow fixed trigger for cannons, if cannons are frozen bots wont try to mount them anymore which prevented them from attacking mage properly bots will use rocket packs to jump to and from enemy ship instead of teleporting Main tank will now jump 1st. tank enemy boss and wait until all bots have jumped back before he jumps back All bots will wait for main tank to engage enemy captain before jumping to enemy ship Cannons will focus rockets 1st, then other adds now (for when gs gets scripted) Rdps will focus nearby adds on enemy ship and mark with star rti icon when there is no deep freeze todo: remove tanking bypass when core fixes enemy ship boss threat reseting Tested crossfaction on horde with single ally bot, ally bot did everything right, need to test more. note horde side is heavily bugged due to threat issue of adds, tanks cant take threat, on ally its somewhat ok, on horde rip. Horde is doable, but annoying cus of threat issue. Tested on ALL diffs DBS Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get rune of blood Tanks will tank adds better now, no loose adds anymore Tested on ALL diffs Dogs Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get 8 mortal wounds stacks Tanks will tank adds better now, no loose adds anymore Tested on ALL diffs Festergut Hunters sometimes populated row 0 which would make them in melee range of the boss (bad for dps). They should pick correct rows now Healers will populate row 0 1st then other rows for optimal healing position Ranged bots should properly choose unique spots to avoid stacking when there is no spore present Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get 6 gastric bloat stacks Changed ranged spore position closer to boss Spore bots should be able to attack/do non movement action when they have spore and are in position Solved malleable goo detection via direct boss hooks to detect boss targets! Tested on ALL diffs Rotface Tanks should not fight over big ooze anymore Improved big ooze kiting Improved small ooze stacking logic (when no big ooze present, stack at small ooze position, when big ooze is present move to it) Fixed edge cases when main and assist tank get small ooze (they used to move to big ooze, that was really bad since main tank would start to tank big ooze and get hit by big ooze, assist tank would stop kiting and get hit by big ooze) stopped mutated plague from dispelling instantly (as fight goes on, rotface cast mutated plague more and more, thus making it impossible to pass due to sheer numbers of small oozes and big oozes on the map, this will delay their spawning and give enough time for bots to handle them properly) Fixed edge case of multiple small oozes and big oozes being alive at same time (bots would detect wrong oozes and wipe raid or get stuck) Improved flood avoidance Improved ranged positioning in heroic mode, instead of letting them choose positions (which is a nightmare on dynamic fight as rotface, they now will choose 1 spot of 22 premade ones and populate them based on guid and adopt spot based on flood position) Improved Explosion avoidance by making bots remember their starting position so that they can return to it after big ooze explode, their movement is not chaotic anymore, and improved timers, they will wait 2 sec at new position before returning to starting position so that they can avoid explosion projectiles properly, they should also avoid moving to other bots starting positions. These changes ensure minimal movements so that bot can do maximum dps possible. Tested on ALL diffs PP Fixed many logic conflicts that caused bots to freeze, do bad dps to ooze/clouds Fixed triggers and multipliers Improved Gas Cloud avoidance, bloated bot will now remember its previous position to avoid backtracking/getting stuck in corners Added boss hooks to finally detect malleable goo, it is not an npc, object or creature and PP doesn't target anyone, bots will flee from it now Boss stacking now only in last phase Added cheats for players also (if enabled in cfg) only bots used to get auras Fixed tank switching in last phase, atm PP doesn't apply aura, but it should work, since same logic works for dogs, festergut and dbs Assist tank will now become abo if there is no abo before first puddle appears Abo will during puddles, slow oozes, slash boss & oozes In last phase assist will return to normal Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) Tanks switched in last phase flawlesly and shared stacks as they should (mutated plague got fixed in core) In short cleared PP without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. BPC Added center position to prevent bots from pulling BQL or other adds when they glitch thru walls/floor and thus resetting raid back to icc entrance teleporter Added additional z axis resetting since bots like to "fly" up in the air when attacking kinetic bombs. using cheat bypass for ball of inferno flames (atm bugged, doesn't shrink), bots will simply kill them when they spawn. Improved tanking for main tanks, improved collection of dark nuclei for assist tank Improved kinetics bomb handling Improved shock vortex spreading Improved valaran spreading for ranged Added shock vortex (non empowered) detection to avoid it while moving into safe positions Fixed jittery movement Tested on ALL diffs BQL Removed center position block so that bots can spread our easier in 25 mode, not ideal but makes 25hc easier Replaced repulsion based spreading, now each bot will have its own spot and move if needed to new spot Improved air phase spreading Fixed assist tank taking 1st bite Tested on ALL diffs VDW Due to recent core changes bots got bugged in portals if no real player entered and changed Z axis, if there was no z axis change bots would chill under the cloud on the ground and do nothing. I could not figure out how to fix this (thus breaking immersion) without force teleporting them to the clouds. Bots that go into portals will now teleport at the same time to clouds instead of following leader bot. Added feature that if players enter the portal, player with lowest guid will become bot "leader" and they will follow that player so that there is at least a little bit of immersion left. Fixed cloud collection for Heroic Mode, bots will now time clouds more precisely to avoid loosing stack due to not picking them up Improved RTI marking Improved group splitting Improved zombie kiting and avoiding explosion Tested on ALL diffs Sindragosa Bots will mark tomb positions with red smoke bomb in air phase so that real player know where to go with when beacon on them in last phase they will mark with blue smoke tomb position Fixed tank positioning Fixed wrong tomb choice and positioning Fixed tomb marking In last phase healers will stack with melee to allow boss healing In last phase when waiting for mystic debuff to pass, bots will damage tomb like in air phase to speed up the kill todo: tank switch to reset mystic buffet stacks Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) In short cleared LDW without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. LK Changed add gathering logic for 1st phase and winter phase, instead of tank moving to shamblings, he will keep taunting until they agro him. necrotic plague is easy now, ditched complex timing logic for a simple logic ( move to shambling, wait until dispeled, go back. Healers dont dispel until defile ally is near shambling ) Fixed winter phase gathering logic, assist tank will now properly move to raging spirits asap and bring them to main tank, melee dps will no properly move behind/flank spirits and shamblings to avoid instant death. Rdps will now properly focus frost orbs and adds, Transition should also be smoother now, but still needs /p reset if they get stuck. Other phases are ok, LK fight is now even better than before, but player still need to know tactics and use multibot addon to help out bots when needed, especially during defile phase since its random and position matter for valkyrs and future defiles Non winter phase AT will collect raging spirits and move them to main tank, ranged bots will keep distance, melee bots will flank them to avoid aoe Defile, ditched complex spreading which was mostly gamble with boss hooks to detect defile victim. If bot, bot will move away from raid, if real player main tank will yell Player name move away defile. bots will stay in center now if safe from defile, raging spirits or vile spirits Vile spirits soaking by assist tank. Assist tank will stand between spirits and raid and chase spirits. healers are allowed to move from position to heal assist tank. one hunter if alive will be at center position to place traps to slow down spirits HC Real players will also get buffs if cheats are enabled now Assist tank will now never move towards the raid to gather adds, instead it will taunt them instead so that they come to it Assist tank will rotate shamblings at all times away from raid Assist tank will stun shamblings before transition to avoid shockwave wipe Winter phase ice sphere location changed, ranged will focus sphere faster and better now Fixed jittery movement and low dps during winter phase Fixed most of the bots getting stuck during winter phase Valkyrs will be properly marked now, one by one, in hc bots will now ignore low hp valkyrs and focus on grabbing valkyrs or boss After winter raging spirit will have top priority for killing After winter ranged bots will 1st handle ice spheres then skull targets Spirit bomb avoidance improved, main tank should not back track into unsafe positions anymore Since real player is leader its crucial that player know the tactics, bots can not handle edge cases during the fight alone, they need some of reset, follow, summon here and there since its a long fight and things can go wrong. Tested on ALL diffs NOTE: If server crash, bots will sometimes drop ICC strategy even though they are in ICC, simply re enter or write /p nc +ICC to re enable. NOTE: addons that mark icons during fight could break bots, since icons are used for RTI by bots NOTE: I did not use any raiding addons besides unbot and multibot to control bots NOTE: In theory everything should work wihout ICC buff from world cfg, and ICC cheats from playerbots cfg, didnt test it, didnt try, its too hard core for hc mode to go raw, but it should be possible good luck :) NOTE: For normal about 5k gs should be enough to do most bosses. For HC T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for fun experience. NOTE: As player its good to know every strategy for Bosses, so that you can spot and help out with reset, follow, summon if bots seem stuck or are doing something strange, a lot of stuff is happening on most fights so expect some intervention with reset, summon, follow. 10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for bress (its not set in stone, but most success with this setup) 25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for bress (its not set in stone, but most success with this setup) GL & HF, happy raiding :D Closes #1421 #2120 Fixes #1219 NOTE: Not all of them, I have updated affected changes in #1219. Trash, quest, cheats are still nice to haves, but I don't see working on that in near future. Before posting bugs check #1219 and write there. As I said, I dont plan to implement certain things in near future, but I am more than willing to fix bugs that crash server if they happen ASAP. <!-- 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. --> ## 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. Enter ICC Test Bosses bis ICC command type bisicc into party chat or whisper and bots will reply and equip gear - Any required setup (e.g. multiple players, number of bots, specific configuration). NOTE: If server crash, bots will sometimes drop ICC strategy even though they are in ICC, simply re enter or write /p nc +ICC to re enable. NOTE: addons that mark icons during fight could break bots, since icons are used for RTI by bots NOTE: I did not use any raiding addons besides unbot and multibot to control bots NOTE: In theory everything should work wihout ICC buff from world cfg, and ICC cheats from playerbots cfg, didnt test it, didnt try, its too hard core for hc mode to go raw, but it should be possible good luck :) NOTE: For normal about 5k gs should be enough to do most bosses. For HC T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for fun experience. NOTE: As player its good to know every strategy for Bosses, so that you can spot and help out with reset, follow, summon if bots seem stuck or are doing something strange, a lot of stuff is happening on most fights so expect some intervention with reset, summon, follow. 10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for bress (its not set in stone, but most success with this setup) 25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for bress (its not set in stone, but most success with this setup) - Expected behavior and how to verify it. If requirements are met, bots should not struggle with killing bosses Compare to https://www.youtube.com/watch?v=nACyjn817iQ&t=460s --> ## 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? - - [ ] No, not at all - - [X ] Minimal impact (**explain below**) In theory it should not impact, didnt test with hi bot count or large player count - - [ ] 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? - - [ ] No - - [X ] Yes (**explain below**) Impacts in raid, new actions, triggers Impacts with new bisicc cmd that will gear bots Everything should make it easier for maintenance since each boss is in seperate file now ## 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 for analyzing code for ac code standard violations, edits were made by me. It was used for fixing bugs, brainstorming and code generation (for complex math problems, such as dynamicaly kiting oozes around, assiging positions during multiple complex situations in rotface encouter. Everything was checked and tested multiple times until it was polished (to my abilites and understanding). It helped me to solve Malleable goo detection, defile, by hooking directly to boss in order to detect it, since it was detectable only by split second since it was not npc, spell or object. <!-- 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. --> I have not tested with multiple players, or large servers or with 3k+ bots --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.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 -->
This PR refactors the Blackwing Lair strategy to align with newer raid
strategy implementations.
It extracts repeated Blackwing Lair spell IDs, game object IDs, and
suppression device checks into a shared helper, so the action and
trigger code use the same centralized definitions instead of duplicating
literals and condition chains.
No gameplay behavior changes are expected.
This PR is intended as a base for follow-up PRs that introduce
additional boss-specific strategy logic.
## 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.
- Move existing BWL-specific constants and the suppression device
condition into a shared helper.
- Keep all existing trigger names, action names, spell IDs, game object
IDs, and condition checks unchanged.
- Update the affected action/trigger implementations to call the helper
instead of duplicating the same logic inline.
- Describe the **processing cost** when this logic executes across many
bots.
- No meaningful increase. The logic executed per bot remains effectively
the same.
- This refactor only replaces duplicated inline checks with a shared
helper function and named constants.
- There are no additional scans, branches, state tracking, or new
decision loops.
## 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.
-->
Run the Blackwing Lair raid and check if the already implemented
features still work:
- _Onyxia Scale Cloak handling_: Confirm the bot still applies/checks
the same aura as before.
- _Suppression device handling_: Confirm bots still detect nearby active
suppression devices and turn them off under the same conditions as
before.
- _Chromaggus bronze affliction handling_: Confirm bots still use
Hourglass Sand if they have the bronze affliction.
## 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?
- - [ ] No, not at all
- - [x] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
A small helper call was introduced for the suppression device check, so
there is technically a minor additional call overhead compared to the
previous inline condition. In practice, the executed logic, iteration
scope, and decision flow remain unchanged, so the impact is negligible
and does not introduce meaningful scaling risk.
- 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.
-->
AI was used for review support and drafting the pull request text.
The refactoring itself was done manually.
<!--
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.
-->
This PR is intended to be behavior-preserving only.
The main change is consolidation of repeated Blackwing Lair constants
and suppression device logic into a shared helper used by both actions
and triggers. Review can focus on verifying that the extracted helper
matches the previous conditions.
<!-- 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 --> Fixed bug with finding russian texts (loc8) Related with: #1884 ## 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. Use ru client 2. Invite bot 3. Use command `focus heal ?" ## 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. --> Find and fix wrong places checking texts <!-- 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 -->
Disc Priests currently do not use Power Word: Shield until a party
member is at "medium health" (configurable, default 65%). That is the
second-level healing threshold; at the highest level, "almost full
health" (configurable, default 85%), Disc Priests will use only Prayer
of Mending and Renew. This PR adds PWS as the highest priority healing
action starting at "almost full health."
## 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 new action "power word: shield on party" to "party member almost
full health" trigger in HealPriestStrategy.cpp (the "heal" strategy,
which is the default strategy for Disc Priests, as Holy Priests use the
"holy heal" strategy).
## 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.
-->
Group up with a Disc Priest and take damage; confirm that PWS is cast
when you drop below your configured almost full health threshold.
## 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**)
PWS is the signature ability of Disc. Priests, and delaying it to 65% is
significantly limiting their effectiveness in group content,
particularly with raid bosses that deal raidwide damage and in heroic
dungeons, where waiting until the tank hits 65% is a death wish. This
single change makes an enormous difference in their effectiveness.
See below for before/after change for Eredar Twins (focus on the
activity).
Before:
<img width="693" height="397" alt="Screenshot 2026-05-18 201949"
src="https://github.com/user-attachments/assets/18ad84c7-9ad8-4c39-94e7-650c9bb5f36e"
/>
After:
<img width="746" height="409" alt="image"
src="https://github.com/user-attachments/assets/6240f118-e12f-44c7-a1af-373e94985957"
/>
- 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 -->
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.
-->
<!--
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 --> 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. -->
…#2401) <!-- 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 -->
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.
-->
<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.
Test staging
Badgermilk0
merged commit 3027d2e
into
Badgermilk0:AutoGearLimitByCharacterItemLevel
1 check failed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
20260603