Hello everyone,
I was working with hunter bots and I feel like I didn't have enough control over their pets. So I started working on a chat command for the hunter pets, and it's been a blast. Below is a description of what the commands do:
pet name <name>
Summons a tameable pet by its creature name (case-insensitive).
The bot checks if the pet is exotic and requires the Beast Mastery talent if so.
If successful, the bot announces the pet's new name and creature ID.
If not found or not tameable, an error message is given.
pet id <id>
Summons a tameable pet by its database creature ID.
The same exotic pet checks apply.
Success is announced with the pet's name and ID.
Errors are given for invalid IDs or untameable pets.
pet family <family>
Randomly selects and summons a tameable pet from the specified family (e.g., "cat", "wolf").
Only families with tameable pets are considered.
Exotic pet checks and talent requirements apply.
Success is announced with the pet's name and ID.
Errors are given if no suitable pet is found.
pet rename <new name>
Renames the hunter's current summoned pet to a new name.
The name must be 1-12 alphabetic characters (A-Z, a-z) and is automatically formatted (first letter capitalized, rest lowercased).
Forbidden or reserved names are disallowed.
After renaming, the bot sets the new name, saves the pet, and updates the client.
The bot dismisses and attempts to recall the pet using "Call Pet" (if the hunter knows it) to update the UI.
If the new name isn't visible immediately, the bot instructs the player to dismiss and recall the pet manually.
Confirmation and guidance messages are provided.
Additional Details:
All commands display errors if requirements are not met (wrong name/id/family, forbidden name, lack of Beast Mastery, or hunter below level 10).
After changing or summoning a pet (except renaming), the bot initializes the pet and its talents, then announces the result.
TLDR:
pet name <name> Summon a tameable pet by name
pet id <id> Summon a tameable pet by database creature ID
pet family <family> Randomly summon a tameable pet of the given family
pet rename <new name> Rename the current pet and refresh its name in the client UI
Description of files changed:
src\strategy\actions\ChatActionContext.h: Added the "pet" action for the whisper command.
src\strategy\actions\PetAction.cpp: New chat actions for all things related to hunter pets.
src\strategy\actions\PetAction.h: New header for the PetAction.cpp.
src\strategy\generic\ChatCommandHandlerStrategy.cpp: Linked the trigger and action in the chatcommandhandlerstrategy, for the bot to take action when whispered "pet" (trigger).
src\strategy\triggers\ChatTriggerContext.h: Added the "pet" trigger.
- Refactored BattleGroundTactics.cpp
- Bots choose strategies to determine if they are more aggressive or defensive in objectives
- Largely improved bots tactics in WSG, AB, AV and EY
- Improved how bots chase flag carriers
- Fixed some bots stuck in action loops - especially in WSG and AV
- Fixed several other Bugs
PVP Talents and InitGlyph changes
This PR adds 3 pvp specs for each class, as well as their glyphs. It also adds exceptions to the Initglyph function, based on pvp-based talents for each class.
conf\playerbots.conf.dist - Adds 3 pvp specs/glyphs for each class.
src\factory\PlayerbotFactory.cpp - InitGlyph in its current form is unable to correctly assign glyphs on specindexes (or tab) over 2 without an exception. That is why this exception already exists in the code:
if (bot->getClass() == CLASS_DRUID && tab == DRUID_TAB_FERAL && bot->GetLevel() >= 20 && !bot->HasAura(16931))
tab = 3;
This checks if the class is a Druid, if the tab is feral, if they are equal to or above level 20, and they don't have the Thick Hide talent. If all of these are true, then it manually sets the tab = 3. I first discovered this when I noticed that my frostfire mage would never be assigned the correct glyphs in the config - aka glyph of frosfire. It is because the frostfire spec is tab = 3, and no such logic exists. When I started adding the additional pvp specs, I noticed that they never would assign the correct glyphs. I had to add an exception to all pvp specs, and have them check for certain pvp related talents to correlate the tab manually. This is because tab is derived from the AiFactory::GetPlayerSpecTab(bot); function. The only possible tab values from this function are 0, 1, and 2.
**TLDR: Added code to support Frostfire Mage, dual-aura Blood DK, and all the PvP specs for correct glyph assignment.**
src\strategy\actions\ChangeTalentsAction.cpp: When you pick a spec with "talents spec" function, such as "talents spec arms pve", it will now correctly assign glyphs without the player having to execute the maintenance command. Setting the InitGlyphs to false removes prior glyphs.
src\strategy\actions\TrainerAction.cpp - Changed factory.InitGlyphs(true); to factory.InitGlyphs(false);. This makes it so all prior glyphs that were assigned are correctly deleted. I first noticed this when switching between specs and using the maintenance command - I had to login to the bot and manually delete the old glyphs, in order for the maintenance command to assign the new, correct glyphs.
This is a complete overhaul of the warlock class, making 3 new strategies (affliction, demonology, and destruction), as well as finishing the warlock tank strategy (shadow ward and searing pain). It also includes a soulstone fix, where the bots can change who they soulstone based on the non-combat strategies you set for them. It also includes a self-resurrect action and trigger that allows the bots to resurrect using a soulstone or reincarnation. Many other skills were added to finish out the warlock skillset.
* fix: 🚑 Add spellProcFlag check for flag 2 at UseTrinket Context-Action
Bots will "learn" the trinket proc, so CanCastSpell() will be true e.g. on Item https://www.wowhead.com/wotlk/item=44074/oracle-talisman-of-ablution leading to constant casting of the proc spell onto themselfes https://www.wowhead.com/wotlk/spell=59787/oracle-ablutions. This will lead to multiple hundreds of entries in m_appliedAuras -> Once killing an enemy -> Big diff time spikes. See diagnosis
* perf: ⚡ Should futher reduce the problems, hindering trinkets with other proc flags of being used, see https://www.azerothcore.org/wiki/spell_proc_event
I have tested bots with active trinkets and they are still using them, as well as onhit trinkets are still being triggered like they should. Could also fix some other weird behavior.
* CMaNGOS Playerbots "lfg" command implemented
* Remove logging, fix warning, add suggestion
- Remove LOG_INFO's console clutter, since 'lfg' command is working correctly now.
- Warning C26813 fixed for: placeholders["%role"] = (role == BOT_ROLE_TANK ? "tank" : (role == BOT_ROLE_HEALER ? "healer" : "dps"));
- Added suggestion to let bots do autogear & maintenance, so players can instantly start their dungeon or raid activities without manually having to configure the playerbots gear. It could save a lot of time. This is up to discussion for playerbots maintainers.
- Prevent bots from looting Gunship Armory chest in ICC before the event ends (#1162)
- Fix bots being able to loot Tribunal Cache in Halls of Stone multiple times (#1200)
- Ensure bots do not attempt to loot Deathbringer's Cache in ICC before it is available
Three chests (Gunship Armory, Tribunal Cache, Deathbringer's Cache) were tested and now behave as expected: bots will not approach or attempt to loot chests while they are unlootable, even if players move close to them.
Closes#1162, #1200
* feat(playerbots): staggered taxi take-off for bots
Adds four new configurable settings to playerbots.conf:
- AiPlayerbot.BotTaxiDelayMinMs: Min random delay before the 1st follower bot clicks the flight-master
- AiPlayerbot.BotTaxiDelayMaxMs: Upper bound for the overall taxi delay window – larger spreads big raids
- AiPlayerbot.BotTaxiGapMs: Fixed gap added per group-slot so bots never take off together
- AiPlayerbot.BotTaxiGapJitterMs: Extra small randomness added to each gap so launches don’t look robotic
These options allow server owners to fine-tune how bots queue up and take off from flight masters, making their behavior appear more natural.
Closes#1017 : Bots use Flight master nearly the same time.
* fixed build errors
Was missing a header and variable declarations.
Fixes#1276
This change adds logic to detect if an item is a relic and ensures it can only be equipped by bots of the corresponding class:
- Idols are restricted to druids
- Librams are restricted to paladins
- Sigils are restricted to death knights
- Totems are restricted to shamans
Fixes a bug where bots would attempt to equip relics regardless of class restrictions.
Additionally, this commit resolves two unrelated build warnings found in the same file.
Fixes#1179
This update fixes several issues related to bot behavior in battlegrounds when the player dies and releases spirit:
- Removed conflicting strategies (+stay / +follow): Bots were being told to follow and stay simultaneously each tick, causing oscillating movement ("stuttering"). The +stay strategy is now skipped in BGs to allow bots to continue objectives normally.
- Disabled follow while in BG: When the player died, bots attempted to return to the player repeatedly, abandoning objective-based movement. PlayerbotAI now sets -follow while in BGs to keep bots engaged with the objectives.
- Prevented dead bots from following ghosts: Previously, dead bots would follow ghost players away from the graveyard and potentially miss Rez. Bots now wait at the spirit healer when dead in BGs.
- Removed redundant strategy changes and messages in ReleaseSpiritAction as they no longer apply in battleground contexts.
Fix: Better handling of CC state transitions in bot movement:
- Added wasMovementRestricted to track CC status
- Enhanced UpdateMovementState() to detect and react to CC ending
- Triggered movement flag update to fix animation desync
This ensures proper client-server movement synchronization and resolves the visual bug where bots appeared to jump or skip positions. The fix restores the correct movement animation state, replicating the effect previously achieved with the reset or summon commands.
* Fix: Prevents bots from learning spells twice
Added bot->HasSpell() check before calling bot->learnSpell() to ensure the bot does not learn spells it already has.
This avoids redundant behavior, possible unnecessary logging, and inconsistencies in learning spells trained with SPELL_EFFECT_LEARN_SPELL.
* Possible fix
* Add addclass bots to trading list, differentiate between buying and selling.
* typos
* Try calling playerguid
* point IsAddclassBot to IsRandomBot
* typo
* Fix through IsAddClassbot
* Working Version
* Minor typos.
* Group improvement: Bots will no longer auto-invite players who have DND enabled.
* Group fix: Bots will no longer invite self-bots to groups with dnd enabled.
* Invite fix: Bots will no longer invite DnD players from their guild.
* Guild group invite improvement: Lower level guildmembers may now invite higher level players to help them out.
* Crash fix: Bots inviting players into a group that are being teleported.
* Invite fix: Bots will no longer automatically convert to raid when inviting real players.
* Group fix: Bots now properly group up automatically again.
* Group fix: Bots no longer invite themselves to groups from the guild.
* Fix
* Fix build
* New Fix
* .
* ..
* Add RandomBotMinLevelChance
* Save mana only for healer
* Disable addclass dk for low level player
* Target selection and debuff cast with less players in group
* Change default rpg strategy and bots count in config
* Logs clean up
* Improve init=auto
* Remove login logs after initialization
* Rndbots stats for quest
* Prediction chase in reach combat
* Poor & Normal items ensurence for init=auto
