veitR/mod-playerbots
1
0
Fork 0
mirror of https://github.com/liyunfan1223/mod-playerbots.git synced 2026-06-20 23:49:25 +02:00
Code Issues Packages Projects Releases Wiki Activity
2,616 Commits 9 Branches 0 Tags
Commit Graph

307 Commits

Author SHA1 Message Date
bash
29ec04e577 feat(Core/Travel): Travel-node graph routing for long-distance pathing 2026-05-10 17:30:50 +02:00
Ivan Novokhatski
8caf37af97
Add EnableAutoTradeOnItemMention config option (#2323) 
## Pull Request Description
This PR adds a config parameter
`AiPlayerbot.EnableAutoTradeOnItemMention` that controls whether trade
dialogues and inventory listings will be triggered for messages that
contain keywords anywhere in their text (for example "got some food?").
The default value is `1/true`, so for existing installs there will be no
change.

This is useful for other mods that could utilise game chats for other
purposes, specifically my
[mod-playerbots-characters](https://github.com/deseven/mod-playerbots-characters)
and @DustinHendrickson 's
[mod-ollama-chat](https://github.com/DustinHendrickson/mod-ollama-chat).
Individual users might also benefit from the ability to disable this
functionality.



## Feature Evaluation
N/A



## How to Test the Changes
1. Start the server with default config and join the game.
2. Get into a party with one or more bots.
3. Write `got some food?` to the party chat.
4. A trade dialogue along with the whispers from the bots should pop up.
5. Stop the server, change `AiPlayerbot.EnableAutoTradeOnItemMention` to
`0`.
6. Start the server, join the game.
7. Get into a party with one or more bots.
8. Write `got some food?` to the party chat.
9. Nothing should happen.

> [!NOTE]
> In both cases the commands `t something` and `c something` should
still work.

## Impact Assessment
- 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
Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)



## 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
N/A
 2026-05-08 22:39:55 -07:00
Crow
104a1b9ee1
Clean up unnecessary includes in raid strategy and trigger-context headers (#2347) 
<!--
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 trims redundant includes from raid Strategy.h and
TriggerContext.h headers. I noticed a consistent pattern of including
Multiplier.h when it was not needed in Strategy.h and including
AiObjectContext.h in TriggerContext.h when only the narrower
NamedObjectContext.h is needed (both of which I was guilty of also).
Since we make new raid strategies based on existing raid strategies, I
figure let's go for the low-hanging fruit and just fix this so we stop
doing it wrong going forward.

While I was at it, I removed other unnecessary includes but in those two
files only (across dungeon and raid strategies).

Edit: Made a couple of other minor code cleanups I'd been intending to
do. Notably, we shouldn't be including a .cpp in PlayerbotAI.cpp.

## 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.
-->

I had GPT-5.4 do the actual work because doing it myself file-by-file
would've been such a snoozefest.

<!--
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.
-->
 2026-05-02 12:20:18 -07:00
ThePenguinMan96
605f1d7aaa
PvP Gear, Autogear Tuning, and Stat Weight Corrections (#2322) 
<!--
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 -->

Hello playerbots community! I have been working diligently whilst on
vacation to help get pvp gear up and running for pvp specs. Throughout
this process, I have looked at our current autogear system, tested it
through and through, and made some changes to make gearing more
appropriate per spec. _I am going to have my description of the changes
in italics_, **and the AI description overview will be bolded.** Let's
begin!

**This PR makes some improvements to the bot autogear system across item
scoring, spec tracking(pvp specs and gear), and stat weights. Changes
are split between those that are always active and those controlled by
new config options.**

**Mandatory Changes:**

**PvP Spec Detection (IsSpecPvp)
A new method RandomPlayerbotMgr::IsSpecPvp(botGuid, cls) checks the
bot's stored specNo against the spec name string defined in config. If
the name contains "pvp", the bot is treated as a PvP spec throughout the
entire gear pipeline. This is the single source of truth used by both
InitEquipment() and ItemUsageValue. In the future this detection can be
expanded to drive bot behavior decisions — such as prioritizing dueling
players in the world, joining Wintergrasp, or preferring BG and Arena
queues over PvE content.**

_This is scalable, so if someone were to create their own pvp spec in
the config, it would still be tracked if the name contains "pvp". I like
the idea of pvp specced random bots having an identifier for pvp
events._

**PvP Weights Applied During Loot Evaluation
ItemUsageValue::QueryItemUsageForEquip() now calls IsSpecPvp() before
scoring a looted item. If the bot is on a PvP spec, it passes
SetPvpSpec(true) to the StatsWeightCalculator, ensuring looted items are
evaluated with PvP stat priorities (including resilience weighting)
rather than PvE weights. Previously, a PvP-specced bot would score loot
identically to a PvE bot.**

_So, during autogear and upgrade equips, pvp specced bots will now
heavily prioritize resilience. On the flip side, pve bots really don't
want resilience gear, so a negative weight modifier (penalty for
resilience items) has been applied to pve autogearing and upgrade
equips. This is important, because you can switch a bot from a pve spec
to a pvp spec, and it will automatically consider resilience items in
it's inventory as upgrades, and equip them. Same for when you switch a
bot from a pvp spec back to a pve spec - the resilience penalty will
encourage the bot to switch back to the best available pve gear._

**Resilience Weighting
After all per-spec weights are generated in GenerateBasicWeights(), a
global resilience modifier is applied unconditionally:**

**PvP specs: +7.0 resilience weight — strongly prioritizes resilience
gear
Non-PvP specs: −3.0 resilience weight — actively discourages resilience
gear
Resilience is additionally excluded entirely from trinket slot scoring
via SetExcludeResilience(true), preventing the PvP resilience bonus from
inflating the scores of non-CC trinkets.**

_I tried several different numbers here - as high as 10 and as low as 3
for resilience. I ended up with 7 so nearly all specs will slot
resilience in every slot EXCEPT for trinkets. I stopped weighing
resilience on trinkets because they ended up being garbage trinkets for
the most part - other endgame pve trinkets were way more impactful. In
my testing, the only class/specs that wont use 100% resilience gears are
the tanks, since defense rating/parry/block/dodge weights are so high._

**CC-Break Trinket Cache
At server startup, PlayerbotFactory::BuildCcBreakTrinketCache() queries
the world database for all trinkets (InventoryType=12, Quality≥2) whose
spell IDs include spell 42292 — the CC-break / PvP trinket effect shared
by items like Medallion of the Alliance/Horde. Results are sorted by
item level descending and cached in a static vector, ready for fast
lookup during gearing.**

_This creates a cache of cc trinkets on startup, for this:_

**CC-Break Trinket Force-Equip
During InitEquipment(), PvP-specced bots at level 50 or higher (level
minimum for autogear to apply trinkets) run a pre-selection pass over
ccBreakTrinketCache to find the best CC-break trinket they meet the
level requirement and quality limit for. Human and Undead bots are
excluded from this — they have racial abilities (Every Man for Himself,
Will of the Forsaken) that share the PvP trinket cooldown, making a
dedicated trinket redundant.**

**If a suitable trinket is found, it is stored as pvpTrinket1 and
force-equipped into TRINKET1 before the main gear loop runs. If an item
already occupies the slot, it is moved to bags first. The second-chance
pass also skips TRINKET1 when pvpTrinket1 is set, so the CC trinket is
never overwritten.**

_This is the catch-all forced pvp trinket for trinket slot 1. In my
testing, I really found out how few cc trinkets there are - most of them
are epic, and blue ones start showing up super late in the game. An
heirloom patch would really help the lower levels, being able to equip a
pvp trinket at level 10 or something. Keep in mind, that if your bot
isn't getting a pvp trinket with autogear, make sure they aren't human
or undead, and check your config for what quality items are allowed with
autogear. NOTE - PVP TRINKET STRATEGIES ARE NOT CURRENTLY CODED, SAME
WITH CC RACIALS. They will not break out of stun/cc currently. This is
for future updates if/when I make a trinketstrategy._

**Enhancement Shaman Dual Wield Fix
Classes like Rogues, Frost DKs, and Fury Warriors have their dual wield
capability established through class initialization code in the core.
Enhancement Shamans acquire Dual Wield only through a specific talent
(spell 30798, learned around level 40), and the bot factory had no code
to detect and apply this. The result was that Enhancement Shaman bots
would sometimes have their offhand weapon unequipped — despite having
the talent. After talents are applied in both InitTalentsTree() and
InitTalentsBySpecNo(), the code now checks for spell 30798 and
explicitly grants SKILL_DUAL_WIELD and SetCanDualWield(true) when
present.**

_When testing the weapon speed preferences, I noticed that randombot
enhancement shamans were unequipping their offhand randomly. They would
just walk around with a single 1-hand weapon. This is because they were
not considered in the system as dual wielding, so when initequipment or
autoequipupgrades was ran, it would unequip the offhand through a
function, despite having the dual wield talent. Looking at the code, the
other classes already have this flag (warriors, rogues, dks, hunters)
because they didn't acquire it through talents._

**CalculateItem() Slot Awareness
StatsWeightCalculator::CalculateItem() now accepts an optional slot
parameter (default -1). When provided and the item is a weapon,
ApplyWeaponSpeedGovernance() can be called. Both item scoring calls
inside InitEquipment() — the candidate scoring loop and the incremental
old-item comparison — now pass the current equipment slot.**

_This change allows the calculate item function to know what slot it's
working with, and that's how it modifies it's decision making for some
of the optional features below._

**Holy Paladin Weapon Scoring Fix
Prior to this change, Holy Paladin could end up equipping 2H weapons
because haste and crit sticks (2H weapons) were outscoring appropriate
1H caster weapons — the item type penalty was not catching them
correctly. Holy Paladin is now explicitly added to the dual-wield
penalty group (preventing 2H weapons from being viable), excluded from
the generic caster 1H penalty (since they use 1H + shield rather than a
staff), and given a 0.8x soft preference for 1H weapons.**

_In autogear testing, sometimes 2h weps with high crit/haste would win
over caster gear - this is especially noticeable at lower levels, with
shallower item pools (greens only). You'd hit autogear and the holy
paladin would equip a 2h axe with crit :( So this makes it so holy
paladins only use 1h weapons. They can use either a shield or an
offhand, depending on stat weights._

**PvP Spec Slots Added for All Classes
The existing RandomClassSpecProb / RandomClassSpecIndex config entries
control what percentage of random bots in the world are assigned each
spec. Previously only PvE specs (indices 0–2, or 0–3 for Druids) were
defined, giving server operators no way to introduce PvP-specced random
bots into the world population. This PR adds PvP spec slots for every
class (indices 3–6 depending on class), all defaulting to 0 probability.
Server operators can raise these values to spawn PvP-specced random bots
— e.g., setting RandomClassSpecProb.1.3 = 20 would make 20% of Warrior
bots run Arms PvP.
Two additional PvE specs have also been added:
Death Knight index 3: Double-aura Blood (a hybrid Blood/Frost PvE tank
variant)
Mage index 3: Frostfire (a PvE hybrid spec)
All existing spec entries have been annotated with comments identifying
each one (e.g., # arms pve, # holy pve) for readability.**

_This change was actually added at the start - I realized that there was
no way for pvp-specced randombots to spawn naturally, so I added
optional probabilities to the config. They are currently set at 0% by
default, but giving the user the option I feel is necessary. Also, it
would have been impossible for me to test the init on randombots with
pvp gear otherwise. Also, I noticed that the frostfire mage and the
dual-aura dk didn't have an option, so I added them in as well, as well
as names above each option for quality of life._

**Stat Weight Corrections
The following per-spec stat weights were adjusted to better reflect
actual WotLK priorities. Entries marked NEW did not previously exist;
unmarked rows show old → new values.**

<img width="795" height="268" alt="arms warrior"
src="https://github.com/user-attachments/assets/cb0deb00-a985-432d-81a1-133fc953088b"
/>

_Arms warriors would prefer leather/ap gear about half of the time - the
combined weights of both would often beat strength gear, especially at
lower levels, or where the item pool was shallow. Also, they continued
to spawn with spell power gear and defense gear occasionally, especially
on gear with resilience (resilience, spell power, crit, haste, stam
items)._

<img width="796" height="301" alt="fury warrior"
src="https://github.com/user-attachments/assets/715ff3a3-3d20-4e0e-a953-7ed6fd9386db"
/>

_Fury warriors had the same issues as arms warrior, but really can't
afford to lose a strength item - beserker stance increases strength by
20%. Also had to reduce haste here because haste really isn't nearly as
important as strength, crit, arp. Haste items would win often over
strength/crit/arp gear._

<img width="796" height="300" alt="prot tanks"
src="https://github.com/user-attachments/assets/624de09a-2506-4aee-95aa-c49cbc5b85d3"
/>

_So, prot paladins and prot warriors currently are weighed identically
fyi. Look at that whopping 2.0 agility - twice as important as strength?
I noticed that my prot paladins/warriors were equipping
agility/haste/crit items instead of defense gear on their neck, rings,
trinkets, and back. This adjustment pretty much ensures that defense
gear takes those slots if it's available. Removed the crit/haste
weightings, because realistically if a tank wants more damage, it will
just get strength. Lastly added the spell power penalty because prot
paladins would spawn in fully holy gear if they were pvp specced
(resilience is weighted so high, resilience/spellpower/stam/haste gear
would often win). This aims to prevent that._

<img width="802" height="421" alt="dps dks"
src="https://github.com/user-attachments/assets/371d1344-2382-4460-b3a7-f38b33025b73"
/>

_Same issue with plate dps as the warriors had. Spell power gear would
occasionally spawn on crit/hit items in pve, and a ton of spell power
resilience gear would spawn. There is no scenario where a DK wants spell
power, this isn't patch 3.0.1..._

<img width="796" height="447" alt="blood dk"
src="https://github.com/user-attachments/assets/c84a2bbf-7daa-4805-acf3-cd3bf815eda4"
/>

_Similar issues to prot paladin/warrior. I was really tired of seeing
block rating/value gear as a result of getting gear with defense/stam.
This results in a lot more defense rating/expertise/hit/dodge/parry
gear, and basically makes shield stats nearly non-existent (unless the
upgrade is good enough, it could still win)_

<img width="794" height="226" alt="ret paladin"
src="https://github.com/user-attachments/assets/b09f40ed-b25f-4945-940c-2ce92f81c7c4"
/>

_Prior to this PR, the positive spellpower and int weights were enough
for ret paladins to spawn with spellpower/int/haste/crit gear. This is
unlikely now. And agility/ap was reduced to favor more strength gear._

<img width="795" height="306" alt="Enhancement Shaman"
src="https://github.com/user-attachments/assets/1e5231fd-36ea-4b7e-a546-cf0075d17bd4"
/>

_While spell power is a decent stat on enhancment shamans, it was
appearing on too much gear, especially on items that were
haste/crit/spell power. And for elemental shamans, they were getting
agi/haste/crit gear, so this aims to get rid of those items entirely
without reducing haste/crit._

<img width="800" height="119" alt="shaman pally"
src="https://github.com/user-attachments/assets/6ea3300a-effd-4a03-8f6f-4ae13c5383a5"
/>

_Holy paladins and resto shamans are scored the same, but this prevents
attack power/haste/crit gear, since haste and crit are weighted high._

<img width="1025" height="385" alt="mage"
src="https://github.com/user-attachments/assets/03191dfd-dc09-477d-8424-8fd56f3e0d71"
/>

_Prevents mages from equipping/autogearing items with attack power, some
attack power/crit/haste/hit items were winning with shallow item pools._

<img width="1022" height="502" alt="hunter rogue"
src="https://github.com/user-attachments/assets/06fa67c9-7709-4ee8-a0e2-34de18594018"
/>

_Prevents hunters and rogues from getting spell power leather gear with
hit/crit. Crit is very heavy for hunters so this was decently common._

**Optional Changes (Config-Controlled)**

**AiPlayerbot.PreferClassArmorType (default: 0)
Applies a 3x score multiplier to armor matching the bot's
class-appropriate type (plate/mail/leather/cloth). A significantly
better off-type item can still win — this is a soft preference, not a
hard filter.**

_Are you tired of your fury warrior being a leather daddy? Are you tired
of your holy paladin running around in cloth lingerie? This will fix
that. For mail classes (hunters/shamans) and plate classes, this only
kicks in after level 40. But it really helps adhere to the highest armor
class available. This would be the perfect solution to the quarterly
question "Why is my paladin wearing leather?". This definitely should
remain optional, as quite a few BIS lists would disagree with it.
Leather at certain stages is great for hunters/shamans/warriors/dks._

**AiPlayerbot.AutogearAllowsQuestRewards (default: 0)
Builds a cache of equippable armor and weapon quest rewards at startup.
Bots can then equip these items during autogear, using the quest's
minimum level as the effective required level gate.**

_So, I noticed that autogear didn't allow items without a level
requirement (quest rewards), because it didn't know how to handle that
when giving out gear. It would previously just flat out reject all quest
rewards, as they wouldn't be a part of the item pool. This option
enables quest rewards to be considered in the item pool, and the level
correlates to the lowest level you could get the quest. I have tested
this for about 3 hours across all specs and using blue/green gear, it
seems like a really nice bonus. Keep in mind that I do 0 quests on my
way to 80, so players like me could still benefit from those items. I
think this should remain optional._

**AiPlayerbot.EquipAllSlotsAtAnyLevel (default: 0)
Bypasses the low-level slot restrictions in InitEquipment():
Trinkets normally locked until level 50
Head/Neck until level 30
Rings until level 20
All other non-weapon slots until level 5**

_Autogear currently has level floors for slots - they will not ever give
items below the above thresholds. This config option bypasses that. I
have not tested this as much as I should have, so as people test this,
they could let us know of items that should be blacklisted._

**AiPlayerbot.WeaponSpeedGovernance (default: 0)
When enabled, ApplyWeaponSpeedGovernance() applies a 3x score multiplier
to weapons matching the spec's ideal attack speed profile. Applies to
mainhand, offhand, and ranged slots only. Per-spec preferences:
Arms Warrior: Slow 2H (>=3400ms) in mainhand; poleaxes and axes
preferred (Axe Specialization)
Ret Paladin / Blood & Unholy DK:  Slow 2H (>=3400ms) in mainhand
Prot Warrior & Paladin: Slow 1H (>=2600ms) in mainhand
Fury Warrior dual wield:  Slow 1H (>=2600ms) in both hands
Fury Warrior titan's grip: Slow 2H (>=3400ms) in both hands
Frost DK: Slow 1H (>=2600ms) in both hands; 2H excluded
Enhancement Shaman (dual wield): Slow 1H (>=2600ms) in both hands;
synchronized MH/OH speeds for flurry procs
Enhancement Shaman (pre-dual wield): Slow 2H (>=3400ms) in mainhand
Combat Rogue: Slow MH (>=2600ms) + Fast OH (<=1500ms)
Assassination / Subtlety Rogue: Slow dagger MH (>=1700ms) + Fast dagger
OH (<=1500ms)
Hunter: Slow ranged (>=2600ms); melee is a stat stick, speed ignored
Feral Druid: No preference (forms normalize attack speed)**

_Besides pvp gearing for pvp specs, I feel like this is one of the
nicest additions. It was really frustrating to see an enhancement shaman
put windfury on a 1.5 dagger. Without this, weights for melee dps are
calculated on dps alone, not weapon speed. You'll see 2h specs use fast
2h weapons (3.0), rogues use 2 fast weapons or slow weapons, frost dks
occasionally using 2h weapons while having dual wield talents. I tested
this for about 6 hours across all mentioned specs at levels 20, 30, 40,
50, 60, 65, 70, 75, and 80, with 3 quality types (greens, blues,
purples). I would actually consider making this mandatory, simply
because of the impact I saw in the dps charts. Super happy and proud of
this._

<img width="1021" height="470" alt="files changes"
src="https://github.com/user-attachments/assets/f55d955c-8760-4adf-b4d9-84797da2dc65"
/>


## 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.

_Two caches are built upon startup - the pvp trinket cache and the quest
reward cache. From there, this directly modifies the stat weight
calculations involving initequipement (autogear) and autoequipupgrades,
as both go off of stat weight calculations. I tried to implement these
changes with as little custom functions and coding as possible, and
relied as much as I could on the pre-existing framework._

- Describe the **processing cost** when this logic executes across many
bots.

_Fortunately most of the gates are boolean so it shouldn't impact
performance much at all. I ran these changes on my local server with
stock 500 bots, noticed no pmon difference from the main branch. Did a
24h stress test on my server yesterday, stats looked consistent with the
stress test I did prior to making any changes on 3-31-26._

_It helps that it uses pre-existing functions such as initequipment and
autoequipupgrades, and it really just modifies them with slightly more
logic. That being said, autogear didn't lag my server at all, nor did
the bots equipping upgrades._

## 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.
-->

_So, with the basic stock playerbots config (do not forget to copy the
new config!), the only thing that should change is the pvp gear
appearing on pvp specs, and the classes preferring more appropriate
stats across the board. You can load into the game, level a bot to 20,
autogear, and notice the difference. Same at level 40, 60, 75, or
whatever. You could add in the optional config settings to further
streamline the gear you want. I currently run with all 4 enabled, 2 of
which increase the item pool, and 2 of which help guide them to more
appropriate gear (armor/weps)._

## 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**)

_The code is only used on startup (cache generation) and when
autogear/autoequipupgrades is called. Not all the time, and not per
tick. I noticed no performance impact after these changes._

- Does this change modify default bot behavior?
    - - [ ] No
    - - [x] Yes (**explain why**)

_It modifies the decision making as far as equipment goes, but as far as
priority/strategies, this does not affect that._

- Does this change add new decision branches or increase maintenance
complexity?
    - - [x] No
    - - [ ] Yes (**explain below**)

_Not to my knowledge, but I'll rely on testers and the community to let
me know if it does._

## 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 in the research of the initequipment system, stat weights,
and cache building. As far as generating the code, using AI was 2 steps
forward, 1 step back. I used Claude Code with Sonnet 4.6 (high) and had
gemini/copilot review the work. **AI did generate a large portion of the
code being used.** I have personally reviewed every line, and a lot was
removed out of being obsolete/new system that copied an old one/too many
comments. I don't think anything else can be trimmed, though. I also
used AI in the PR description, and made my own comments in italics below
each entry. I hate explaining/writing._

<!--
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 would like atleast 5-10 people to review this over the next 1-6
months. The big problem I used to have with my PRs was I was acting like
they were a sprint, when it's really a marathon - good changes take
time, and I was too quick to bust out new content. The old PRs I made
introduced just as many new bugs as they did features. I learned my
lesson, and have tested this extensively (code was pretty much complete
on 4-10-26, been testing alone for the last 11 days) and it's ready for
the test realm for others to try out. I think it's going to be a good
step forward when it comes to gear decision making for bots as a whole.
PvPers have come and gone too much from this project due to the lack of
options, and this helps captivate that audience. Please reach out to me
on discord at Zhur#4391, I am happy to hear results/suggestions there as
well as here._

---------

Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
 2026-04-24 23:22:52 +02:00
kadeshar
665a702a65
Worldbuff classic support (#2311) 
<!--
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 -->

Added support for flask and food for vanilla and TBC
## Vanilla

| Class | Spec | Buff IDs | Buffs |
| --- | --- | --- | --- |
| Warrior | Arms | `17538`, `24799` | Elixir of the Mongoose; Smoked
Desert Dumplings |
| Warrior | Fury | `17538`, `24799` | Elixir of the Mongoose; Smoked
Desert Dumplings |
| Warrior | Protection | `17626`, `25661` | Flask of the Titans; Dirge's
Kickin' Chimaerok Chops |
| Paladin | Holy | `17627`, `18194` | Flask of Distilled Wisdom;
Nightfin Soup |
| Paladin | Protection | `17626`, `25661` | Flask of the Titans; Dirge's
Kickin' Chimaerok Chops |
| Paladin | Retribution | `17628`, `24799` | Flask of Supreme Power;
Smoked Desert Dumplings |
| Hunter | Beast Mastery | `17538`, `18192` | Elixir of the Mongoose;
Grilled Squid |
| Hunter | Marksmanship | `17538`, `18192` | Elixir of the Mongoose;
Grilled Squid |
| Hunter | Survival | `17538`, `18192` | Elixir of the Mongoose; Grilled
Squid |
| Rogue | Assassination | `17538`, `18192` | Elixir of the Mongoose;
Grilled Squid |
| Rogue | Combat | `17538`, `18192` | Elixir of the Mongoose; Grilled
Squid |
| Rogue | Subtlety | `17538`, `18192` | Elixir of the Mongoose; Grilled
Squid |
| Priest | Discipline | `17628`, `18194` | Flask of Supreme Power;
Nightfin Soup |
| Priest | Holy | `17627`, `18194` | Flask of Distilled Wisdom; Nightfin
Soup |
| Priest | Shadow | `17628`, `18194` | Flask of Supreme Power; Nightfin
Soup |
| Shaman | Elemental | `17628`, `18194` | Flask of Supreme Power;
Nightfin Soup |
| Shaman | Enhancement | `17538`, `24799` | Elixir of the Mongoose;
Smoked Desert Dumplings |
| Shaman | Restoration | `17627`, `18194` | Flask of Distilled Wisdom;
Nightfin Soup |
| Mage | Arcane | `17628`, `18194` | Flask of Supreme Power; Nightfin
Soup |
| Mage | Fire | `17628`, `18194` | Flask of Supreme Power; Nightfin Soup
|
| Mage | Frost | `17628`, `18194` | Flask of Supreme Power; Nightfin
Soup |
| Warlock | Affliction | `17628`, `25661` | Flask of Supreme Power;
Dirge's Kickin' Chimaerok Chops |
| Warlock | Demonology | `17628`, `25661` | Flask of Supreme Power;
Dirge's Kickin' Chimaerok Chops |
| Warlock | Destruction | `17628`, `25661` | Flask of Supreme Power;
Dirge's Kickin' Chimaerok Chops |
| Druid | Balance | `17628`, `18194` | Flask of Supreme Power; Nightfin
Soup |
| Druid | Feral Bear | `17626`, `25661` | Flask of the Titans; Dirge's
Kickin' Chimaerok Chops |
| Druid | Restoration | `17627`, `18194` | Flask of Distilled Wisdom;
Nightfin Soup |
| Druid | Feral Cat | `17538`, `24799` | Elixir of the Mongoose; Smoked
Desert Dumplings |

## TBC

| Class | Spec | Buff IDs | Buffs |
| --- | --- | --- | --- |
| Warrior | Arms | `28520`, `33256` | Flask of Relentless Assault;
Roasted Clefthoof |
| Warrior | Fury | `28520`, `33256` | Flask of Relentless Assault;
Roasted Clefthoof |
| Warrior | Protection | `28518`, `33257` | Flask of Fortification;
Fisherman's Feast |
| Paladin | Holy | `28491`, `39627`, `33263` | Elixir of Healing Power;
Elixir of Draenic Wisdom; Blackened Basilisk |
| Paladin | Protection | `28518`, `33257` | Flask of Fortification;
Fisherman's Feast |
| Paladin | Retribution | `28520`, `33256` | Flask of Relentless
Assault; Roasted Clefthoof |
| Hunter | Beast Mastery | `28520`, `33261` | Flask of Relentless
Assault; Warp Burger |
| Hunter | Marksmanship | `28520`, `33261` | Flask of Relentless
Assault; Warp Burger |
| Hunter | Survival | `28520`, `33261` | Flask of Relentless Assault;
Warp Burger |
| Rogue | Assassination | `28520`, `33261` | Flask of Relentless
Assault; Warp Burger |
| Rogue | Combat | `28520`, `33261` | Flask of Relentless Assault; Warp
Burger |
| Rogue | Subtlety | `28520`, `33261` | Flask of Relentless Assault;
Warp Burger |
| Priest | Discipline | `28491`, `39627`, `33263` | Elixir of Healing
Power; Elixir of Draenic Wisdom; Blackened Basilisk |
| Priest | Holy | `28491`, `39627`, `33263` | Elixir of Healing Power;
Elixir of Draenic Wisdom; Blackened Basilisk |
| Priest | Shadow | `28540`, `33263` | Flask of Pure Death; Blackened
Basilisk |
| Shaman | Elemental | `28521`, `33263` | Flask of Blinding Light;
Blackened Basilisk |
| Shaman | Enhancement | `28520`, `33261` | Flask of Relentless Assault;
Warp Burger |
| Shaman | Restoration | `28491`, `39627`, `33263` | Elixir of Healing
Power; Elixir of Draenic Wisdom; Blackened Basilisk |
| Mage | Arcane | `28521`, `33263` | Flask of Blinding Light; Blackened
Basilisk |
| Mage | Fire | `28540`, `33263` | Flask of Pure Death; Blackened
Basilisk |
| Mage | Frost | `28540`, `33263` | Flask of Pure Death; Blackened
Basilisk |
| Warlock | Affliction | `28540`, `33263` | Flask of Pure Death;
Blackened Basilisk |
| Warlock | Demonology | `28540`, `33263` | Flask of Pure Death;
Blackened Basilisk |
| Warlock | Destruction | `28540`, `33263` | Flask of Pure Death;
Blackened Basilisk |
| Druid | Balance | `28521`, `33263` | Flask of Blinding Light;
Blackened Basilisk |
| Druid | Feral Bear | `28518`, `33257` | Flask of Fortification;
Fisherman's Feast |
| Druid | Restoration | `28491`, `39627`, `33263` | Elixir of Healing
Power; Elixir of Draenic Wisdom; Blackened Basilisk |
| Druid | Feral Cat | `28520`, `33261` | Flask of Relentless Assault;
Warp Burger |

## 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 bot with 60-79 level
2. Add him strategy `nc +worldbuff`
3. Bot should apply buffs


## 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.
-->

Prepare list of buffs based on website and apply them to matrix.
Randomly reviewed ids with guides and in-game

<!--
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.
-->



[VANILLA_CONSUMABLE_WORLD_BUFFS.md](https://github.com/user-attachments/files/26761020/VANILLA_CONSUMABLE_WORLD_BUFFS.md)

[TBC_CONSUMABLE_WORLD_BUFFS.md](https://github.com/user-attachments/files/26761021/TBC_CONSUMABLE_WORLD_BUFFS.md)
 2026-04-17 13:54:52 -07:00
Scarecr0w12
c0c2b6ab5b
feat(Core/Playerbots): Initialize bot professions and specializations (#2287) 
## Pull Request Description

Initialize random bot professions from the factory using class-matching
or weighted-random profession pairs, respect the active primary
profession cap, and restore required profession tools during bot
init/refresh.

This PR also initializes profession specializations for eligible bots so
crafted professions are not left in an unspecialized state after
profession assignment. Supported specialization families include:

- Alchemy: Transmute / Elixir / Potion
- Engineering: Goblin / Gnomish
- Leatherworking: Dragonscale / Elemental / Tribal
- Tailoring: Spellfire / Mooncloth / Shadoweave
- Blacksmithing: Armorsmith / Weaponsmith, plus Hammersmith / Axesmith /
Swordsmith for eligible Weaponsmith bots

Specialization choices are stored in bot values so they remain stable
across later refreshes. Required tool items are also restored for
relevant professions during maintenance.

## Feature Evaluation

- Describe the **minimum logic** required to achieve the intended
behavior.
- Select one or two professions during factory initialization from a
small weighted list.
- Clamp the assigned professions to the configured primary profession
limit.
- Learn the profession starter spell and set skill to the bot’s
profession cap.
- For professions with supported specialization branches, assign exactly
one valid specialization when the bot meets the same level/skill gates
used by AzerothCore profession scripts.
- Persist the specialization selection in stored bot values so the
choice is stable and does not need to be recalculated repeatedly.
- Restore missing profession tools only when the bot has the related
profession and the tool is absent.

- Describe the **processing cost** when this logic executes across many
bots.
- The added logic executes only during bot init/refresh, not as part of
per-tick combat or trigger evaluation.
- Runtime cost is limited to a few small switch statements, stored value
lookups, spell checks, and item presence checks.
- No expensive repeated searches, map scans, or per-trigger decision
trees were added.
- The design keeps specialization selection deterministic after first
assignment by storing the result, avoiding repeated random branching
later.

## How to Test the Changes

1. Build and restart the server with this branch.
2. Trigger random bot creation, refresh, or level-based reroll for
multiple bots.
3. Verify in `Playerbots.log` that bots receive profession pairs and,
when eligible, profession specializations.
4. Check that low-level bots do not receive specializations before the
required thresholds.
5. Check that eligible bots do receive one specialization for supported
profession families.
6. Verify that specialization choices remain stable across subsequent
refreshes.
7. Verify that profession tools are restored when missing:
   - Mining Pick
   - Blacksmith Hammer
   - Arclight Spanner
   - Runed Arcanite Rod
   - Skinning Knife
8. For a few bots, inspect in game or via debug tooling that profession
spells/specialization spells are present as expected.

Expected behavior:
- Bots receive professions that respect the configured primary
profession limit.
- Profession skill values are initialized to the level-based cap.
- Eligible bots receive exactly one valid specialization for supported
profession families.
- Specialization assignments are logged and persist across refreshes.
- Profession tools are restored only when required.

## Impact Assessment

- 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**)

  Explanation:
- The added work runs during initialization/refresh rather than normal
per-tick behavior.
- Logic is bounded, data-local, and based on direct skill/spell/value
checks.

- Does this change modify default bot behavior?
    - - [ ] No
    - - [x] Yes (**explain why**)

  Explanation:
- Bots can now start with initialized professions, required tools, and
eligible profession specializations instead of remaining partially
configured or unspecialized.

- Does this change add new decision branches or increase maintenance
complexity?
    - - [ ] No
    - - [x] Yes (**explain below**)

  Explanation:
- The factory now contains specialization assignment branches for
supported profession families.
- Complexity is intentionally limited to init-time switch-based logic
with stored specialization values to preserve predictability.

## AI Assistance

Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)

AI assistance was used for:
- code generation and refactoring in `PlayerbotFactory`
- drafting and refining profession/specialization initialization logic
- PR description preparation

All generated and suggested code was reviewed, adjusted, built locally,
and validated before submission.

## 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

- Target branch is `test-staging`.
- Profession/specialization logic is intentionally limited to
init/refresh paths to avoid per-tick cost.
- Specialization selections are stored to keep bot behavior stable
across later refreshes.
- Recent changes also add debug logging for assigned specializations and
save the bot after specialization learning so assignments are visible
and persisted.

---------

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>
 2026-04-17 13:54:36 -07:00
Crow
d01316fe64
Exclude Isle of Quel'danas Areas From PvP (#2304) 
<!--
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 the vendor/quest hub areas of the Isle of Quel'danas to excluded
PvP areas (Shattered Sun Staging Area, Sun's Reach Sanctum, Sun's Reach
Harbor, Sun's Reach Armory). Otherwise, bots attack each other and piss
off all the Shattered Sun Offensive guards and NPCs.


## 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.
-->
Go to one of the above-mentioned areas while PvP flagged (or on a PvP
server, like me). See if bots attack.


## 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>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
 2026-04-17 11:26:53 -07:00
Keleborn
53a607e147
Enable bots to do Outdoor pvp (#2217) 
## Pull Request Description
Bots will now engage with outdoor pvp targets when in an area with them.
I carved this out of the guildrpg system Im working on since it should
work just fine as a standalone. Note this requires a core update
https://github.com/azerothcore/azerothcore-wotlk/pull/25103

## Feature Evaluation

Its not expensive. the status checks are fairly light and simple. Should
be on par with current rpg system actions

## How to Test the Changes

You can try to use selfbot to enable this while in EPL, or set the
probability of all other rpg actions to 0.


## 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**)

There is some impact, but should be minimal overall. 

- Does this change modify default bot behavior?
    - [ ] No
    - [x] Yes (**explain why**)
It will activate automatically based on default config. 


- Does this change add new decision branches or increase maintenance
complexity?
    - [ ] No
    - [x] Yes (**explain below**)

## AI Assistance
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.
-->
Nothing beyond search functionality and autocomplete. 


## Final Checklist

- [x] Stability is not compromised.
- [x] Performance impact is understood, tested, and acceptable.
- [x] Added logic complexity is justified and explained.
- [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: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
 2026-04-10 22:16:58 -07:00
bash
9ebccc23a2 clearified the ac 2026-04-05 11:25:53 +02:00
bashermens
c0390a24fd
feat(Performance): BotActiveAlone activity interval fixes and default settings for avg player (#2250) 
<!--
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

- Bugfix the jittering on/off of botAlone activity
- BotActiveAlone activity duration configurable
- Updated the default config values for general user for a smoother
experience
- Added offset jittering for the check allowedActivity and check next AI
delay to prevent cpu spikes

(disabled WhenIsFriend can cause race conditions)

## 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?
    - - [ ] No, not at all
    - - [ ] Minimal impact (**explain below**)
    - - [x] Moderate impact (**explain below**)

In a positive way, bots in your zone and 150 radius will always be
active, meanwhile other bots will be active 40%
of the time with intervals for 60 seconds per bot. With much lower
latencies. All configurable without say.

40% and 60 seconds for more balance for those who seek bots create world
feel more natural and live vs bots leveling without killing the server
performance. Why not 50 due activity of bots itself 40% will result more
into 45-50% like behavior and 50% prolly more 55%-60%. This it not
something we want incorporate when calculating the value since it
depends on various config and situation. But 40% is good base with
default config.

- 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**)



## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
- Does this change add bot messages to translate?
    - - [x] No
    - - [ ] Yes (**list messages in the table**)

| Message key  | Default message |
| --------------- | ------------------ |
|			 |			      |
|			 |			      |

## 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.
-->



## Final Checklist

- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [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>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
 2026-04-03 14:54:46 -07:00
Crow
f76c286353
Fix Destruction Warlock Glyphs, Take Two (#2278) 
<!--
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 -->
When I previously "fixed" the default glyphs for destro pve, I
accidentally put Life Tap twice. This PR replaces the second Life Tap
with Incinerate (which is what I intended).

I also fixed a typo in the config.


## 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.
-->

Use maintenance on a level 80 Warlock with destro pve spec. Their major
glyphs should be, in order, Life Tap, Conflagrate, and Incinerate.

## 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 default glyphs are wrong.


- Does this change add new decision branches or increase maintenance
complexity?
    - - [x] No
    - - [ ] Yes (**explain below**)



## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
- Does this change add bot messages to translate?
    - - [x] No
    - - [ ] Yes (**list messages in the table**)

| Message key  | Default message |
| --------------- | ------------------ |
|			 |			      |
|			 |			      |

## 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.
-->



## Final Checklist

- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [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>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
 2026-04-03 13:31:30 -07:00
Crow
35a0282ca6
Add Sense Undead for Paladins (#2200) 
# Pull Request

This PR adds the sense undead ability for Paladins, which they will keep
active at all times. This is mildly useful because the associated minor
glyph provides a 1% damage increase against undead while the ability is
active.

Sense undead is also added to InitClassSpells(). I understand that it is
a trainer spell so would normally be covered by InitAvailableSpells(),
but those playing with mod-individual-progression will not receive the
spell through InitAvailableSpells() because it is removed from trainers
by the mod (in TBC, a quest was required to obtain the spell).

Finally, the minor glyph of sense undead is now added to the config as a
default glyph for all PvE specs. It is not added for PvP specs because
Forsaken do not count as undead so the glyph is useless in PvP. I also
made some other tweaks to Paladin default minor glyphs that are not
worth spending any time talking about.

Edit: I also did some minor reformatting of code and replaced some
numbers with existing constants.

---

## Design Philosophy

We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.

Principles:

- **Stability before intelligence**  
  A stable system is always preferred over a smarter one.

- **Performance is a shared resource**  
  Any increase in bot cost affects all players and all bots.

- **Simple logic scales better than smart logic**  
Predictable behavior under load is more valuable than perfect decisions.

- **Complexity must justify itself**  
  If a feature cannot clearly explain its cost, it should not exist.

- **Defaults must be cheap**  
  Expensive behavior must always be optional and clearly communicated.

- **Bots should look reasonable, not perfect**  
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those
principles.

---

## Feature Evaluation

Please answer the following:

- Describe the **minimum logic** required to achieve the intended
behavior?
- Describe the **cheapest implementation** that produces an acceptable
result?
- Describe the **runtime cost** when this logic executes across many
bots?

The implementation just checks if a Paladin has the sense undead aura,
and if not, the Paladin will activate sense undead. It is simple and
cheap.

---

## How to Test the Changes

- Step-by-step instructions to test the change
- Any required setup (e.g. multiple players, bots, specific
configuration)
- Expected behavior and how to verify it

## Complexity & Impact

Does this change add new decision branches?
- - [x] No
- - [ ] Yes (**explain below**)

Does this change increase per-bot or per-tick processing?
- - [ ] No
- - [x] Yes (**describe and justify impact**)

Infinitesimally 

Could this logic scale poorly under load?
- - [x] No
- - [ ] Yes (**explain why**)

## Defaults & Configuration

Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)

Paladin bots will by default have sense undead enabled. There is no
disadvantage to this.

If this introduces more advanced or AI-heavy logic:
- - [x] Lightweight mode remains the default
- - [ ] More complex behavior is optional and thereby configurable
---

## AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [x] No
- - [ ] Yes (**explain below**)

If yes, please specify:

- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation)
- Which parts of the change were influenced or generated
- Whether the result was manually reviewed and adapted

AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB
logic. We expect contributors to be honest
about what they do and do not understand.

---

## Final Checklist

- - [x] Stability is not compromised
- - [x] Performance impact is understood, tested, and acceptable
- - [x] Added logic complexity is justified and explained
- - [x] Documentation updated if needed

---

## Notes for Reviewers

Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.

---------

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>
 2026-03-20 20:38:06 +01:00
Keleborn
2ce8993986
Correct Loot rolling behavior (#2190) 
# Pull Request

This fixes the loot rolling behavior issue created by #2068 . 
Introduce the ability for enchanter bots to disenchant items they dont
need, and roll need on recipes they also need.
Make it so ITEM_USAGE_AH ensures the item is not BOP.
Try to reduce the call for item_usage in CalculateRollVote by passing
usage if available.

---

## Design Philosophy

We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.

Principles:

- **Stability before intelligence**  
  A stable system is always preferred over a smarter one.

- **Performance is a shared resource**  
  Any increase in bot cost affects all players and all bots.

- **Simple logic scales better than smart logic**  
Predictable behavior under load is more valuable than perfect decisions.

- **Complexity must justify itself**  
  If a feature cannot clearly explain its cost, it should not exist.

- **Defaults must be cheap**  
  Expensive behavior must always be optional and clearly communicated.

- **Bots should look reasonable, not perfect**  
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those
principles.

---

## Feature Evaluation

Please answer the following:

- Describe the **minimum logic** required to achieve the intended
behavior?
-- Add a new check that downgrades greed rolls to desired levels, or
bools for the other two options.
- Describe the **cheapest implementation** that produces an acceptable
result?
-- As implemented.
- Describe the **runtime cost** when this logic executes across many
bots?
-- Same as before. Item usage is the heaviest part, and that hasnt
changed to accommodate this.

---

## How to Test the Changes

- multiple bots in a group with group loot on, do a dungeon or
something. One bot should be an enchanter.

## Complexity & Impact

Does this change add new decision branches?
- - [ ] No
- - [x] Yes (**explain below**)

Does this change increase per-bot or per-tick processing?
- - [X] No
- - [ ] Yes (**describe and justify impact**)

Could this logic scale poorly under load?
- - [X] No
- - [ ] Yes (**explain why**)
---

## Defaults & Configuration

Does this change modify default bot behavior?
- - [ ] No
- - [X] Yes (**explain why**)
- - - Corrects the looting behavior to original design. 

If this introduces more advanced or AI-heavy logic:
- - [ ] Lightweight mode remains the default
- - [X] More complex behavior is optional and thereby configurable
---

## AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [x] No
- - [ ] Yes (**explain below**)

---

## Final Checklist

- - [x] Stability is not compromised
- - [x] Performance impact is understood, tested, and acceptable
- - [x] Added logic complexity is justified and explained
- - [x] Documentation updated if needed

---

## Notes for Reviewers

Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
 2026-03-20 20:37:02 +01:00
Rikus Louw
ed81a43403
Added all TBC attunement quests (#2179) 
# Pull Request

Added all TBC attunement quests to conf

---

## Design Philosophy

We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.

Principles:

- **Stability before intelligence**  
  A stable system is always preferred over a smarter one.

- **Performance is a shared resource**  
  Any increase in bot cost affects all players and all bots.

- **Simple logic scales better than smart logic**  
Predictable behavior under load is more valuable than perfect decisions.

- **Complexity must justify itself**  
  If a feature cannot clearly explain its cost, it should not exist.

- **Defaults must be cheap**  
  Expensive behavior must always be optional and clearly communicated.

- **Bots should look reasonable, not perfect**  
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those
principles.

---

## Feature Evaluation

Please answer the following:

- Describe the **minimum logic** required to achieve the intended
behavior?
- Describe the **cheapest implementation** that produces an acceptable
result?
- Describe the **runtime cost** when this logic executes across many
bots?

---

## How to Test the Changes

- Step-by-step instructions to test the change
Run maintenance on bots
- Any required setup (e.g. multiple players, bots, specific
configuration)
This only applies to Individual Progression mod, since attunements
aren't required in base AC
- Expected behavior and how to verify it
Bots should be able to enter:
- The Eye (Tempest Keep)
- Mount Hyjal
- Black Temple

## Complexity & Impact

Does this change add new decision branches?
- - [x] No
- - [ ] Yes (**explain below**)

Does this change increase per-bot or per-tick processing?
- - [x] No
- - [ ] Yes (**describe and justify impact**)

Could this logic scale poorly under load?
- - [x] No
- - [ ] Yes (**explain why**)
---

## Defaults & Configuration

Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
All attunements for TBC are now added on 'maintenance' command

If this introduces more advanced or AI-heavy logic:
- - [ ] Lightweight mode remains the default
- - [ ] More complex behavior is optional and thereby configurable
---

## AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [x] No
- - [ ] Yes (**explain below**)

If yes, please specify:

- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation)
- Which parts of the change were influenced or generated
- Whether the result was manually reviewed and adapted

AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB
logic. We expect contributors to be honest
about what they do and do not understand.

---

## Final Checklist

- - [x] Stability is not compromised
- - [x] Performance impact is understood, tested, and acceptable
- - [x] Added logic complexity is justified and explained
- - [x] Documentation updated if needed

---

## Notes for Reviewers

Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
 2026-03-06 07:58:32 -08:00
kadeshar
28a888b6e0
Added unobtainable items to config (#2133) 
# Pull Request

Moving hardcoded values to config

## How to Test the Changes

- use maintenance command
- unequip and destroy item get from this command
- turn off server
- add item to config
- turn on server
- use maintenace command
- check that different item was provided

## Complexity & Impact

Does this change add new decision branches?
- - [X] No
- - [ ] Yes (**explain below**)

Does this change increase per-bot or per-tick processing?
- - [X] No
- - [ ] Yes (**describe and justify impact**)

Could this logic scale poorly under load?
- - [X] No
- - [ ] Yes (**explain why**)
---

## Defaults & Configuration

Does this change modify default bot behavior?
- - [X] No
- - [ ] Yes (**explain why**)
---

## AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [X] No
- - [ ] Yes (**explain below**)

---

## Final Checklist

- - [X] Stability is not compromised
- - [X] Performance impact is understood, tested, and acceptable
- - [X] Added logic complexity is justified and explained
- - [X] Documentation updated if needed

---

## Notes for Reviewers
 2026-03-06 07:56:53 -08:00
Rikus Louw
ea60b38eb9
Add Serpentshrine Cavern attunement quest to bot factory (#2136) 
# Pull Request

I've being getting ready to test Serpentshrine Cavern strategy on
`test-staging`, but noticed the bots don't currently have attunement
setup.

Added attunement quest.

---

## Design Philosophy

We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.

Principles:

- **Stability before intelligence**  
  A stable system is always preferred over a smarter one.

- **Performance is a shared resource**  
  Any increase in bot cost affects all players and all bots.

- **Simple logic scales better than smart logic**  
Predictable behavior under load is more valuable than perfect decisions.

- **Complexity must justify itself**  
  If a feature cannot clearly explain its cost, it should not exist.

- **Defaults must be cheap**  
  Expensive behavior must always be optional and clearly communicated.

- **Bots should look reasonable, not perfect**  
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those
principles.

---

## Feature Evaluation

Please answer the following:

- Describe the **minimum logic** required to achieve the intended
behavior?
- Describe the **cheapest implementation** that produces an acceptable
result?
- Describe the **runtime cost** when this logic executes across many
bots?

---

## How to Test the Changes

- Add bots and convert to raid
- Make sure you have attunement by completing
[this](https://www.wowhead.com/tbc/quest=13431/the-cudgel-of-kardesh)
quest
- Teleport to SSC and summon bots. The bots should appear in the raid.

## Complexity & Impact

Does this change add new decision branches?
- - [x] No
- - [ ] Yes (**explain below**)

Does this change increase per-bot or per-tick processing?
- - [x] No
- - [ ] Yes (**describe and justify impact**)

Could this logic scale poorly under load?
- - [x] No
- - [ ] Yes (**explain why**)
---

## Defaults & Configuration

Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)

This adds the attunement quest for SSC by default

If this introduces more advanced or AI-heavy logic:
- - [x] Lightweight mode remains the default
- - [ ] More complex behavior is optional and thereby configurable
---

## AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [x] No
- - [ ] Yes (**explain below**)

If yes, please specify:

- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation)
- Which parts of the change were influenced or generated
- Whether the result was manually reviewed and adapted

AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB
logic. We expect contributors to be honest
about what they do and do not understand.

---

## Final Checklist

- - [x] Stability is not compromised
- - [x] Performance impact is understood, tested, and acceptable
- - [x] Added logic complexity is justified and explained
- - [x] Documentation updated if needed

---

## Notes for Reviewers

Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
 2026-02-23 11:02:11 -08:00
privatecore
2f7dfdbbfc
Fix rest of trainers' related stuff + codestyle changes and corrections (#2104) 
# Pull Request

* Fix the rest of the trainer-related functionality: list spells and
learn (cast vs. direct learn) spells.
* Rewrite `TrainerAction`: split the logic between appropriate methods
(`GetTarget`, `isUseful`, `isPossible`) instead of pushing everything
inside a single `Execute` method.
* Change method definitions to remove unnecessary declarations and
parameters overhead.
* Move the `Trainer` header into the implementation. Rewrite
`RpgTrainTrigger` to fit the original logic and move all validation to
`RpgTrainAction` (`isUseful` + `isPossible`).
* Implement "can train" context value calculation to use with
`RpgTrainTrigger`.
* Update and optimize "train cost" context value calculation -- it
should be much faster.
* Replace `AiPlayerbot.AutoTrainSpells` with
`AiPlayerbot.AllowLearnTrainerSpells` and remove the "free" value
behavior — please use `AiPlayerbot.BotCheats` if you want bots to learn
trainer's spells for "free".
* Add `nullptr` checks wherever necessary (only inside targeted
methods/functions).
* Make some codestyle changes and corrections based on the AC codestyle
guide.

---

## Design Philosophy

We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.

Principles:

- **Stability before intelligence**  
  A stable system is always preferred over a smarter one.

- **Performance is a shared resource**  
  Any increase in bot cost affects all players and all bots.

- **Simple logic scales better than smart logic**  
Predictable behavior under load is more valuable than perfect decisions.

- **Complexity must justify itself**  
  If a feature cannot clearly explain its cost, it should not exist.

- **Defaults must be cheap**  
  Expensive behavior must always be optional and clearly communicated.

- **Bots should look reasonable, not perfect**  
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those
principles.

---

## How to Test the Changes

Force bots to learn spells from trainers using the chat command `trainer
learn` or `trainer learn <spellId>`. Bots should properly list available
spells (`trainer` command) or learn them (based on configuration and
command).

## Complexity & Impact

- Does this change add new decision branches?
    - [x] No
    - [ ] Yes (**explain below**)

- Does this change increase per-bot or per-tick processing?
    - [x] No
    - [ ] Yes (**describe and justify impact**)

- Could this logic scale poorly under load?
    - [x] No
    - [ ] Yes (**explain why**)

---

## Defaults & Configuration

- Does this change modify default bot behavior?
    - [x] No
    - [ ] Yes (**explain why**)

If this introduces more advanced or AI-heavy logic:

- [x] Lightweight mode remains the default
- [ ] More complex behavior is optional and thereby configurable

---

## AI Assistance

- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
    - [x] No
    - [ ] Yes (**explain below**)

If yes, please specify:

- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation)
- Which parts of the change were influenced or generated
- Whether the result was manually reviewed and adapted

AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB
logic. We expect contributors to be honest
about what they do and do not understand.

---

## Final Checklist

- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [x] Added logic complexity is justified and explained
- [x] Documentation updated if needed

---

## Notes for Reviewers

Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.

---------

Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
 2026-02-23 11:00:24 -08:00
Keleborn
3db2a5a193
Refactor of EquipActions (#1994) 
#PR Description 

The root cause of issue #1987 was the AI Value item usage becoming a
very expensive call when bots gained professions accidentally.

My original approach was to eliminate it entirely, but after inputs and
testing I decided to introduce a more focused Ai value "Item upgrade"
that only checks equipment and ammo inheriting directly from item usage,
so the logic is unified between them.

Upgrades are now only assessed when receiving an item that can be
equipped.

Additionally, I noticed that winning loot rolls did not trigger the
upgrade action, so I added a new package handler for that.


Performance needs to be re-evaluated, but I expect a reduction in calls
and in the cost of each call.

I tested with bots and selfbot in deadmines and ahadowfang keep.

---------

Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
 2026-02-08 12:41:33 +01:00
Crow
8585f10f48
Implement Serpentshrine Cavern Strategies (#1888) 
Edited: Below description of methods were brought up to date as of the
PR coming off of draft.

### General
I've starting leveraging, to the extent possible, an out-of-combat
method to erase map keys. This is mostly useful for timers that need to
start upon the pull because I dislike having to rely on a check for a
boss to be at 100% HP (or 99.9% or whatever) because it can be
unreliable sometimes.

### Trash
Underbog Colossi: Some Colossi leave behind a lake of toxin when they
die that quickly kills any player that is standing in it. The pool is a
dynamic-object-generated AoE, and bots will not avoid it on their own (I
think because the AoE is out of combat, plus the radius is much larger
than the default avoidance radius in the config). The method does not
require bots to be in combat, and simply gets bots to run out of the
toxin. You will probably still get a couple of idiots who drink in the
middle of it, but in my experience, the vast majority of the raid gets
out, and healers that escape can easily keep up a couple of fools until
they've drank to full.

Greyheart Tidecallers: Bots will mark and destroy Water Elemental Totems
immediately.

### Hydross the Unstable
The strategy uses 2 tanks, with the main tank assigned to the frost
phase and the 1st assistant tank assigned to the nature phase.

- The main tank will tank the frost phase, and the first assistant tank
will tank the nature phase. They each have designated spots and will
wait at their spots twiddling their thumbs while Hydross is in the other
phase.
- Hunters will misdirect to the applicable tank upon the pull and after
each phase change.
- The phase change process begins 1 second after Hydross reaches 100%
Marks. The current tank will begin moving to the next phase tank's spot
for the next tank to take over as soon as Hydross transitions.
- DPS is ordered to stop after Hydross reaches 100% Marks until 5
seconds after he transitions.
- Bots will prioritize the elementals adds after every phase change,
unless Hydross is under 10% HP, in which case they should ignore the
adds and burn the boss.
- Ranged bots should spread during the frost phase to mitigate the
impact of Water Tombs.

### The Lurker Below

- There is a designated spot for the main tank.
- Ranged DPS will fan out over a 120-degree arc that is centered
directly across from the tank spot (to try to spread to reduce Geyser
damage while also keeping them behind Lurker).
- When Spout begins, all bots will run around behind Lurker. The intent
is to keep a distance with a radius of 20 or 21 yards and within 45
degrees (either side) of directly behind him. Movement is specifically
tangential along an arc so bots don't run in front of Lurker.
- Spout's duration is tracked by a timer. The mechanics of the spell
itself are rather unique and don't involve a continuous cast or aura to
track easily so I settled for the timer.
- If you have 3 (or more) tanks, each of the first 3 tanks will be
assigned to one of the 3 Coilfang Guardians during the submerge phase.

### Leotheras the Blind
The fight is designed for a Warlock tank. You can choose the Warlock
tank by giving a Warlock the Assistant flag. If you don't do that, your
highest HP Warlock will be picked. Do NOT switch the Warlock tank to a
co +tank strategy--the designated Warlock is hardcoded to spam Searing
Pain on Demon Leo and otherwise will engage in normal DPS strategies. If
you don't have a Warlock at all, the strategy has some methods built in
to try to make things work as best as possible with a melee tank.

- The Spellbinders get marked with skulls and killed in order.
- There is no designated spot or designated tank for the human phase.
Your tanks will fight for aggro. Ranged bots will attempt to keep some
distance, and when Whirlwind starts, everybody will run away from
Leotheras.
- During the demon phase, your melee tanks should take a backseat to
your Warlock tank, who will receive help in the form of Misdirection.
Bots will get the hell away from the Warlock tank so the Warlock tank
should be taking every Chaos Blast alone.
- During the final phase, your regular tanks will tank Leotheras, and
the Warlock tank will tank his Shadow. The melee tanks will attempt to
separate Leotheras from his Shadow so bots can focus down Leotheras
without getting hit with Chaos Blasts.
- Bots will wait 5 seconds to DPS after every transition into human
phase, 12 seconds to DPS after every transition into demon phase, and 8
seconds to DPS after the transition into the final phase. There is no
waiting on DPS after Whirlwinds, even though it would be ideal. It's not
a big deal to live without, and for various reasons, it would have been
a pain in the ass to deal with.
- Bots will save Bloodlust/Heroism until after Spellbinders are down.
- To deal with the Inner Demons, I disabled DPS assist for bots who are
targeted and force them to focus only on their Inner Demons. This is
sufficient in my experience for all DPS bots and Protection Warriors and
Paladins to kill their Inner Demons, even at 50% damage. Feral Tank
Druids and Healers still need help, so the strategy hardcodes their
actions while fighting Inner Demons. For example, Resto Druids are coded
to shift out of Tree Form, cast Barkskin on themselves, and just spam
Wrath until the Inner Demon is dead. There are no bot strategy changes
used for this method.

### Fathom-Lord Karathress
You will need 4 tanks. Your main tank will tank Karathress, and an
assistant tank will tank each Fathom Guard. If you have fewer than 4
tanks, then the priority order for tank assignment will be Karathress,
Caribdis, Sharkkis, and then Tidalvess.

- Roughly, the tank spots are (1) for Karathress, near where he starts
but closer to the ledge for LoS reasons, (2) for Sharkkis, North from
his starting location on the other side of the ramp, (3) for Tidalvess,
Northwest from his starting location near the pillar, and (4) for
Caribdis, far to the West of her starting position, near the corner.
- Note that the tanks will probably clip through the terrain a bit when
going to their positions. This is due to me implementing a forced MoveTo
to the tank position coordinates. There is something weird about the
maps in Karathress's room, and the tanks will take some really screwed
up paths without making them go directly to the exact coordinates. So
this looks stupid but is necessary.
- One healer will be assigned to heal the Caribdis tank. Because AC
Playerbots does not yet have a focus heal strategy, this just means that
such healer has a designated location near the Caribdis tank's location.
This healer can be selected with the Assistant flag.
- Hunters will misdirect the Fathom Guards onto their applicable tanks.
If you don't have three Hunters, the priority is Caribdis, Tidalvess,
then Sharkkis.
- DPS will wait 12 seconds to begin attacking. After that, they will
prioritize targets as follows:
- (1): Melee will always prioritize Spitfire Totems as soon as they
spawn. This will continue through the duration of the fight.
- (2): All bots will kill Tidalvess first.
- (3): Melee bots will move to Sharkkis, and ranged bots will move to
Caribdis. I understand this is not the standard kill order for players,
which would have the entire raid kill Sharkkis next. The reasons I have
done this differently are because melee DPS is much stronger with 3.3.5
talents vs. in retail TBC, and because bots get really thrown off by
Cyclones and therefore they struggle to kill Caribdis quickly. You do
not want Karathress below 75% HP before all Fathom-Guards are dead or he
gets a huge damage buff.
- (4) If Caribdis dies first, ranged bots will help with Sharkkis.
- (5) Everybody kills Sharkkis's pet.
- (6) Everybody kills Karathress.

### Morogrim Tidewalker

- The main tank will pull the boss to the Northeast pillar, with the
tank's back against the pillar.
- A hunter will misdirect the boss onto the main tank upon the pull.
- When the boss gets to 26% HP, the main tank will begin moving the boss
to the Northeast corner of the room in preparation for Phase 2 (which
begins at 25%). The tank will move in two steps to get around the
pillar.
- When the boss gets to 25% HP, ranged will follow the main tank to the
corner and stack up right behind the boss. They will also move in two
steps.
- There is no method for melee since they will just naturally follow the
boss anyway.

### Lady Vashj

**Phase 1**:
- The main tank will tank Vashj in the center of the arena.
- If a Shaman is in the main tank's group, that Shaman will attempt to
keep a Grounding Totem down in range of the main tank to absorb Shock
Blast. This should continue in Phase 3.
- Ranged bots will spread out in a semicircle around the center of the
arena.
- If any bot other than the main tank gets Static Charge, it will run
away from other bots. If the main tank gets Static Charge, other bots
will run away from the main tank. This method should continue in Phase
3.
- If any bot is Entangled and has Static Charge, the bot will attempt to
use Cloak of Shadows if it is a Rogue, and Paladins will attempt to use
Hand of Freedom. This method should continue in Phase 3 (with some
modifications).
- Bots will not use Bloodlust or Heroism (saved for Phase 3). Bots will
not use any other major cooldowns, either, such as Metamorphosis (saved
for Phase 2 and 3).

**Phase 2**:
There are two central mechanics to this phase, both of which were
challenging to get bots to execute properly. First is the system of
prioritizing adds. The large playing field and multiple types of adds
coming from random directions make this phase not doable with realistic
DPS under the standard Playerbots target selection system. Therefore, I
took inspiration from liyunfan's Naxx strategy for Phase 1 of Kel'Thuzad
to disable dps assist and create a custom target selection system.

First, a cheat with respect to the Coilfang Striders: 
- Tanks will permanently have the Fear Ward aura applied to them if you
have raid cheats enabled. This allows them to tank the Coilfang
Striders. The standard strategy was to have an Elemental Shaman kite the
Strider around the perimeter of the arena, with ranged players
(including healers) spamming DoTs on the Strider. If you can make bots
do this, then great, but it's far beyond my capabilities. Therefore,
with the cheat, the first assistant tank is responsible for tanking
Striders and keeping them away from Core passers (described below) and
Vashj. Evidently it was (and is, in TBC Classic) possible to tank (and
melee DPS) Striders by wearing a Dire Maul Ogre Suit, which would give
you enough reach to stay out of the Strider's fear. I actually tried
that, and it does not work, either because AC's radiuses are not the
same or just because bots do not maintain the same level of precise
positioning. But anyway, the point is that technically the Striders are
tankable by real players, so maybe that will make you feel better about
using this cheat (it's fine enough rationalizing for me). I found this
fight to be unmanageable without this cheat (i.e., using a method that
would only have bots try to run away from Striders) because each Strider
was guaranteed to wipe out a couple of bots, and you really cannot
afford to lose anyone. YMMV though.
- If cheats are enabled for Striders, Hunters will attempt to Misdirect
the Striders to the first assist tank.
- If cheats are not enabled, bots will attempt to use slows/roots to
stop the Striders. I have some logic for them to use Netherweave Nets,
but I suspect it does not actually work so I may remove it instead of
trying to get it to function properly.

Target priority is as follows:
- Hunters and Mages: Enchanted Elementals, Coilfang Striders, Coilfang
Elites.
- Other Ranged Bots: Elites, Striders, Elementals. 
- Melee DPS: Elementals, Elites.
- Tanks: Elites, Elementals (except if cheats are enabled, the first
assistant tank will instead prioritize Striders and then Elementals)
- Everybody else (basically means healers): Elementals, Elites, Striders
- If there is more than one of the same target, bots will prioritize the
one that is closer to Vashj.
- In all cases, the valid attack ranged is limited so that bots should
not leave the central platform.
- If somehow a bot ends up too far from the center of the room and is
not actively attacking anything, there is logic to make them run back.

Handling Tainted Elementals and the Tainted Core: I will make another
post about this later. It is easily the most complicated strategy I've
ever worked on (far beyond anything on Kael'thas even) so will
necessitate a long explanation. The tl;dr is that there is a chain of
two-to-four bots that receive/pass the Tainted Core before using it on a
Shield Generator, and if you are playing by yourself, you probably need
to turn raid cheats on, in which case there will also be a bot that
teleports to, kills, and loots the Tainted Elementals (i.e., the bots
will then handle the entire sequence of shutting down Shield
Generators).

**Phase 3**:
- The main tank will pick up Vashj immediately and try to keep her away
from Enchanted Elementals.
- DPS will burn down residual adds from Phase 2 in the order of (1)
elementals, (2) strider for ranged only (if you have more than one up,
you're dead), and (3) elites (hopefully you have only one up, but two
with one almost dead is possible).
- Hunters will kill Toxic Sporebats. This works quite well, but they
(and anybody else if ordered to target Sporebats) have a tendency to
levitate up into the pipes at the top of the room when killing the
Sporebats. To counteract this, a method forcibly teleports bots to the
ground if they get more than 2 yards above the ground.
- The Phase 1 Cloak of Shadows/Hand of Freedom method is now expanded to
include bots Entangled in the Sporebat poison pools (with Hand of
Freedom usage prioritized on the main tank).
- There is a specific method to avoid the Sporebat poison pools. The
Vashj tank will move backwards when avoiding poison.

---------

Co-authored-by: kadeshar <kadeshar@gmail.com>
 2026-02-08 12:31:23 +01:00
kadeshar
bebac60c51
test-staging alignment (#2121) 
# Pull Request

Describe what this change does and why it is needed...

---

## Design Philosophy

We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.

Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.

Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.

Principles:

- **Stability before intelligence**  
  A stable system is always preferred over a smarter one.

- **Performance is a shared resource**  
  Any increase in bot cost affects all players and all bots.

- **Simple logic scales better than smart logic**  
Predictable behavior under load is more valuable than perfect decisions.

- **Complexity must justify itself**  
  If a feature cannot clearly explain its cost, it should not exist.

- **Defaults must be cheap**  
  Expensive behavior must always be optional and clearly communicated.

- **Bots should look reasonable, not perfect**  
  The goal is believable behavior, not human simulation.

Before submitting, confirm that this change aligns with those
principles.

---

## Feature Evaluation

Please answer the following:

- Describe the **minimum logic** required to achieve the intended
behavior?
- Describe the **cheapest implementation** that produces an acceptable
result?
- Describe the **runtime 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, bots, specific
configuration)
- Expected behavior and how to verify it

## Complexity & Impact

Does this change add new decision branches?
- - [ ] No
- - [ ] Yes (**explain below**)

Does this change increase per-bot or per-tick processing?
- - [ ] No
- - [ ] Yes (**describe and justify impact**)

Could this logic scale poorly under load?
- - [ ] No
- - [ ] Yes (**explain why**)
---

## Defaults & Configuration

Does this change modify default bot behavior?
- - [ ] No
- - [ ] Yes (**explain why**)

If this introduces more advanced or AI-heavy logic:
- - [ ] Lightweight mode remains the default
- - [ ] More complex behavior is optional and thereby configurable
---

## AI Assistance

Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [ ] No
- - [ ] Yes (**explain below**)

If yes, please specify:

- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation)
- Which parts of the change were influenced or generated
- Whether the result was manually reviewed and adapted

AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB
logic. We expect contributors to be honest
about what they do and do not understand.

---

## Final Checklist

- - [ ] Stability is not compromised
- - [ ] Performance impact is understood, tested, and acceptable
- - [ ] Added logic complexity is justified and explained
- - [ ] Documentation updated if needed

---

## Notes for Reviewers

Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.

---------

Co-authored-by: Crow <pengchengw@me.com>
 2026-02-06 11:55:28 -08:00
Crow
00d19dbf9c
Fix Destro Warlock Glyphs (#2084) 
Updates are only to the config. This PR should be simple. Tl;dr is
destro pve spec is using the wrong glyphs.

Longer explanation--right now, PreMadeSpecGlyph in the config provides
for destro pve spec to use the following Major Glyphs at levels 15, 30,
and 80, respectively: Life Tap, Quick Decay, Conflagrate. Quick Decay is
useless for destro because destro does not cast Corruption except as a
filler instant cast when on the move. Meanwhile, the spec is almost
unplayable without Glyph of Conflagrate, so that should not be withheld
until level 80. After Conflagrate, there are several viable glyphs,
including Life Tap, Incinerate, Immolate, and Imp. I understand Glyph of
Life Tap gets worse over time to the point that you don't want to use
that glyph in ICC, but that's quite late, and it is useful for the vast
majority of the game as a glyph that would actually be available at
level 15. I also understand that Glyph of Immolate does not excel until
high gear levels. Therefore, I decided to use Incinerate as the default
level 80 glyph.

The new order for default glyphs for destro pve for levels 15, 30, and
80 is Life Tap, Conflagrate, and Incinerate, respectively. I also made a
couple of other very minor fixes in the config. No impact on performance
or AI, obviously.

Sidenote: Glyph of Conflagrate is not available at level 30--it requires
level 40, so from 30 to 40, InitGlyphs() will plug in a random glyph for
the second Major slot. This issue applies to many specs, and it's not
avoidable unless InitGlyphs() is broken up into level brackets, which I
think is not worthwhile. I think the better approach for glyphs is to
ensure the right ones are applied at high levels, but with an attempt to
make them usable at lower levels too where possible.
 2026-01-30 21:52:35 +01:00
Crow
34bab48dd4
Correct comment for AutoEquipUpgradeLoot in config (#2045) 
Added a definition for "AddClass bot" and refined the descriptions for "Randombot" and "Altbot" to better reflect their intended use cases.
 2026-01-22 11:01:01 -08:00
Crow
00171a8c82
Minor fixes to .dist descriptions (#1945) 
Clarified that MinEnchantingBotLevel also determines whether maintenance
will socket gems, in addition to applying enchants.

Fixed max iLevel for ZA gear in RandomGearScoreLimit description (iLevel
138 is the max that drops from the final boss, but the 3rd timed chest
gives iLevel 141 equipment).
 2026-01-09 19:57:29 +01:00
Crow
b16789fa54
Remove "potion" strategy from arenas + code cleanups (#1922) 
Lines 481 through 484 are the only substantive changes. Bots were having
the potion strategy added in arenas, and since potions are not allowed
in arenas, this caused them to lock up and attempt to repeatedly drink
potions when under the applicable health or mana trigger thresholds. Now
they won't have the potion strategy in arenas.

Otherwise, I noticed a bunch of magic numbers for spec tabs and so went
ahead and did some refactoring:
1. All references to spec tab numbers now use the appropriate constant
name.
2. A bunch of extra braces were deleted.
3. DEATHKNIGHT_TAB was changed to DEATH_KNIGHT_TAB, and
HUNTER_TAB_BEASTMASTERY was changed to HUNTER_TAB_BEAST_MASTERY, to
reflect the correct names of the class and spec.
4. Deleted some comments that were clearly unneeded. There's much more
that can be cleaned up, and probably the entire logic sequence for
adding/removing strategies in AiFactory.cpp can be redone, but that's
above my pay grade.
 2025-12-30 21:17:14 +01:00
Keleborn
9917863ca1
Feat. Add Fishing action and fish with master. (#1433) 
### Update :Thank you to @notOrrytrout from prompting me to work on
this. Its been a huge learning experience.

With @notOrrytrout I started working on enabling bot fishing with
master, but also on their own.
The first commit didnt crash, showing that it was possible to have a bot
cast when master does. Currently it compiles but crashes when you try to
fish with a bot in the group, whether the bot has fishing or not. It
makes me think that the check in FishingValues is broken somehow, but I
cant figure out how.

---------

Co-authored-by: bash <31279994+hermensbas@users.noreply.github.com>
 2025-12-27 19:50:18 +01:00
Crow
934e73ae20
Add Ogri'la and Blackwind Landing to PvP Restricted Areas (#1915) 
This PR adds a couple of neutral quest hubs in Outland to PvP restricted
areas (and makes a couple of very minor formatting fixes to the Karazhan
files).

3786: Ogri'la
3973: Blackwind Landing (Sha'tari Skyguard quest hub in Skettis)
 2025-12-15 15:26:38 +01:00
Crow
08c739f918
Align index with section update (#1831) 
Update to index to reflect change to section title
 2025-11-14 15:17:43 +01:00
nick
a37dd2b9ae
Clarify random bot timing configuration section and parameter descriptions (#1826) 
This update reorganizes and rewrites the random bot timing configuration
section for clarity and accuracy. The previous section was mislabeled as
"INTERVALS" and lacked precise descriptions. The new version:

1. Renames the header to RANDOM BOT TIMING AND BEHAVIOR
2. Adds concise, standardized comments for each parameter
3. Corrects misleading terminology (not all values are intervals)
4. Documents defaults and actual behavior clearly for easier tuning and
maintenance
5. No functional code changes — documentation and readability only.

Note, this is derived information from reading the code.
Please double check if I have captured each param accurately!
 2025-11-11 09:21:13 +01:00
Crow
3260ca1429
Cleanups to config and source (#1720) 
* general edits

* Clarify comment for bot teleportation map IDs
 2025-10-14 15:43:18 +02:00
Yunfan Li
e1fa733aa5
Preparation for project transfer (#1733) 2025-10-14 00:11:54 +08:00
bash
377ac199a7
Revert "Feat: Filter bot logins by level range" (#1705) 2025-10-03 22:58:30 +02:00
IainD92
2a340ce68f
Update playerbots.conf.dist (#1698) 
Removed comments from the end of lines (results in bad value)
 2025-10-03 14:19:17 +02:00
IainD92
f2b5580495
Maintenance config for altbots (#1693) 
* Maintenance config controls

bools in config

* Update TrainerAction.cpp

removed some note-to-selfs (personal config preferences)

* Set default to true

Also tidied up some comments

* Update playerbots.conf.dist

* Reorganised

Changed the description in conf to be less conversational.

Rearranged the order that options are arranged, grouping by what made sense to me (the type of gameplay made easier/skipped by the option being enabled).

Rearranged the order the variables and method calls are listed in the code to match the order they are presented in the conf to make future maintenance of maintenance (:P) more intuitive.

* Update playerbots.conf.dist

Revert previous commit (change to call order in MaintenanceAction::Execute)

conf settings grouped
 2025-10-03 11:56:16 +02:00
kadeshar
ffa8c6d94a
Merge pull request #1623 from brighton-chi/karazhan 
Implement Karazhan strategy
 2025-10-03 06:30:39 +02:00
kadeshar
1ea17e593a
Merge pull request #1499 from NoxMax/login-range 
Feat: Filter bot logins by level range
 2025-10-01 17:42:39 +02:00
crow
0afeca4300 Merge remote-tracking branch 'upstream/master' into karazhan 2025-09-28 17:06:55 -05:00
Iain Donnelly
6f79193d7a Config option to set max number of guild members in random bot guilds 2025-09-28 14:04:09 +01:00
crow
ec8e9db1ed Merge remote-tracking branch 'upstream/master' into karazhan 2025-09-27 23:03:18 -05:00
bash
c8f32569a8
Merge branch 'master' into login-range 2025-09-28 00:27:05 +02:00
Crow
f5a6194808
Fixed some comments in the config (#1668) 2025-09-27 20:31:06 +02:00
crow
bdfd45c9a0 Merge remote-tracking branch 'upstream/master' into karazhan 2025-09-27 03:22:50 -05:00
Revision
fcb956ec1b Removed unnecessary spaces 2025-09-19 22:43:50 +02:00
Alex Dcnh
e175eb1178
Paladin buff logic: Sanctuary+Kings synergy, role-aware targeting, safer Greater buffs (#1603) 
* Paladin buff logic: Sanctuary+Kings synergy, role-aware targeting, safer Greater buffs

* Update PaladinActions.cpp

* Update PaladinActions.cpp

* All configs should be implement into PlayerbotAIConfig and sPlayerbotAIConfig used in code

* added: prayer of fortitude

* Magic number removed

* Update PaladinActions.cpp

* Update PaladinActions.cpp

* Update PaladinActions.cpp

* Update PaladinActions.cpp

* Update PaladinActions.cpp

* Add patch for solo paladin in group

* Correction review

* Update PaladinActions.cpp

* Add harcoded text to DB
 2025-09-18 19:52:26 +02:00
Crow
a41abb54cb
Corrected inaccuracy in config comment 2025-09-16 14:51:23 -05:00
ThePenguinMan96
b388657bf6
Shaman Overhaul (#1566) 
* Shaman Overhaul

Hello everyone,

I bring to you the Shaman Overhaul. This was the most fun project I've had so far.
Here is a simplified list of the changes this brings:

1. Added Call of the Elements - making the shaman able to set 4 totems down simultaneously! This saves them multiple global cooldowns in combat.

2. Totems are now selected based on their combat strategies. These strategies set totems on the Call of the Elements bar, as well as change what totem is summoned if a single totem is missing. NOTE: Only one strategy of each elemental type (earth, fire, water, air) can be active at a time.
Earth - strength of earth, stoneskin, tremor, earthbind
Fire - searing, magma, flametongue, wrath, frost resistance
Water - healing stream, mana spring, cleansing, fire resistance
Air - wrath of air, windfury, nature resistance, grounding

There are a few exceptions to totems without strategies: Stoneclaw Totem, Fire Elemental Totem, and Mana Tide Totem. These each have triggers that fire under certain conditions:
Stoneclaw Totem: Resto/Ele shaman has low health and isn't in a group
Fire Elemental Totem: Boost trigger for Ele/Enhance
Mana Tide Totem: Resto Shaman medium mana

3. Added Totemic Recall - a spell that picks up the totems outside of combat to regain 25% of the mana spent. Useful to avoid patrols.

4. Changed the config slightly - Enhance uses Fire Nova Glyph for crazy AoE damage, and enhance pve spec uses both clearcasting and improved shock talent now.

5. Enhancement Shamans will use their Spirit Wolves' Spirit Walk ability - this helps them close the gap and improves their DPS on fights that require movement.

6. Boost Strategy - Moved Bloodlust/Heroism/Fire Elemental Totem from the generic strategy triggers to a new Boost strategy. Now you can control their uses with Boost! (co +boost or co -boost. Enabled by default.)

7. AoE Strategy - Unified both of the AoE strategies for Ele/Enhance to "aoe", rather than "caster aoe" and "melee aoe". NOTE: Healers will still aoe under "healer dps". (co +aoe or co -aoe. Enabled by default.)

8. Moved the weapon imbue strategies from combat to non-combat. I noticed that they were only casting their weapon imbues during combat - this fixes that.

9. Added logic for only using Lava Burst on targets with Flame Shock active, ensuring that it's as close to 100% crit chance as possible. I did notice on a sample size of 112 lava bursts in testing that it still fails to crit around 3 percent of the time - that is because the lava burst starts to cast while flame shock is on the target, but by the time the projectile lands, flame shock has worn off.

10. Added Earth Shock as an execute ability for elemental shamans only. This helps their DPS tremendously at low levels, as well as in PVP. There is logic in place to prevent the use of Earth Shock as elemental entirely on bosses (it's garbage on bosses), as it will only be used as an execute if the target has less than 1500 hp and it's at 25% hp or less.

10. Added chain lightning as an AoE option for enhancement shamans while maelstrom weapon is at 4 or 5 stacks. This continues to push the AoE dps on enhance higher!

Here is a file-by-file list of the changes:

conf\playerbots.conf.dist - Enhancement shamans use Fire Nova Glyph as early as level 15, they also use the clearcasting talent in elemental and improved shocks in enhance. It really helps their mana usage. Also swapped the position of two glyphs in resto.

src\AiFactory.cpp - Set the default spec that new altbot shamans start as to Elemental. Put Arcane, Fire, and Frost comments on the mage specs. Set the strategies of the shaman specs to "ele, resto, and enh", as well as added the default totem strategies for each spec. Also added in the aoe strategy. Removed bmana/bdps, as those were set for lightning/mana sheld - those have been moved to both the non-combat strategy, as well as to each spec combat strategy. Enhancement will use Lightning Shield, and Elemental and Resto will use Water Shield both in and out of combat.

src\strategy\shaman\CasterShamanStrategy.cpp/CasterShamanStrategy.h - Renamed to Elemental.

src\strategy\shaman\ElementalShamanStrategy.cpp/ElementalShamanStrategy.h - Renamed from CasterShamanStrategy, most logic is the same. Moved the totem of wrath passthrough to the GenericShamanStrategy. Moved the Weapon Imbue to the NonCombatShamanStrategy. Moved the AoE spells to GenericShamanStrategy, under the AoE strategy there. Added the use of Stoneclaw totem, as well as Earth Shock Execute. Changed the use of Thunderstorm from medium mana to high mana, so it can be used more often in longer fights. Moved the individual casting of totems to the totem strategies. Added the use of Call of the Elements.

src\strategy\shaman\EnhancementShamanStrategy.cpp/EnhancementShamanStrategy.h - Renamed from MeleeShamanStrategy. Moved the totem passthroughs to GenericShamanStrategy. Refined the priorities in the default actions and triggers to closer match guides online. Moved the weapon imbues to the non-combat strategy. Moved the individual casting of totems to the totem strategies. Moved the AoE spells to the AoE strategy in GenericShamanStrategy. Added the use of Call of the Elements (while in melee range) and Spirit Walk.

src\strategy\shaman\GenericShamanStrategy.cpp/GenericShamanStrategy.h - Moved weapon imbue passthroughs to non-combat. Set up all totem passthroughs here so lower level shamans could function well. Set up a boost strategy for heroism/bloodlust/fire elemental totem. Set up an AoE strategy for Elemental/Enhancement. Cleaned up tablature of the code. Moved the Healer DPS strategy to the RestoShamanStrategy. Added a medium mana trigger so they can use more mana potions in longer fights.

src\strategy\shaman\HealShamanStrategy.cpp/HealShamanStrategy.h - Renamed to RestoShamanStrategy.

src\strategy\shaman\MeleeShamanStrategy.cpp/MeleeShamanStrategy.h - Renamed to EnhancementShamanStrategy.

src\strategy\shaman\RestoShamanStrategy.cpp/RestoShamanStrategy.h - Renamed from  HealShamanStrategy. Moved weapon imbue to non-combat strategy. Moved the individual casting of totems to the totem strategies (except mana tide totem). Added in Healer DPS from genericshamanstrategy. Added in use of Stoneclaw totem and Call of the Elements.

src\strategy\shaman\ShamanActions.cpp/ShamanActions.h - Organized the actions by type. Removed the TTL check in the totem action and Flame Shock. Added logic in the Stoneclaw totem to only be used when not in a group. Added logic on LavaBurst Action to only be used when the target has flame shock debuff from the caster. Added custom logic for casting Spirit Walk (no code exists in AC/Playerbots to make a guardian cast a spell). Added in the "SetXTotemAction"s, which set a totem to the highest rank of the spell in the totem bar.

src\strategy\shaman\ShamanAiObjectContext.cpp/ShamanAiObjectContext.h - Cleaned up strategies, triggers, and actions as a whole. Renamed melee, heal, and caster to ele, enh, and resto. Changed the "totems" strategy to individualized elemental totem strategies.

src\strategy\shaman\ShamanNonCombatStrategy.cpp/ShamanNonCombatStrategy.cpp - Moved weapon imbues here. Cleaned up tablature. Added the Totemic Recall spell.

src\strategy\shaman\ShamanTriggers.cpp/ShamanTriggers.h - Removed the commented out section. Added triggers + logic for:
EarthShockExecute
Call of the Elements
Totemic Recall
"SetXTotemTrigger"
Spirit Walk
Elemental Mastery
No Earth/Fire/Water/Air Totem

src\strategy\shaman\TotemsShamanStrategy.h - Master hub for all defined constants and arrays used in other files, as well as names all of the totem strategy types.

src\strategy\shaman\TotemsShamanStrategy.cpp - Each strategy has a "set x totem" to change the bar totem, as well as a "no x totem" trigger with a corresponding "cast x totem". NOTE: some totems aren't learned by level 30 when a shaman learns call of the elements, so I had to set an alternative for those (Totem of Wrath, Wrath of Air, Cleansing Totem, and Windfury). Testing showed me that this is necessary - without this, the trigger would just fire over and over, and the shaman would recast the same totem over and over.

Scope of Testing:

8/5/25 (2 hours): Began work on the Shaman class. Cleaned up actions and triggers.
8/6/25 (3.5 hours): Tried what felt like everything to get the totem bar changed. Seems impossible to change a client-side thing with cpp.

8/9/25(3 hours): Initial totem strategies created. Through the help of Revision, I was able make a functioning action that would change the totem bar's spell. The spells are stored in the database! I was able to get a strategy of each type working, and Call of the Elements was casting the correct totems.

8/10/25 (3.5 hours): Testing on Noth the Plaguebringer. The elemental shaman's dps was low - I noticed that the shaman was casting lava burst regardless of if the target had flame shock. I fixed this. I also noticed that the enhancement shaman was casting call of the elements at max range, resulting in the magma totem never doing damage. Changed so enhance would only cast  Call of the Elements in melee range. Also, had to add "cast x totem" spells to each strategy, so magma totem would recast once expired (as well as other totems).

8/11/25 - (2.5 hours)Did a full run of Naxxramas. Enhancement did crazy dps for the gear it had. Elemental was consistently placing between 14-18th place of 18 dps. I noticed that totemic recall was messing up with the KT encounter, and had to look in the AC repo for logic to check if a boss encounter is active. Fixed it, and shamans weren't spamming totemic recall between packs. I wonder what I can do to fix elemental?

8/12/25 (1.5 hours) - Added a check in lava burst's isuseful to ensure flame shock was on the target. DPS went up a little bit. Also, made chain lightning the highest spell priority - DPS went up quite a bit after that. It is quite costly, but it is worth it - even on one target, but especially 3. Added spirit walk for enhancement.

8/13/25 - (5 hours) Tested on level 1-10 level, 15, 25, 35, 45, and 55 instances: I had a ton of bugs at level 35. Essentially, the shaman was standing there casting the totems it didn't know (wrath, cleansing, wrath of air). I had to add some checks and passthroughs for it to run smoothly again. Elemental was still doing just okay dps at lower levels, while enhancement was CRUSHING it. The fact that enhancement has the fire glyph from 15 on now is crazy.

8/14/2025 (2 hours) - Tested in 65/75 instances, as well as little bit of ulduar. I am pretty happy with the state of shamans now, they are consistently performing highly (enhance top 5, elemental top 8 in ulduar). Tweaked elemental mastery to cause lava burst to be instant cast, not chain lightning. This improved the DPS of elemental shamans right out of the gate.

Total testing - 23 hours

If y'all have any questions or comments, please let me know either here or on discord!

* Fixed the Bracket so the code will compile

Fixed the Bracket so the code will compile

* - Code refactoring

* - Non windows compilation error fixes

---------

Co-authored-by: kadeshar <kadeshar@gmail.com>
 2025-09-16 20:09:00 +02:00
St0ny
2c383339d8
Update playerbots.conf.dist (#1635) 
* Update playerbots.conf.dist

Added Half-Burried Bottle to the list of dissallowed GO's

* Update PlayerbotAIConfig.cpp

Added Half-Burried Bottle to the list of disallowed GO's in the standard values of the source to complete this PR
 2025-09-15 20:26:36 +02:00
kadeshar
20025b7dfa
- Added quests ending death knight questline to by default enable LFG for them (#1633) 2025-09-14 10:48:47 +02:00
Revision
19399c6f57 Implement Karazhan strategy 2025-09-09 21:23:27 -05:00
kadeshar
a41c1912ac
Merge pull request #1611 from brighton-chi/fix-expansion-limits-for-enchants 
Fix thresholds for LimitEnchantExpansion
 2025-09-06 17:33:23 +02:00
zeb139
bf56154eee
Add weighted bot to banker teleport logic and config (#1615) 
* add weighted bot to banker teleport logic and config

* moved banker location lookup tables to top of file
 2025-09-06 16:10:56 +02:00