mod-playerbots

mirror of https://github.com/liyunfan1223/mod-playerbots.git synced 2026-06-20 15:39:25 +02:00

Author	SHA1	Message	Date
bash	1a593a6a3c	chore: Tighten inline comments	2026-06-05 10:05:55 +02:00
bash	c87297ff0a	feat(Core/Travel): Enable travel node system for RPG pathfinding (#2312 )	2026-06-05 10:05:54 +02:00
Keleborn	714bb6bca3	Shorten paths (#2396 ) <!-- 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 is designed to significantly shorten the overall path while maintaining the more detailed structure. I tried to follow the principle of removing any folder that had 1 or 2 files in it, shortenining dungeon/raid names to acronyms, and removing instances when the base name was in the file name (Like Raid) etc. ## 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. --> Plan and execute <!-- 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 - - [ ] Stability is not compromised. - - [ ] Performance impact is understood, tested, and acceptable. - - [ ] Added logic complexity is justified and explained. - - [ ] Any new bot dialogue lines are translated. - - [ ] 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-31 18:38:01 +02:00
Crow	92fa97c3aa	Rewrite Equipment-Randomization-Related Configs (#2409 ) <!-- 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 --> The main focus on this PR is to clarify and eliminate overlap between three very confusingly described yet important config options: AutoUpgradeEquip, EquipmentPersistence, and IncrementalGearInit. For context, after initialization, randombots generally get randomized each time after logging in and periodically between MinRandomBotRandomizeTime (configurable, default 2 hours) to MaxRandomBotRandomizeTime (configurable, default 14 days). This randomization happens only when the bot is idle. Now let’s look at what those three config options currently say. - AutoUpgradeEquip: Randombots automatically upgrade their equipment on levelup. - EquipmentPersistence: Enable/Disable bot equipment persistence (stop random initialization) after certain level (EquipmentPersistenceLevel). - IncrementalGearInit: If disabled, random bots can only upgrade equipment through looting and quest None of those descriptions are accurate. - AutoUpgradeEquip determines if randombots, upon leveling up, refresh ammo, reagents, food, consumables, potions, and, ONLY IF IncrementalGearInit is also enabled and EquipmentPersistence is disabled, upgrade equipment (yes, three config options required for this one thing). - EquipmentPersistence affects both equipment and talents. - Disabling IncrementalGearInit does not prevent randombots from changing their equipment through the login/periodic randomization process unless EquipmentPersistence is enabled. These config options shouldn’t overlap with or be dependent on each other, and their names and descriptions should reflect what they actually do. Thus, this PR does the following: - AutoUpgradeEquip solely controls whether or not randombots automatically upgrade their gear upon level up. No other config option is involved for this purpose, and AutoUpgradeEquip no longer impacts inventory items. This does mean that it is no longer possible to stop randombots from being given ammo, potions, etc. when they level up. I tend to think that randombots as they currently are cannot fully function otherwise so I have no issue with the loss of this ability, but if there is disagreement, then we need to introduce a new config option. AutoUpgradeEquip is also now set to true in PlayerbotAIConfig to reflect that the default is true in the .dist. - I originally wanted to combine EquipmentPersistence and EquipmentPersistenceLevel into a single config option that also included talents in the name, but EquipmentPersistence is used in the level brackets mod so I don’t want to make a breaking change there. I settled for making EquipmentPersistence enabled by default and also reducing EquipmentPersistenceLevel to 1 by default, in effect entirely disabling periodic/login randomization of randombot talents and gear by default. I only see people complain about these features so I think unless there is some compelling performance or structural reason to the contrary, the default should be that randombots do not continuously randomize their talents and equipment. - IncrementalGearInit is eliminated. There are two real functional impacts: (1) as noted above, randombots cannot be blocked from receiving standard inventory items upon level-up (though the way it is currently being gated does not make sense anyway), and (2) you can no longer have equipment persistence for equipment only but not talents (I cannot imagine anybody would ever want to do that, and I don't think it was even intended given the strange interaction between config options that was needed to even accomplish that before). - For all these settings, the config descriptions are updated to try to be clear about what the player is actually configuring. Beyond that, I made some clean-up changes to the config to fix some typos and try to shorten it in places, and I also deleted a few config options that do not appear in operative code anymore (and any corresponding references in PlayerbotAIConfig). I also deleted some comments and made some minor style changes in AutoMaintenanceOnLevelupAction.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. The main substance of the PR consists of changes to checks in PlayerbotFactory and AutoMaintenanceOnLevelupAction. ## 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. --> - To test AutoUpgradeEquip, use the gm command .level 1 while targeting an rndbot. - To test EquipmentPersistence, the only way I could find to force an incremental randomization was to use .playerbots rndbot level BotName. This will do an incremental randomization and a level up. However, this level does not go through the AutoMaintenanceOnLevelupAction path so just disregard the +1 level aspect and consider it a pure test of EquipmentPersistence. ## 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 review my changes and come up with the testing method. <!-- 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>	2026-05-30 11:13:18 -07:00
Mat	ff001afd46	Reset instance ID via existing cmd refresh=raid for alt bots (#2422 ) <!-- 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 --> Alt bots can now use refresh=raid cmd if cfg is set to 1. `AiPlayerbot.ResetInstanceIdForAltBots = 1` ## 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. --> Add alt bot, use .playerbots bot refresh=raid and it should say ok after reseting instance. ## 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) Alt bots will now reset instance ID if cfg is set to 1. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (explain below) It will check if cfg is set to 1 to enable alt bots to reset instance id. ## 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>	2026-05-30 11:12:54 -07:00
Lichborne	a3ca438bef	Make .playerbots bot commands case-insensitive (#2419 ) ## Pull Request Description \`.playerbots bot add jared\` fails with "Character 'jared' not found" even when \`Jared\` exists, because the lookup is case-sensitive. Same issue hits \`remove\`, \`init=<...>\`, \`refresh\`, \`addaccount\`, and any other subcommand that takes a character name. Fix at the parser layer in \`HandlePlayerbotCommand\`: every subcommand that takes a charname flows through one shared name-lookup step. Normalize the typed name to canonical form (first letter upper, rest lower) at that step so \`jared\`, \`JARED\`, \`JaReD\` all resolve to \`Jared\`. The \`addaccount\` path still tries the raw token as an account name first (account names are case-insensitive on the auth side), then falls back to a normalized character-name lookup. No subcommand's behavior changes — only the name lookup that precedes them. Subcommands with no charname (\`initself\`, \`list\`, \`reload\`, \`tweak\`, \`self\`, \`lookup\`, \`addclass\`) are unaffected. ## Feature Evaluation - Describe the minimum logic required to achieve the intended behavior. One \`normalizePlayerName(s)\` call on each comma-separated token before the existing \`GetCharacterGuidByName(s)\` lookup. Uses the helper this module already calls in four other places. - Describe the processing cost when this logic executes across many bots. Runs only when a player types a \`.playerbots bot ...\` command, on the typed tokens. Not in any bot-tick or per-bot path. Cost does not scale with bot count. ## How to Test the Changes \`\`\` .playerbots bot add Jared → adds Jared .playerbots bot add jared → adds Jared .playerbots bot add JARED → adds Jared .playerbots bot add JaReD → adds Jared .playerbots bot remove Jared → removes Jared .playerbots bot remove jared → removes Jared .playerbots bot init=auto jared → re-rolls Jared's gear .playerbots bot levelup jared → re-rolls Jared at his current level .playerbots bot refresh jared → refreshes Jared (HP/mana restored) .playerbots bot refresh=raid jared → unbinds Jared from saved raid IDs .playerbots bot add jAred,saLLy,BOB → adds all three .playerbots bot add nonexistent → still reports not found .playerbots bot initself → still works (untouched path) \`\`\` All cases verified in-game. ## 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? - [ ] No - [x] Yes (explain below) Used Claude to help trace the call graph (confirming which subcommands are affected and which are untouched) and to draft the patch. Reviewed and tested in-game before pushing. ## 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 Diff is small (~25 lines in one file). One minor cosmetic side effect: "Character 'X' not found" errors now echo the normalized form (\`Bogus\` instead of \`bogus\`). --------- Co-authored-by: Lichborne-AC <lzeppelin112@gmail.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-30 07:03:22 -07:00
Mat	a1f9ff4542	fix bot leader handling (#2426 ) <!-- 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 fixes bots "freaking out" after leader change and bots will promote player to party leader after give leader command closes #2420 #2424 ## 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. --> 1. Join rdf or make group 2. Promote bot to leader (rnd or alt), if bot was not leader 3. Type /p give leader 4. Bot will promote you to leader and it will follow you instead of freaking out ## 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) 1. Bots now reset their AI on every SMSG_GROUP_SET_LEADER packet, so old leader strategies get cleared after a leader change. 2. Random bots auto-bind their master to a real-player group member during reset botAI, so commands like give leader and follow logic that depend on HasActivePlayerMaster() start working for them. 3. On OnBotLogin, bots no longer steal leadership from a real player, they only force the leader change if the current leader is a bot or offline. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (explain below) Adds two small guards: an "is current leader a real player" check on login, and a "find first real-player member" loop inside ResetAiAction. Both reuse existing patterns (IsRealPlayer(), the OnPlayerLogin master-assign loop). ## 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. -->	2026-05-30 06:48:29 -07:00
Mat	240bb2dfca	Autogear suffixes (#2415 ) <!-- 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 Suffix scoring was already wired up in playerbots, bots could evaluate suffix items they owned, but factory init scored candidates with randomPropertyId = 0 and equipped via EquipNewItem which doesn't roll suffixes, so suffix items always looked like junk and never got picked. Added a cached item_enchantment_template pool in RandomItemMgr, a PickBestRandomPropertyId helper that picks the best suffix per bot class/spec, and added it on the equipped item via SetItemRandomProperties. Tested levels 20-80, suffixes match spec. Closes #2370. ## 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. For items with RandomProperty != 0 or RandomSuffix != 0, run the item_enchantment_template pool once, score each candidate suffix against the bot's existing class/spec stat weights, keep the highest, and stamp that id on the item right after EquipNewItem. Items without a suffix pool skip the helper entirely. Without this, every suffix template scores as base stats only (often near zero) and never gets picked during factory init. - Describe the processing cost when this logic executes across many bots. Startup: one SELECT entry, ench FROM item_enchantment_template (few hundred rows), parsed into an unordered_map<uint32, vector<uint32>> once. No SQL afterwards. Per bot during init: PickBestRandomPropertyId only runs on candidates that actually have a suffix pool. Each call is a hash lookup plus a loop over 5-15 enchantment ids, each doing DBC lookups already used by the scoring code. Cost is mostly by the existing CalculateRandomProperty work, not new logic. Scales linearly with bot count, same as the rest of factory init. No new per-tick work. ## How to Test the Changes 1. Generate a fresh random bot at level 20-79 and use autogear (cloth, leather, mail, plate, lots of suffix gear at that range). 2. Inspect the bot's gear. Items with names like "of the Eagle", "of the Monkey", "of Healing", etc... should be equipped, with the suffix stats visible on the tooltip. 3. Generate a level 80 bot at high gear-score limit. Confirm it still equips raid epics normally (epics have no suffix pool, so this path is untouched). ## 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) Bots now consider random-suffix items during factory init and equip them with the best suffix for their class/spec. Before, suffix items were effectively invisible to init autogear because they scored as base stats only. This is the intended fix for #2370. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (explain below) Added one new public method on StatsWeightCalculator (PickBestRandomPropertyId) and one new cache in RandomItemMgr (LoadEnchantmentPool + GetEnchantmentPool). The candidate list in InitEquipment changed from vector<uint32> to vector<pair<uint32, int32>> to carry the chosen suffix id alongside the item id. Logic mirrors existing patterns in the same files (DBC lookups, SQL-backed caches, signed randomPropertyId encoding), no new abstractions, no new wrappers. ## 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) Used AI to help me find the bug. It mapped the existing scoring pipeline and pointed out that PlayerbotFactory::InitEquipment was scoring candidates with randomPropertyId = 0 and equipping via EquipNewItem (which doesn't roll suffixes), so the scoring side was already built, just never fed real suffix ids during init. I reviewed and tested all the code in-game across levels 20-80 and multiple classes/specs. <!-- 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-05-30 06:48:07 -07:00
Crow	9bba4b78dd	Overhaul party buff/greater blessing system (#2358 ) ## Pull Request Description These changes I originally made for myself because as a person who really likes to raid with bots, I felt like the current group buff system is fundamentally broken, and I needed something more consistent and optimal. I debated a lot whether to PR this because it's such an extensive overhaul that was almost entirely reliant on AI, and I know that wishmaster still has a PR open regarding the greater blessings. I decided to after a couple of conversations so at least people can look at it and see if it's something that they want. The tl;dr version is that this PR overhauls buff handling in two related areas: 1. It adds a dedicated greater blessing assignment system. 2. It generalizes party/raid reagent-buff handling for Paladins, Druids, Mages, and Priests. Under this PR, greater blessings are determined by assignments for the current group, and those assignments are determined based on: 1. a hardcoded priority list of blessings for each spec; 2. the number of Paladins in the group; and 3. whether any Paladins have talents for Blessing of Sanctuary, Improved Blessing of Might, or Improved Blessing of Wisdom. Assignment determinations are cached in a value to avoid constant reevaluation. The exact priority list is: - All casters: Kings, Wisdom, Sanctuary, Might - Physical-only DPS (Rogues, Warriors, DKs): Might, Kings, Sanctuary, N/A - Hybrid DPS (Enh, Ret, Hunters, Cats): Might, Kings, Wisdom, Sanctuary - Druid tanks: Kings, Might, Sanctuary, Wisdom - Warrior and DK tanks: Kings, Might, Sanctuary, N/A - Paladin tank: Sanctuary, Might, Wisdom, Kings Note that Sanctuary is preferred over Kings for Paladin tanks because of the mana regen component but deprioritized for other tanks because Kings provides Agility. The extra 3% damage reduction from Sanctuary does not stack with Disc Priests’ Renewed Hope, which will have 100% uptime. For group buffs, logic is centralized so that class triggers use the same gating and upgrade rules for Gift of the Wild, Arcane Brilliance, Prayer of Fortitude, Prayer of Spirit, and Prayer of Shadow Protection. Also, Shadow Protection is now a default strategy for Priests (rshadow, which existed before but wasn’t added by default). I’ve added a config setting for the greater blessing system and adjusted the current config setting for group buffs. In each case, you can pick whether to disable the feature entirely, use it in all groups, or use it only in raid groups. The default is raid only for greater blessings and all groups for group buffs. Note that for group buffs, even if the config is enabled, they will be used only if at least 3 group/raid members on the same map are missing the buff family. This is mainly to stop group buff spamming during wipe recovery as bots are revived one-by-one. I renamed the Paladin buff strategies to align them with the actual blessing names: - `bhealth` -> `bsanc` - `bmana` -> `bwisdom` - `bdps` -> `bmight` - `bstats` -> `bkings` This is an intentional breaking change for saved strategy strings. Bots will need a one-time strategy reset after update. I removed bots telling you when they are out of reagents for greater blessings. If people like that though, I can add it back. A small cleanup is also included in TankPaladinStrategy: Holy Shield was subject to three overlapping health triggers with the same priority; I removed the two lower health thresholds which have no purpose. ## Feature Evaluation - Describe the minimum logic required to achieve the intended behavior. I’m going to let the AI answer this one. > The minimum logic is: > - a shared config-gated check for whether group/raid buff variants are allowed > - a shared way to treat single and group variants as equivalent aura families > - a shared upgrade path from single-target buff to group buff when the group variant is appropriate > - a Paladin-only cached assignment model that decides which blessing family each Paladin should cover for the current group > - trigger/action wiring that only attempts casts when a group member is actually missing the assigned buff > > This avoids scattering separate per-class heuristics across many triggers and actions. - Describe the processing cost when this logic executes across many bots. Processing cost should be minimal but non-zero. The general party buff changes are limited to existing buff trigger paths and mostly replace duplicated checks with shared helpers. They do not add expensive default per-tick behavior outside those existing trigger evaluations. The Paladin greater blessing logic does add extra decision-making, but it is limited to Paladins, gated by config and group eligibility, subject to a delayed trigger evaluation of only once per 4s, and cached per group assignment set instead of recomputing the full assignment model on every action attempt. This PR also increases the throttle duration for group buff triggers to limit performance impact; I’m open to adjustments to these durations: - Mark of the Wild triggers were increased from 4s to 8s - Arcane Intellect triggers were increased from 4s to 8s - Priest buff triggers were increased to 8s (previously, Fortitude was 6s, Spirit was 4s, and Shadow Protection had no throttle) - There is now a 5s delay on buffing (greater blessings and group buffs) after bots log in—I was getting bots spamming buffs as soon as they logged in even when it was not necessary I’ve tested with pmon, and the impact is minimal—these are very cheap triggers even compared to standard bot rotational ability triggers. ## How to Test the Changes 1. Try different config settings to confirm that they work to enable/disable greater blessings/group buffs in the configured scenarios 2. For greater blessing changes: - test with one Paladin in a party/raid - test with multiple Paladins in a party/raid - confirm the Paladins divide blessing coverage instead of repeatedly overwriting each other - include at least one Paladin with Improved Blessing of Might and make sure it casts Might over Paladins without the talent; check the same with a Paladin with Improved Blessing of Wisdom - do not include a Paladin that knows Sanctuary, confirm any Paladin tank receives Kings instead (you’ll need a low-level Paladin for this since Sanctuary is a prot talent) - confirm bots cast blessings only when a member is actually missing the relevant blessing family - confirm there is a 5s delay on buffing when bots log in 3. For group buff changes: - confirm there is a 5s delay on buffing when bots log in - confirm that single buffs are used when there aren’t at least three unbuffed members in the same map, even if group buffs are enabled in the config 4. For all buffs, test with reagents missing to confirm fallback to single-target buffs and single blessings 5. Confirm the Paladin buff strategy names are changed after resetting AI ## 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) Discussed above in processing costs. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) Yes—that is the purpose of this PR, to change default buffing behavior. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (explain below) Yes, but I think it’s inevitable to add complexity to get greater blessings to function consistently, given the challenges brought by their mechanic of applying across each class. ## AI Assistance Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (explain below) I used GPT-5.4 extensively for this overhaul. It’s much more complicated than I could handle on my own. I’ve done a lot of testing and have reviewed the code and provided plenty of revisions, but I cannot say I can perfectly explain each addition and how it works, not even close. ## 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 --------- 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-05-29 23:08:21 -07:00
ThePenguinMan96	8ca6e42f10	Druid Overhaul (#2392 ) <img width="1274" height="952" alt="druids" src="https://github.com/user-attachments/assets/7390d7e5-ed99-4eb3-8802-8c2f457d7c86" /> Hello playerbots community!! After my pvp gear update, I was itching to get back to class strategies. I was testing raids, and noticed that druids... Well, they kinda sucked. They had glaring issues, would randomly die from bugs, and overall felt bad. Looking at issues discussed on github/discord, I decided to start working on a druid update. I started with the boomkin, and made a boomkin PR, but there were some technical issues with the storing of the eclipse mapping not clearing, and it was not good... I closed that PR, and went back to the drawing board, with one goal in mind: Make the druid class function as best as possible WHILST keeping the code consistent with what already exists. There is a TON of _yoink and twist_ (copy and paste with or without slight edits), and anything that is custom/new is discussed in the section below. I am very proud and excited to release this though - after 45 days of coding and testing, the druid finally feels good to have in the group. Disclaimer - this PR aims to address bugs, utility, and overall performance of Druids. It will not magically make them top DPS. I have done hours of testing, and druids can occasionally top the charts - but inconsistently. Boomkins are inconsistent due to Eclipse (until later gear phases), and Feral Cats are incredibly dependent on positioning, timing, combo points, energy, clearcasting procs... The stars have to align for things to go right for the Cat (It doesn't help that all movement, targeting, and actions are ran through the same engine, so cats really suffer in boss fights with scripted movement) But the changes I have made help those situations occur a fair bit more frequently. Let's dive in! <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> A druid overhaul across all four specs — new Cat stealth and CC systems, Eclipse tracking and rotation fixes for Balance, a Bear threat rotation rework, a Resto healing priority overhaul, and a restructured CC and AoE strategy architecture. --- ## Talent & Glyph Config - Balance: Moved points out of Improved Moonfire and into Nature's Reach for threat reduction and extended cast range. - Bear: Moved points out of King of the Jungle (15% enrage damage) and into Feral Instinct for increased Swipe damage and AoE threat. - Cat: Swapped the Glyph of Typhoon (useless for feral) for Glyph of Dash, which benefits the cat a ton in prowl. - Resto: Swapped Glyph of Rejuvenation for Glyph of Nourish (better HPS for difficult content), and Glyph of Typhoon (useless for resto) for Glyph of Dash. Moved one point from Nature's Bounty to Empowered Touch. --- ## Balance - New skill - Typhoon: Added Typhoon, triggered by "enemy within melee," using cone targeting logic ported from Cone of Cold. Typhoon is from the "balance pvp" spec only, and is housed in the shared AoE strategy. - New skill - Cyclone: Added Cyclone targeting the RTI CC-marked target (default moon). Incapacitates for 6 seconds with full damage immunity — cannot be broken by AoE. Priority 24.0f > Hibernate (23.0f) > Entangling Roots (22.0f). (See CC Implementation in the code notes below.) - Bug fix - Eclipse cooldown tracking: Eclipse procs referenced a cooldown not registered in the database, so boomkins immediately reverted to the wrong filler after an Eclipse buff fell off. Fixed with manual timestamp tracking. (See Eclipse Cooldown Tracking in the code notes below.) - Bug fix — Starfall no longer pulls out-of-combat hostile enemies: Previously fired on cooldown regardless of surroundings — its 36-yard radius (the largest AoE in the game) could silently pull entire unengaged packs. Now suppressed if any non-combat hostile NPC is within 40 yards. (See Starfall Pull Safety in the code notes below.) - Filler changed to Starfire: Starfire is now the filler (priority 5.4) over Wrath (5.3). Starfire has a 100% spellpower coefficient vs. Wrath's 12%, is more mana-efficient per point of damage, and has a 100% eclipse proc chance on crit vs. Wrath's 40%. In practice this significantly reduced mana consumption, especially before level 40 when Moonkin Form's mana-on-crit passive isn't available. - Moonfire / Insect Swarm on Attacker rework: Previously tied to the light AoE trigger (2+ enemies, 13.0f), causing low-level boomkins to multi-dot instead of casting fillers — mana-inefficient at low levels where targets rarely live long enough to tick the full DoT. Re-added as dedicated on-attacker triggers at lower priority than the fillers, so they fire only as a movement fallback. The triggers have been changed to override the TTL check (time to life), similar to the warlocks DoTs. - Hurricane channel check rework: Previously cancelled based on distance from the bot — enemies could leave the AoE but remain within 30 yards, keeping the channel alive. Now reads the Hurricane DynamicObject's actual radius and counts only attackers physically inside it. (See Hurricane Channel Cancel in the code notes below.) --- ## Cat - Prowl (Stealth): Implemented using the same logic as the existing Rogue stealth system. The bot enters Prowl when out of combat and a target is within range. Engagement distances are: - 30 yards baseline - −10 yards if the target already has a victim (engaged in combat) - −10 more yards if the target is also moving (minimum 10 yards) - +15 yards in Battlegrounds or Arenas - Enemy player targets take priority over grind/DPS targets when evaluating distance. - Prowl openers: The bot approaches the target in Prowl and opens based on approach angle and level: - From behind: Ravage (learned at level 32). Before Ravage is learned, Shred is used as the opener. - From the front: Pounce (stun + bleed, learned at level 36). Before Pounce is learned, Claw is used as the opener. - New skill - Maim: Added Maim as a 5 second stun-finisher at 5 combo points, but only against player targets. It will only fire when Rip and Savage Roar are already active. - Innervate on healer: Cats now cast Innervate when a healer drops below the low mana threshold (`AiPlayerbot.LowMana`, default 15%). (See Healer Low Mana Framework in the code notes below for the shared value/trigger infrastructure backing this.) - Predator's Swiftness with CC spells: Added a twotrigger pairing Predator's Swiftness (the instant-cast proc from finishing moves) with the existing CC triggers (Cyclone, Hibernate, Entangling Roots). Feral cats can now instant-cast CC the RTI CC-marked target (default moon) after a finisher using the Predator's Swiftness proc. - Predator's Swiftness with Rebirth: Added a twotrigger pairing Predator's Swiftness with the combat resurrection trigger. Cats can now use a Predator's Swiftness proc to instantly cast Rebirth on a dead party member. - Bug fix - Autoattack no longer breaks prowl: `MeleeAction::isUseful()` now returns false while the bot has the Prowl aura, preventing autoattack from breaking stealth before an opener spell fires. The code comment notes this pattern should be reused for a future Rogue autoattack in stealth fix. - Bug fix - Non-prowl skills no longer break prowl: `isUseful()` overrides were added to Feral Charge (Cat), Mangle (Cat), Swipe (Cat), Rake to return false while Prowl is active, preventing accidental prowl breaks before the opener fires. - Bug fix - Clearcasting proc with energy spells: Added dedicated `ClearcastingTrigger` / action pairings to ensure Clearcasting procs are consumed immediately. On single target, Shred is used; on AoE, Swipe (Cat) is used. This prevents the cat from using it's valuable clearcasting proc on a low energy spell (rake, feral charge - cat, cower, etc). This also fixes a bug where Clearcasting would sometimes linger for 4+ seconds without being used, as energy-based spells do not recognize the free cast and would not fire until their energy condition was met. - Tiger's Fury rework: TF previously fired on cooldown as a default action, meaning the bot would use it at full or near-full energy and gain no benefit from the energy it generates. The trigger now requires energy to be below 30 before firing, ensuring the bot recovers the full 60 energy granted by the King of the Jungle talent. - Faerie Fire (Feral) rework for cat: With Omen of Clarity, spams on cooldown to fish for Clearcasting procs. Without it, applies as a normal debuff and does not reapply while active. (See Faerie Fire (Feral) Trigger in the code notes below.) - Feral Charge toggleable strategy: Feral Charge (Cat) is now housed in a dedicated `feral charge` strategy, enabled by default for Cat druids. It can be disabled with `co -feral charge` and re-enabled with `co +feral charge`. Disabling this strategy can be useful for encounters where charging in would be unfavorable. - Rake on Melee Attackers removed: The Rake on Melee Attackers action was removed from the Cat AoE strategy. Applying Rake to multiple attackers and spreading out combo points produced far lower AoE DPS than simply continuing the single-target rotation. - Antiquated Omen of Clarity framework removed: `OmenOfClarityTrigger` and `CastOmenOfClarityAction` were not functional and have been removed. The `ClearcastingTrigger` appropriately tracks Omen of Clarity procs. I believe this was from TBC when Omen of Clarity was a spell. --- ## Bear - Berserk tracking for Mangle: A `berserk active` trigger fires Mangle (Bear) at priority 25.0f while Berserk is up. Previously, Mangle sat at 5.5f in the default actions while Swipe (Bear) sat at 25.0f on the light AoE trigger — meaning in any 2+ enemy encounter, Swipe would always win regardless of Berserk. Now Mangle (25.0f) sits above the AoE triggers (24.5f), so it takes priority during Berserk. It's pretty cool to see a Bear's dps on pull! - Faerie Fire (Feral) rework: Previously applied once and stopped. Now spams on cooldown for continuous threat generation (~3.5k threat per cast at level 80), and serves as a ranged soft-taunt fallback on the `lose aggro` trigger when Growl is on cooldown. (See Faerie Fire (Feral) Trigger in the code notes below.) - Lacerate rework: Previously, lacerate was a low priority default action and bears had no duration awareness. They would occasionally let 5 stacks of Lacerate fall off, resulting in pretty significant threat loss. Now, `LacerateTrigger` fires when the target has no Lacerate debuff, the stack count is below 5, or the remaining duration is ≤ 6 seconds. - Demoralizing Roar on single target: Previously, Demoralizing Roar only fired on the medium AoE trigger (3+ enemies, skipped on bosses). A dedicated trigger now applies it in any encounter, provided Vindication, Demoralizing Shout, or Curse of Weakness are not already present, as they don't stack with Demoralizing Roar. - Bug fix - Rebirth on bears: Bears no longer attempt to cast Rebirth in combat. The generic combat resurrection trigger was firing for all druid specs, causing bears to shift out of Dire Bear Form mid-fight to cast Rebirth — dropping their armor and HP while still holding aggro. Lots of sudden tank deaths... - Feral Charge toggleable strategy: Feral Charge (Bear) is now housed in a dedicated `feral charge` strategy, enabled by default for Bear druids. It can be disabled with `co -feral charge` and re-enabled with `co +feral charge`. Disabling this strategy can be useful for encounters where charging in would be unfavorable. --- ## Resto - Blanketing strategy: Added a `blanketing` strategy (enabled by default, `co -blanketing` to disable) that pre-HoTs group members with Wild Growth and Rejuvenation regardless of current health, prioritizing tanks → melee → ranged to maximize Revitalize uptime. (See Blanketing Strategy in the code notes below.) - Nature's Swiftness → instant Healing Touch combo: Nature's Swiftness was previously included in the boost strategy, where it would fire proactively on cooldown regardless of context. This wasted the proc on situations where it provided no benefit. It is now exclusively reactive — triggered at high priority (56.0f) when a party member hits critical health. A paired `nature's swiftness active` trigger then immediately fires Healing Touch (55.0f) on the lowest-health party member, consuming the proc as an instant-cast emergency heal. - Lifebloom priority lowered (29.0f → 13.0f): Lifebloom on the main tank is cast on Omen of Clarity procs. At 29.0f it previously outprioritised all low health reactive healing (21.4f), meaning a Clearcasting proc while a party member was at 25–44% HP would cause the bot to cast Lifebloom on the tank instead of Swiftmend or Nourish on the injured target. Lowered to 13.0f so it fires only when no reactive healing is queued. - Healing spell priority order reworked: All three reactive categories (critical, low, medium) now follow the same sequence: Swiftmend → Wild Growth → Nourish → Regrowth → Healing Touch. - Tranquility toggleable strategy: Tranquility is now housed in a dedicated `tranquility` strategy, enabled by default for Resto druids. It can be disabled with `co -tranquility`. In raids, Tranquility only heals the druid's own group — not the full raid — making it situationally poor during raid-wide damage or heavy movement phases. Disabling this strategy lets players suppress the cast on those encounters without affecting the rest of the healing rotation. --- ## CC & Strategy - Boost strategy: The boost strategy is assigned to all druid specs by default. It is spec-gated internally — Balance druids use it for Force of Nature (treants on cooldown), and Feral druids (both cat and bear) use it for Berserk. - CC strategy enabled by default: The CC strategy was previously not assigned to druids by default. It is now enabled for Balance and Feral Cat, with behavior gated by spec: - Balance receives the full RTI CC trigger set (Cyclone, Hibernate, Entangling Roots). - Feral cats only receive RTI CC triggers when Predator's Swiftness is active (see above). - AoE strategy reorganized: All AoE spells — Hurricane, Starfall, Typhoon, Swipe (Cat), and DoTs on attackers (Moonfire, Insect Swarm) — are now handled by the shared AoE strategy, consistent with how the rest of the playerbot project structures AoE logic. This does not affect Bear druids. - Aquatic Form while submerged: The non-combat strategy now shifts into Aquatic Form when the bot is fully submerged out of combat (`LIQUID_MAP_UNDER_WATER`). If the bot is in another shapeshift (Bear, Cat, Moonkin, Tree), it first shifts to caster form as a prerequisite before entering Aquatic Form. The trigger intentionally does not fire at the water surface (`LIQUID_MAP_IN_WATER`), or use the "swimming" trigger, because it caused the druid to loop caster form and aquatic form endlessly while surfaced. --- ## Code Consolidation & Refactoring - The Bear, Cat, Heal, and Caster strategy files have been renamed to Bear, Cat, Balance, and Resto respectively, to match the naming conventions used elsewhere in the project. - The Melee and Offheal strategy files have been deleted. The offheal healing logic is preserved in full — it now lives as an optional strategy (`CatOffhealStrategy`) inside `CatDruidStrategy`, sharing the same action node factories as the base cat strategy rather than duplicating them. - All action relevance values across the druid strategies have been converted from named constants (e.g. `ACTION_NORMAL`, `ACTION_HIGH + 4`) to explicit numerical floats (e.g. `10.0f`, `24.0f`). This makes priority ordering immediately visible in the source without needing to cross-reference the constant definitions. --- ## New Code & Project References ### Eclipse Cooldown Tracking (`DruidActions.cpp`) The previous implementation tracked the Eclipse cooldown using `EclipseSolarCooldownTrigger` and `EclipseLunarCooldownTrigger`, both of which extended `SpellCooldownTrigger` and called `bot->HasSpellCooldown(48517/48518)`. `SpellCooldownTrigger` is the standard project pattern for this — it works correctly for spells whose cooldowns are registered in the database. However, Eclipse (Solar) and Eclipse (Lunar) both have Cooldown: n/a in the DB. `HasSpellCooldown` always returned false, so boomkins never respected the cooldown and would revert to the wrong filler immediately after an Eclipse buff fell off. Since the cooldown can't be read from the DB, the fix tracks it manually. When `CastWrathAction::isUseful()` or `CastStarfireAction::isUseful()` detects that the corresponding Eclipse aura has become active, it records the current timestamp and suppresses the opposing filler for 30 seconds — the actual in-game cooldown duration. The timestamps are stored using `ManualSetValue<time_t>`, the same pattern as `LastSpellCastTimeValue` (`src/Ai/Base/Value/LastSpellCastTimeValue.h`), which is already used throughout the project to record when spells were last cast. Two new value classes — `EclipseSolarProcTimeValue` and `EclipseLunarProcTimeValue` — are registered in a new `DruidValueContextInternal` factory inside `DruidAiObjectContext.cpp`, following the same factory pattern as `DruidTriggerFactoryInternal` and `DruidAiObjectContextInternal` in the same file. Because these values live in the per-bot `AiObjectContext`, they are automatically destroyed when the bot logs out — no manual cleanup needed, and no shared state between bots. --- ### Healer Low Mana Framework (`PartyMemberToHeal.h/.cpp`, `HealthTriggers.h/.cpp`, `ValueContext.h`, `TriggerContext.h`) `HealerLowMana` and `HealerLowManaTrigger` are added to the shared base framework rather than the druid-specific code. Currently used by the Cat Innervate trigger; designed so Mana Tide Totem, Hymn of Hope, and similar spells from other classes can hook into the same trigger without duplicating the group-scanning logic. The pair follows the same pattern as the existing `PartyMemberToHeal` / `PartyMemberLowHealthTrigger` — the project's standard design for "scan the group for the most in-need member, then trigger when that member crosses a threshold." Value (`HealerLowMana : PartyMemberValue`): `Calculate()` walks the group reference list, skips non-healers via the existing `IsHeal()` check, and uses `MinValueCalculator` to return the lowest-mana healer as a `Unit`. Registered in `ValueContext.h` under the key `"healer low mana"`. Trigger* (`HealerLowManaTrigger : Trigger`): `GetTargetName()` returns `"healer low mana"`, which the base `Trigger::GetTarget()` resolves against the value context — exactly how `PartyMemberLowHealthTrigger::GetTargetName()` returns `"party member to heal"`. `IsActive()` calls `GetTarget()` and checks `GetPowerPct(POWER_MANA) < sPlayerbotAIConfig.lowMana`. The trigger doesn't extend `HealthInRangeTrigger` because that class is specifically for health (it reads the `"health"` value). Mana requires a direct `GetPowerPct(POWER_MANA)` call, so a plain `Trigger` with a custom `IsActive()` is used instead. Both are registered in the global `ValueContext.h` and `TriggerContext.h` rather than a class-specific factory, consistent with how all other `PartyMemberValue` subclasses are registered in the project. --- ### Blanketing Strategy (`RestoDruidStrategy.h/.cpp`, `DruidActions.h/.cpp`, `DruidAiObjectContext.cpp`) Strategy structure: `DruidBlanketStrategy` is a standalone `Strategy` overlay, not embedded inside `RestoDruidStrategy`. This is the same pattern as `DruidTranquilityStrategy`, `DruidBoostStrategy`, and `DruidCcStrategy` — additive overlays that layer behavior on top of the base strategy and can be toggled independently via `co +/-blanketing`. Triggers: Both `"wild growth blanket"` and `"rejuvenation blanket"` are instantiated as `BuffOnPartyTrigger(ai, spellName)` — the project's existing class from `GenericTriggers.h` for party-wide buff maintenance, used throughout the codebase for things like Blessings and Mark of the Wild. `BuffOnPartyTrigger` extends `BuffTrigger` and fires when any party member is missing the named aura. No custom trigger class was needed. Actions: Both actions inherit from a shared `CastBlanketHotAction` base that itself extends `CastSpellAction`. Inheriting from `CastSpellAction` means `isPossible()` is handled for free — spell known, off cooldown, target reachable, resources available. The constructor sets `range = botAI->GetRange("heal")` to use the standard healing range. `GetBlanketTarget(auraName)`: The custom part of the implementation. Walks the group in three prioritized passes — tanks first, then melee non-tanks, then ranged — returning the first eligible member found. Eligible is defined as: alive, not a GM, within `spellDistance`, and `!botAI->HasAura(auraName, member, false, true)` (not already carrying the HoT). Returns nullptr if every member is already covered. `isUseful()`: On both actions simply returns `GetTarget() != nullptr` — fires as long as `GetBlanketTarget` finds someone without the HoT, and suppresses itself the moment all targets are covered. --- ### CC Implementation — Cyclone, Hibernate, Entangling Roots (`DruidTriggers.h/.cpp`, `DruidActions.h/.cpp`, `GenericDruidStrategy.cpp`) The druid CC spells use the project's strict RTI-only pattern rather than the fallback "best candidate" pattern used by other classes (e.g., Mage Polymorph). `"rti cc target"` value: A direct raid icon lookup. Reads the `"rti cc"` string value (default `"moon"`, configurable per-bot via `rti cc <icon>`), converts it to a raid icon index, and returns the live `Unit` for that GUID. If no CC icon is set, it returns `nullptr`. There is no fallback to a best-candidate scan. Triggers* (`CycloneTrigger`, `HibernateTrigger`, `EntanglingRootsTrigger`): All three extend `HasCcTargetTrigger` and override `IsActive()`. The first check is always `"rti cc target"` — if it returns `nullptr`, the trigger is immediately silent. If an icon is set, it checks `"cc target"` (with the spell name as a qualifier) to verify the RTI target matches and delegates to `HasCcTargetTrigger::IsActive()`, which handles the "don't re-cast while already CC'd" check. Actions (`CastCycloneCcAction`, `CastHibernateCcAction`, `CastEntanglingRootsCcAction`): All three extend `CastCrowdControlSpellAction` rather than plain `CastSpellAction`. The action names are `"cyclone on cc"`, `"hibernate on cc"`, `"entangling roots on cc"` — not the raw spell names. This matters because `CastSpellAction` stores its constructor argument as both the action name and the spell name, and `isPossible()` calls `CanCastSpell(spell, target)` using that string. Passing `"cyclone on cc"` to `CastSpellAction` would resolve to spell ID 0 and silently return false forever. `CastCrowdControlSpellAction` keeps the spell name separate from the action name, avoiding this. `GetTargetValue()` on all three returns `context->GetValue<Unit>("rti cc target")` directly. Form prerequisite:* The action nodes for `"cyclone on cc"` and `"hibernate on cc"` have `NextAction("caster form")` as a prerequisite, so the bot automatically shifts out of Bear, Cat, or Moonkin form before casting. Entangling Roots has the same prerequisite. Priority order: Cyclone (24.0f) > Hibernate (23.0f) > Entangling Roots (22.0f). Cyclone is preferred because it works on any target type and the target is immune to all damage and healing while cycloned — it cannot be broken by AoE. Hibernate is beast/dragonkin only. Entangling Roots can be broken by damage. Feral Cat CC: Wired through `TwoTrigger` pairings with `"predator's swiftness"` (see Cat section above). Because the Predator's Swiftness proc makes the spell instant-cast, no form shift is needed — the cat casts directly from Cat Form after a finisher. --- ### Ferocious Bite Execute (`DruidTriggers.h`, `DruidCatActions.h`, `CatDruidStrategy.cpp`) Two separate triggers fire the same `CastFerociousBiteAction`, which is a plain `CastMeleeSpellAction` with no custom logic — all the intelligence lives in the triggers. `FerociousBiteTimeTrigger` ("ferocious bite time", 22.5f) — the normal rotation path. Requires 5 combo points, Savage Roar active with >10 seconds remaining, and Rip active on the target with >10 seconds remaining. The duration checks prevent spending combo points on Ferocious Bite when either buff is about to fall off and needs to be refreshed first. `FerociousBiteExecuteTrigger` ("ferocious bite execute", 24.0f) — the execute window, higher priority than the time trigger. Requires only 1 combo point, and fires when the target is below both 25% HP and 20,000 absolute HP. The dual condition is the key design detail: the 25% threshold alone would trigger on a raid boss at 25% health — which could still be millions of HP remaining. The 20,000 HP cap ensures the execute behavior only activates when the target is genuinely close to death, at which point dumping even a partial combo point buildup into Ferocious Bite is better than continuing a normal builder-spender cycle. --- ### Faerie Fire (Feral) Trigger (`DruidTriggers.h`) A single `FaerieFireFeralTrigger` class handles both Bear and Cat with spec-branched behavior inside `IsActive()`. It extends `DebuffTrigger` — the project's standard class for debuff maintenance on the current target — but overrides `IsActive()` to produce three distinct behaviors depending on form and talent state: Bear: Bypasses `DebuffTrigger::IsActive()` entirely. Returns true whenever the target is alive and in world, regardless of whether the debuff is already present. Every cast generates immediate threat and damage, so there is no reason to wait for it to fall off before recasting. Cat with Omen of Clarity (talent aura 16864): Same bypass — spams on cooldown to fish for Clearcasting procs. Faerie Fire (Feral) has no energy cost, making it a free input that can proc Omen of Clarity on any hit. Cat without Omen of Clarity: Falls through to `DebuffTrigger::IsActive()` — the standard base class behavior, which checks: target alive and in world, debuff not already present (`!botAI->HasAura("faerie fire (feral)", target)`), and estimated remaining lifetime of the target is at least `needLifeTime` seconds (default 8.0f — no point applying a 30-second debuff to something about to die). Applied as a normal debuff; does not reapply while active. Both spam paths additionally guard against Prowl — `IsActive()` returns false while the bot has the Prowl aura to prevent casting from breaking stealth. Strategy wiring: - Bear: standard rotation slot at 17.0f, plus wired into the `"lose aggro"` trigger at 25.5f as a soft-taunt fallback when Growl is on cooldown. - Cat: low-priority filler at 5.0f. --- ### Starfall Pull Safety (`DruidActions.cpp`) Starfall's 36-yard AoE radius is the largest in the game. A single cast near an unengaged patrol or mob pack would silently pull everything in that area. The previous implementation fired on cooldown with no awareness of the surrounding area. `CastStarfallAction::isUseful()` now applies two guards before allowing the cast: CC safety check (standard project pattern): reads `"current cc target"` and `"aoe position"`; suppresses the cast if the CC'd target is within `aoeRadius` of the bot's AoE position. Unengaged hostile NPC scan (custom): reads `"nearest hostile npcs"` (`NearestHostileNpcsValue`), which uses the project's standard `Acore::AnyUnitInObjectRangeCheck` + `Cell::VisitObjects` grid searcher at `sightDistance` (~50 yards). The value pre-filters via `AcceptUnit()`: non-players only, and `unit->IsHostileTo(bot)` must be true — this excludes neutral-faction trigger creatures, dummies, and invisible spawns that would otherwise appear in a raw range scan. The loop then applies four additional filters: - Skip null / dead / out-of-world units (standard guard). - Skip the current target — it is the reason we're in combat; its in-combat flag is already covered. - Skip `!bot->IsValidAttackTarget(unit)` — safety net for hostile-faction trigger creatures carrying `UNIT_FLAG_NON_ATTACKABLE` that `IsHostileTo` alone doesn't filter. - Skip units beyond 40 yards — Starfall's listed radius is 36; 40 adds a small buffer for patrols about to enter range. If any remaining unit is `!unit->IsInCombat()`, the cast is suppressed — that mob is unengaged and would be pulled. Why `"nearest hostile npcs"` and not `"attackers"`: `attackers` only contains units currently targeting the bot. We need to scan all hostile units in the area, not just those already aggro'd. --- ### Hurricane Channel Cancel (`DruidTriggers.h/.cpp`, `GenericDruidStrategy.cpp`) The previous cancel condition checked whether fewer than 3 enemies were within 30 yards of the bot. This is a poor proxy — enemies could scatter laterally but still sit within that radius, keeping the channel alive while none of them were taking damage. The replacement is `HurricaneChannelCheckTrigger`, which locates the actual Hurricane `DynamicObject` on the field and measures from it directly. `IsActive()` logic: 1. Checks `bot->GetCurrentSpell(CURRENT_CHANNELED_SPELL)` — if the bot isn't channeling at all, returns false immediately. If it is channeling but the spell isn't a Hurricane rank, also returns false. This check is necessary because `CURRENT_CHANNELED_SPELL` is a slot, not a specific spell — the same cancel action is reused for other channeled spells in the codebase, so the trigger must verify it's specifically Hurricane before acting. 2. Iterates through `HURRICANE_SPELL_IDS` (all five ranks: 16914, 17401, 17402, 27012, 48467) calling `bot->GetDynObject(spellId)` until a non-null result is found. Hurricane places a `DynamicObject` on the field that the server uses as the actual AoE cylinder — each damage tick queries which units are inside it. The DynamicObject is keyed by spell ID, so the trigger must try each rank to find whichever one the bot currently has learned and placed. 3. Reads `dynObj->GetRadius()` — the actual radius stored on the DynamicObject itself rather than a hardcoded constant. This matches exactly what the server uses to calculate damage, so the trigger's cancel condition is spatially identical to the server's hit detection. 4. Walks the `"attackers"` GuidVector and counts how many live attackers are within `dynObj->GetRadius()` of the DynamicObject's position using `unit->GetDistance(dynObj->GetPosition()) <= radius`. 5. Returns `count < minEnemies` (default 3). The trigger fires — cancelling the channel — when fewer than 3 attackers are physically inside the Hurricane AoE. Why `"attackers"` and not a full area scan: Hurricane only deals damage to units that are attacking the bot (or in its threat list). Scanning all nearby hostile units would cause premature cancellation if non-aggro'd enemies happened to be standing outside the AoE. Attackers is the right scope. Strategy wiring: The trigger is paired with `NextAction("cancel channel", 22.0f)` in the AoE strategy for both Balance and Resto druids. The cancel priority (22.0f) sits below the Hurricane cast priority (23.0f), so if the medium AoE trigger re-activates on the same tick the cancel fires — meaning enemies came back into range — the new cast wins over the cancel. --- ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. Most new triggers are simple aura or cooldown checks. The heavier ones are the group scans (for the blanketing HoTs and the healer mana check), but these are identical in cost to group scans already running throughout the project (all of the party member health checks). The Starfall safety check is the only genuinely new scan — it looks for nearby hostile NPCs before allowing a cast, using the same grid search the project already uses elsewhere. That being said, it's loaded on the end of the trigger/action pairing - so in the StarfallNoCDTrigger, the bot has to already have learned starfall, already be in combat, and have Starfall off of cooldown and ready to use. The Hurricane cancel check only runs while the bot is actively channeling, so it's tightly gated. - Describe the processing cost when this logic executes across many bots. Negligible for almost everything in this PR. The vast majority of new logic is aura/buff/debuff lookups and cooldown checks that cost nothing at scale. The group scans for blanketing and healer mana follow the same pattern as existing party scans that already run on every healer bot every tick. No new unbounded operations, no shared state between bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> All druids perform a bit better now - I'd say test the branch out with the druids y'all currently use. JUST REMEMBER TO DO reset botAI or talents spec "x" again, since there have been some strategies changed!! The big one being the blanketing strategy for resto druids. They heal so much better now. Also being able to control when they pre-hot is really great. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) Tested before an after with the same performance logs. I tested it with a 25 man group of only druids versus my normal 25 man group on several raid bosses - no difference in pmon. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) Druid bots currently have several bugs/issues with them. This doesn't exactly change the skills they were already using - just refines the scenarios in which they should be used. For example, a boomkin won't use starfall when there is a pack within range but not aggro'd. You can turn off feral charge for cat druids now, so they don't fly into a bosses aoe (locust swarm on anub, overload on iron council). Bear druids don't battle rez anymore. They just feel less clunky and heal/hold aggro better. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) There are only 2 changes to files outside of the druid strategy, which is the healer low mana framework and the modification to autoattack not being used while in prowl. ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> AI was used heavily in the process to make this PR. First in the research necessary into how systems work, to the initial code implementation, to the testing results (explaining the outcome/why it sucks), to the fix, and then to the review of the code at the end. I will say that after I started researching how to use AI, use .md files for context, clearing sessions, I got a lot better results. I'll be the first to admit that it is 10 times easier to introduce a bug with AI than it is to solve one or implement something new. That is why every time it proposed a change, I asked it if the code was consistent with the project (Already present somewhere else) and if it wasn't, it was heavily scrutinized. It was written with Claude Code with Sonnet 4.6 (high), and peer reviewed by Github copilot. AI also made the description part of the PR, in which I modified myself. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). Wiki commands @Dreathean While this PR does add strategies, they are all enabled by default: co +feral charge (feral druids, both cat and bear) - enabled by default, allows/prevents the use of feral charge co +tranquility (resto druids) - enabled by default, allows/prevents the use of tranquility co +blanketing (resto druids) - enabled by default, allows the druid to pre-hot with wild growth and rejuvenation But it would be worth a mention on the wiki - there are scenarios where having these strategies disabled would be beneficial. ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> @kadeshar @Celandriel @brighton-chi Thank you for taking the time to look this over. There is a lot of copied code, a bit of new code (which is explained in the code explanation part of it, but please still ask questions), and a lot of refactoring. Please remember to reset the bot strategies before/after you test this branch, due to the several changes (blanketing, feral charge strategies). Reset with reset botAI or "talents spec balance pve" for any testers out there that didn't know. If/When this PR goes to the master branch, it will need to be noted to the people this same thing about resetting strategies.	2026-05-23 11:42:08 -07:00
dillyns	6294199343	DKs should use weapon stones (#2407 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Death Knights were not using weapon stones. This PR lets them use and initialize with weapon stones. ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. - Describe the processing cost when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> Create an rndbot DK. They should be init with weaponstones and use them on their weapon. Or give a weapon stone to an altbot. They should use it on their weapon. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. -->	2026-05-22 21:57:20 -07:00
kadeshar	55c5d29e2d	Replace hardcoded bot texts (#2408 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Replaced hardcoded bot text with translationable. Related with: #1295 ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Invite bots 2. Check that text after "follow" and "stay" return texts "Following" and "Staying" ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> Summary hardcoded text and checking that they already exists to reuse. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. -->	2026-05-22 21:41:24 -07:00
Crow	3a7e3e2719	Fix Mages' Armor Strategies & Light Refactor (#2390 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Mages have a "bdps" strategy to use Molten Armor (default for Fire and Arcane) and "bmana" strategy to use Mage Armor (default for Frost). The existing code uses a series of alternatives for armor (Molten->Mage->Ice->Frost), which is needed for Mages that have not learned Molten or Mage. However, I was noticing that sometimes my Fire and Arcane Mages would end up with Mage Armor, presumably because there could be a situation in which the casting of Molten Armor failed and the fallback to Mage Armor kicked in (for example, due to there being not enough mana to cast Molten Armor). This PR makes bdps always mean Molten Armor, if it is learned, and bmana always mean Mage Armor, if it is learned, by gating through triggers. Other changes: - Added bdps and bmana to default Mage combat strategies (still bdps for Fire and Arcane and bmana for Frost) so that Mages will reapply armor if it expires in combat. - Deleted Arcane Explosion strategy--it was not fully implemented because there was no associated action (such as through a CastArcaneExplosionAction class). I debated implementing it, but there isn't a suitable targeting mechanism that exists in the code from what I can tell. Arcane Mages generally just use Blizzard for AoE (and Flamestrike with PoM); Arcane Explosion is useful to use if (1) a player is moving or (2) mobs are almost dead in an AoE situation. Scenario (1) is irrelevant for bots since they cannot cast while moving. With respect to scenario (2), the existing AoE triggers in fact look for highest HP mobs so to implement Arcane Explosion in a useful manner would probably require a new Value, and that is not worth it for what would be miniscule benefit anyway. - General cleanups of Mage code (e.g., deleted empty ActionNodes). These were based on a quick review; I did not do any sort of detailed or comprehensive review and have no desire to with this PR. Note: I know that FrostMageStrategy.cpp had a Fireball alternative for Frostfire Bolt, but I deleted it anyway because the same ActionNode is already in GenericMageStrategy.cpp. - General cleanups of AiFactory default combat/noncombat strategies (e.g., removal of deprecated bdps and bmana strategies for Shamans). ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. - Describe the processing cost when this logic executes across many bots. Added getAlternatives for the armor strategies; this approach already exists for Druids. Added one new trigger for Molten Armor that is throttled by 10s like the existing Mage Armor trigger. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> Give a Mage the "bdps" strategy. They should cast Molten Armor. Make them cast a different armor. After the trigger throttle period (10s), they should reapply Molten Armor. Same goes for bmana and Mage Armor. Try this in combat, and it should work too. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) The point of this PR is to fix the default Mage armor buffing behavior. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> I had GPT-5.4 present a couple of possibilities to fix the issue of Mage Armor being cast with bdps, and from there I settled on the getAlternatives approach. I did everything else. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> @Dreathean Perhaps the wiki can be updated to document the bdps and bmana strategies for Mages?	2026-05-22 19:25:48 -07:00
Crow	cd2fe2f9a1	Use Stones for Prot Paladins & Reduce Oils (#2405 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Back when I did the Stones/Oils PR, I gave Wizard Oil to Prot Paladins. I was operating based on their mechanics in TBC and have since realized that their damage is much more physical-based in WotLK as opposed to spell-based in TBC. So I've changed them to now get stones upon maintenance and apply stones. I also reduced weapon oils given during maintenance from 4 to 2 stacks. I did 4 originally because oils stack to 5 so it would align with the amount given of stones and poisons (which stack to 20). But 4 inventory slots taken up by oils is excessive, and 2 still last far longer than buffing reagents in a raid context. So this is just to reduce inventory clutter. Other stuff is just little code stuff like reformatting or reordering things to be more efficient. ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. - Describe the processing cost when this logic executes across many bots. There's nothing new--essentially with respect to consumables, prot paladins now are lumped with ret. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> Create a prot paladin, turn on selfbot. Use maintenance and the paladin should be given stones and no oils. The paladin should then apply the stone to its weapon (if it is equipping a level-eligible weapon). Create a caster, turn on selfbot. Use maintenance and they should be given 2 stacks of oils. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) Prot paladins will now use stones in their inventory and will not use oils in their inventories. This is better for their mechanics. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. -->	2026-05-22 19:25:07 -07:00
kadeshar	34f34ef13d	Fix for ru translation (#2400 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Fixed bug with finding russian texts (loc8) Related with: https://github.com/mod-playerbots/mod-playerbots/issues/1884 ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Use ru client 2. Invite bot 3. Use command `focus heal ?" ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> Find and fix wrong places checking texts <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. -->	2026-05-22 19:24:15 -07:00
Mat	c7b4b9aa80	ICC V2, Autogear BiS cmd (#2363 ) ## Pull Request Description <!-- Describe what this change does and why it is needed --> Big thanks to @kadeshar for providing the bis list for many raids and ilvls :D Video demo for ICC 25HC: https://studio.youtube.com/video/nACyjn817iQ/edit Video demo for autogear bis chat command: https://www.youtube.com/watch?v=2YqyVBaSb2g split main IccActions.cpp into sperate per boss .cpp files changed style to be more aligned with https://www.azerothcore.org/wiki/cpp-code-standards (WIP) added bisicc chat command for bots to gear with ICC bis gear if autogear and bisicc is enabled in cfg https://gist.github.com/metal0/0bb094bf65d27e17044308ad0646cae1 bis list used LM Added multiple spike marking and focus for faster spike clearing, each spike will get its own kill group, tank spike will never get melee bots (only assist tank and ranged dps) Added coldflame detection so that melee bots dont go for spikes that are in flames During bonestorm assist tank will go far away spot so that once bonestorm is fixed, LM will bounce back and forth from MT to AT (atm it targets randomly, it should always pick furthest target) Coldflame avoidance is handled by avoid AOE, important to keep it on in cfg Tested on ALL diffs LDW Improved skull marking of adds, add handling by tanks and dps Changed 1st position for ranged bots for easier adds handling in HC and NM Improved tanking logic for tanks, assist tank will focus on collecting adds and bring them near boss Real players will also get cyclone aura when mind controlled Improved ranged position during 2nd phase, they should not get stuck in corners/walls anymore Tanks will remove LDW ToI aura in HC (really hard to tank with it since many things are happening at once) Added Cheat for LDW fight to help tanks with agro in 2nd phase of heroic modes Changed tank position in phase 2 closer to pillars opposed to stairs (bots love to fall thru floor and run thru walls if near them) this fixed the issue Fixed edge case for escaping from shades, it could happen that multiple shades would target bot, and it was running from 1st one he found, now it will run form all that are targeting it Hunters will cast viper sting now, to increase shield draining speed Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) In short cleared LDW without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. GS Changed triggers and actions to enable cross faction play Assist tank will now actually tank adds on friendly ship Dps will properly jump to attack mage and go back to their ship, if stuck on enemy ship /p reset, /p summon or /p follow fixed trigger for cannons, if cannons are frozen bots wont try to mount them anymore which prevented them from attacking mage properly bots will use rocket packs to jump to and from enemy ship instead of teleporting Main tank will now jump 1st. tank enemy boss and wait until all bots have jumped back before he jumps back All bots will wait for main tank to engage enemy captain before jumping to enemy ship Cannons will focus rockets 1st, then other adds now (for when gs gets scripted) Rdps will focus nearby adds on enemy ship and mark with star rti icon when there is no deep freeze todo: remove tanking bypass when core fixes enemy ship boss threat reseting Tested crossfaction on horde with single ally bot, ally bot did everything right, need to test more. note horde side is heavily bugged due to threat issue of adds, tanks cant take threat, on ally its somewhat ok, on horde rip. Horde is doable, but annoying cus of threat issue. Tested on ALL diffs DBS Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get rune of blood Tanks will tank adds better now, no loose adds anymore Tested on ALL diffs Dogs Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get 8 mortal wounds stacks Tanks will tank adds better now, no loose adds anymore Tested on ALL diffs Festergut Hunters sometimes populated row 0 which would make them in melee range of the boss (bad for dps). They should pick correct rows now Healers will populate row 0 1st then other rows for optimal healing position Ranged bots should properly choose unique spots to avoid stacking when there is no spore present Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get 6 gastric bloat stacks Changed ranged spore position closer to boss Spore bots should be able to attack/do non movement action when they have spore and are in position Solved malleable goo detection via direct boss hooks to detect boss targets! Tested on ALL diffs Rotface Tanks should not fight over big ooze anymore Improved big ooze kiting Improved small ooze stacking logic (when no big ooze present, stack at small ooze position, when big ooze is present move to it) Fixed edge cases when main and assist tank get small ooze (they used to move to big ooze, that was really bad since main tank would start to tank big ooze and get hit by big ooze, assist tank would stop kiting and get hit by big ooze) stopped mutated plague from dispelling instantly (as fight goes on, rotface cast mutated plague more and more, thus making it impossible to pass due to sheer numbers of small oozes and big oozes on the map, this will delay their spawning and give enough time for bots to handle them properly) Fixed edge case of multiple small oozes and big oozes being alive at same time (bots would detect wrong oozes and wipe raid or get stuck) Improved flood avoidance Improved ranged positioning in heroic mode, instead of letting them choose positions (which is a nightmare on dynamic fight as rotface, they now will choose 1 spot of 22 premade ones and populate them based on guid and adopt spot based on flood position) Improved Explosion avoidance by making bots remember their starting position so that they can return to it after big ooze explode, their movement is not chaotic anymore, and improved timers, they will wait 2 sec at new position before returning to starting position so that they can avoid explosion projectiles properly, they should also avoid moving to other bots starting positions. These changes ensure minimal movements so that bot can do maximum dps possible. Tested on ALL diffs PP Fixed many logic conflicts that caused bots to freeze, do bad dps to ooze/clouds Fixed triggers and multipliers Improved Gas Cloud avoidance, bloated bot will now remember its previous position to avoid backtracking/getting stuck in corners Added boss hooks to finally detect malleable goo, it is not an npc, object or creature and PP doesn't target anyone, bots will flee from it now Boss stacking now only in last phase Added cheats for players also (if enabled in cfg) only bots used to get auras Fixed tank switching in last phase, atm PP doesn't apply aura, but it should work, since same logic works for dogs, festergut and dbs Assist tank will now become abo if there is no abo before first puddle appears Abo will during puddles, slow oozes, slash boss & oozes In last phase assist will return to normal Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) Tanks switched in last phase flawlesly and shared stacks as they should (mutated plague got fixed in core) In short cleared PP without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. BPC Added center position to prevent bots from pulling BQL or other adds when they glitch thru walls/floor and thus resetting raid back to icc entrance teleporter Added additional z axis resetting since bots like to "fly" up in the air when attacking kinetic bombs. using cheat bypass for ball of inferno flames (atm bugged, doesn't shrink), bots will simply kill them when they spawn. Improved tanking for main tanks, improved collection of dark nuclei for assist tank Improved kinetics bomb handling Improved shock vortex spreading Improved valaran spreading for ranged Added shock vortex (non empowered) detection to avoid it while moving into safe positions Fixed jittery movement Tested on ALL diffs BQL Removed center position block so that bots can spread our easier in 25 mode, not ideal but makes 25hc easier Replaced repulsion based spreading, now each bot will have its own spot and move if needed to new spot Improved air phase spreading Fixed assist tank taking 1st bite Tested on ALL diffs VDW Due to recent core changes bots got bugged in portals if no real player entered and changed Z axis, if there was no z axis change bots would chill under the cloud on the ground and do nothing. I could not figure out how to fix this (thus breaking immersion) without force teleporting them to the clouds. Bots that go into portals will now teleport at the same time to clouds instead of following leader bot. Added feature that if players enter the portal, player with lowest guid will become bot "leader" and they will follow that player so that there is at least a little bit of immersion left. Fixed cloud collection for Heroic Mode, bots will now time clouds more precisely to avoid loosing stack due to not picking them up Improved RTI marking Improved group splitting Improved zombie kiting and avoiding explosion Tested on ALL diffs Sindragosa Bots will mark tomb positions with red smoke bomb in air phase so that real player know where to go with when beacon on them in last phase they will mark with blue smoke tomb position Fixed tank positioning Fixed wrong tomb choice and positioning Fixed tomb marking In last phase healers will stack with melee to allow boss healing In last phase when waiting for mystic debuff to pass, bots will damage tomb like in air phase to speed up the kill todo: tank switch to reset mystic buffet stacks Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) In short cleared LDW without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. LK Changed add gathering logic for 1st phase and winter phase, instead of tank moving to shamblings, he will keep taunting until they agro him. necrotic plague is easy now, ditched complex timing logic for a simple logic ( move to shambling, wait until dispeled, go back. Healers dont dispel until defile ally is near shambling ) Fixed winter phase gathering logic, assist tank will now properly move to raging spirits asap and bring them to main tank, melee dps will no properly move behind/flank spirits and shamblings to avoid instant death. Rdps will now properly focus frost orbs and adds, Transition should also be smoother now, but still needs /p reset if they get stuck. Other phases are ok, LK fight is now even better than before, but player still need to know tactics and use multibot addon to help out bots when needed, especially during defile phase since its random and position matter for valkyrs and future defiles Non winter phase AT will collect raging spirits and move them to main tank, ranged bots will keep distance, melee bots will flank them to avoid aoe Defile, ditched complex spreading which was mostly gamble with boss hooks to detect defile victim. If bot, bot will move away from raid, if real player main tank will yell Player name move away defile. bots will stay in center now if safe from defile, raging spirits or vile spirits Vile spirits soaking by assist tank. Assist tank will stand between spirits and raid and chase spirits. healers are allowed to move from position to heal assist tank. one hunter if alive will be at center position to place traps to slow down spirits HC Real players will also get buffs if cheats are enabled now Assist tank will now never move towards the raid to gather adds, instead it will taunt them instead so that they come to it Assist tank will rotate shamblings at all times away from raid Assist tank will stun shamblings before transition to avoid shockwave wipe Winter phase ice sphere location changed, ranged will focus sphere faster and better now Fixed jittery movement and low dps during winter phase Fixed most of the bots getting stuck during winter phase Valkyrs will be properly marked now, one by one, in hc bots will now ignore low hp valkyrs and focus on grabbing valkyrs or boss After winter raging spirit will have top priority for killing After winter ranged bots will 1st handle ice spheres then skull targets Spirit bomb avoidance improved, main tank should not back track into unsafe positions anymore Since real player is leader its crucial that player know the tactics, bots can not handle edge cases during the fight alone, they need some of reset, follow, summon here and there since its a long fight and things can go wrong. Tested on ALL diffs NOTE: If server crash, bots will sometimes drop ICC strategy even though they are in ICC, simply re enter or write /p nc +ICC to re enable. NOTE: addons that mark icons during fight could break bots, since icons are used for RTI by bots NOTE: I did not use any raiding addons besides unbot and multibot to control bots NOTE: In theory everything should work wihout ICC buff from world cfg, and ICC cheats from playerbots cfg, didnt test it, didnt try, its too hard core for hc mode to go raw, but it should be possible good luck :) NOTE: For normal about 5k gs should be enough to do most bosses. For HC T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for fun experience. NOTE: As player its good to know every strategy for Bosses, so that you can spot and help out with reset, follow, summon if bots seem stuck or are doing something strange, a lot of stuff is happening on most fights so expect some intervention with reset, summon, follow. 10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for bress (its not set in stone, but most success with this setup) 25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for bress (its not set in stone, but most success with this setup) GL & HF, happy raiding :D Closes #1421 #2120 Fixes #1219 NOTE: Not all of them, I have updated affected changes in #1219. Trash, quest, cheats are still nice to haves, but I don't see working on that in near future. Before posting bugs check #1219 and write there. As I said, I dont plan to implement certain things in near future, but I am more than willing to fix bugs that crash server if they happen ASAP. <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. - Describe the processing cost when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. Enter ICC Test Bosses bis ICC command type bisicc into party chat or whisper and bots will reply and equip gear - Any required setup (e.g. multiple players, number of bots, specific configuration). NOTE: If server crash, bots will sometimes drop ICC strategy even though they are in ICC, simply re enter or write /p nc +ICC to re enable. NOTE: addons that mark icons during fight could break bots, since icons are used for RTI by bots NOTE: I did not use any raiding addons besides unbot and multibot to control bots NOTE: In theory everything should work wihout ICC buff from world cfg, and ICC cheats from playerbots cfg, didnt test it, didnt try, its too hard core for hc mode to go raw, but it should be possible good luck :) NOTE: For normal about 5k gs should be enough to do most bosses. For HC T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for fun experience. NOTE: As player its good to know every strategy for Bosses, so that you can spot and help out with reset, follow, summon if bots seem stuck or are doing something strange, a lot of stuff is happening on most fights so expect some intervention with reset, summon, follow. 10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for bress (its not set in stone, but most success with this setup) 25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for bress (its not set in stone, but most success with this setup) - Expected behavior and how to verify it. If requirements are met, bots should not struggle with killing bosses Compare to https://www.youtube.com/watch?v=nACyjn817iQ&t=460s --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [X ] Minimal impact (explain below) In theory it should not impact, didnt test with hi bot count or large player count - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [X ] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [X ] Yes (explain below) Impacts in raid, new actions, triggers Impacts with new bisicc cmd that will gear bots Everything should make it easier for maintenance since each boss is in seperate file now ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x ] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> AI was used for analyzing code for ac code standard violations, edits were made by me. It was used for fixing bugs, brainstorming and code generation (for complex math problems, such as dynamicaly kiting oozes around, assiging positions during multiple complex situations in rotface encouter. Everything was checked and tested multiple times until it was polished (to my abilites and understanding). It helped me to solve Malleable goo detection, defile, by hooking directly to boss in order to detect it, since it was detectable only by split second since it was not npc, spell or object. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [ x] Stability is not compromised. - - [x ] Performance impact is understood, tested, and acceptable. - - [x ] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> I have not tested with multiple players, or large servers or with 3k+ bots --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com>	2026-05-22 19:23:35 -07:00
Keleborn	2973083dda	RBAC sync (#2355 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Implement RBAC Permission system in checks. Claude flagged the following PlayerbotMgr.cpp:751 <= SEC_PLAYER SecurityCheckAction.cpp:27 == SEC_PLAYER In these two cases a moderator level account has access to these commands. This was preserved in PR. The question is whether mods should maintain the override. ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. - Describe the processing cost when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. -->	2026-05-22 19:23:18 -07:00
dillyns	9c9c386af7	Add ELEMENTAL_SHARPENING_STONE to prioritized weight stone IDs (#2395 ) <!-- 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 elemental sharpening stone to the list of weightstones for weapon buff application. Elemental sharpening stones can be used on any melee weapon, not just sharp ones. ## 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. --> Give a bot that has a blunt weapon equipped (staff or mace) an elemental sharpening stone (ID: 18262) They should now use the stone on a blunt weapon. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (explain below) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (explain below) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (explain below) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. -->	2026-05-15 23:28:04 -07:00
Crow	d4f86764bb	Fix raid group condition in SayToRaid (#2386 ) <!-- 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 --> PlayerbotAI::SayToRaid is not used currently but I may use it for Sunwell for bot speech during Kalecgos due to tank handoff mechanics. The function currently erroneously returns false for a bot in a raid. There's no impact on bot behavior or performance from this PR. ## 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? - - [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. -->	2026-05-15 23:27:15 -07:00
Crow	05e8f4d82c	Implement Black Temple Strategies (#2381 ) <!-- 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 implements strategies for all bosses in the Black Temple. As always, I’ve written these with the intent that all bosses be completable with appropriate gear and 50/50 IP nerfs and boss HP returned to TBC levels. Illidan is difficult at those parameters, but he is certainly doable. You just won’t be able to roll a bunch of meme specs or shitty compositions. Probably. ## 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. My goal with raid strategies is the same—I’m not just trying to make encounters doable but am trying to allow people to experience them in a way that feels like they are part of a coordinated raid of real players. To me, being able to achieve that is the minimum, and that requires getting bots to respond to all major mechanics, even if they can technically just be powered through. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> Run the Black Temple raid and see if my descriptions of strategies in the next post check out. ## 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) The performance impact exists only when the “blacktemple” strategy is on. I’ve tested with pmon and done my best to properly gate checks to limit the performance impact even during the instance and boss encounters. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) The triggers and multipliers will be evaluated as long as the "blacktemple" strategy is active, and it will be applied automatically in the instance (and removed automatically when changing maps outside the instance). - 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. --> GPT-5.4, mainly for calculations and things that are more intermediate concepts that I’m not proficient with like lambdas. <!-- 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-15 23:26:55 -07:00
NoxMax	66d41e1d79	Feat: Selective reset to default of combat or non-combat strategies (#2365 ) <!-- 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 commands `co !` and `nc !`, which would reset either the combat or non-combat strategies of a follower bot, without affecting the other strategies or any other values. Also ChangeStrategyAction.cpp was refactored for duplicate code by introducing the helper function `HandleStrategyCommon`, that gets called by `ChangeCombatStrategyAction` and `ChangeNonCombatStrategyAction` ## 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. `reset botAI` already resets strategies back to default, but it resets ALL strategies and wipes values such as formations, stances, and everything else under the `value` key in playerbots_db_store>value. The new commands don't run across many bots, only on the bot the command is run on. ## 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. Run either `co ?` and `nc ?` to see current list of combat and non-combat strategies the bot has. 2. Add and remove strategies to both `co` and `nc`. 3. Confirm your changes with `co ?` and `nc ?`. 4. Run `co !` only. 5. Run `co ?` to confirm combat strategies have been reset to default, and `nc ?` to confirm it has not been affected. Then run `nc !` to reset it as well. 6. Do another test [inside an instance](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#raid-specific-strategies). Remove a bunch of `nc` strategies, including the strategy for the raid itself. 7. Run `nc !` and check that the defaults have been reset, but that the instance strategy has been re-added as well. ## 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? - - [ ] No - - [x] Yes (explain below) Technically it adds a new case to ChangeCombatStrategyAction, but it's straightforward. ## 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. --> Review only in case I was missing something, and then to easily refactor duplicate code with HandleStrategyCommon. <!-- 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. --> [Commands wiki](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#strategies) need to be modified to read: --- You can query the bot to report what strategies are currently being used: ``` co ? nc ? ``` You can reset either of the bot's strategies back to defaults: ``` co ! nc ! ``` --- Tangentially I also recommend [this section](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#non-combat-strategies) to be edit to this for more accuracy: --- General strategy \| description :---\|:--- ``food`` \| enable bot's ability to eat/drink ``pvp`` \| enable bot's ability to engage in PVP combat. Note: PVP mode wouldn't appear active until the bot starts combat ``loot`` \| enable bot's ability to loot. Note: adding or removing that strategy for randombots requires GM level	2026-05-08 22:42:18 -07:00
Keleborn	b8ff5996f8	Flying mount fixes and self-bot (#2351 ) <!-- 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 does a few things. 1. Enable Selfbots to mount up. Because they have masters, but are their own masters, they would never mount up because their master never mounted. 2. Fix flag state handling after processing the aura change. 3. Add in the Dismount packet handler. This is intended to implement fall animations and have bots touch the ground when dismounting instead of floating off the ground. (It was cleared anyway after the first move, but this should make it more seamless.) ## 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. --> self bot should mount up, and select area appropriate mounts. Bots in your team should mount up, and on your dismount properly snap to the ground. should test at low Z (<1.0 off the ground) and higher z (> 1.0 off the ground) ## 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) The processing of a fall path has some impact, but I dont think itll be too much. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) Add natural falling when dismounting. May incurr fall damange.... - 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. --> Comparison of code bases, searching for flags, adding diagnostic logging, and processing of said logging. iterating and brainstorming. Code was also written, but fully reviewed by me, and fixed where appropriate. <!-- 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: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 22:41:13 -07:00
Ivan Novokhatski	7af675e712	Respect worldserver's PreventAFKLogout value (#2328 ) ## Pull Request Description This adds checks to prevent bots from logging out when the master isn't actually logging out, respecting the `PreventAFKLogout` setting in `worldserver.conf`. Otherwise, returning to the game after a long pause means your bots are offline and you have to re-add them, which is annoying. ## Feature Evaluation N/A ## How to Test the Changes 1. Set `PreventAFKLogout` to 1 or 2 in `worldserver.conf`. 2. Start the server, log in, add some bots to your party. 3. Go to a sanctuary if you set `PreventAFKLogout` to 1 or just start idling anywhere otherwise. 4. Both you and the bots will stay in-game no matter how much time has passed. ## 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? - - [ ] No - - [x] Yes (explain below) Researching the issue and determining what checks need to be implemented. ## 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:40:16 -07: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	5d9761c9e8	Implement Battle for Mount Hyjal Strategies (#2258 ) <!-- 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. --> ### Contingent on https://github.com/mod-playerbots/mod-playerbots/pull/2295/ ## Pull Request Description <!-- Describe what this change does and why it is needed --> This PR implements raid strategies for all bosses in everybody's favorite TBC instance, the Battle for Mount Hyjal. As before, I have designed these all to work with IP with 50% damage and healing. I also did not merge the 1.88x buff to Vanilla & TBC healing items that IP recently implemented. The next post will outline all implemented strategies. Note: Set to draft for now as I may tweak Archimonde some more, but I generally consider Hyjal complete, subject to comments. ## 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. As with previous strategies, I've worked within the existing context of actions/multipliers/triggers. This strategy does implement new spell hooks, but I don't think that is problematic for performance, and I'll explain why they are necessary in the next post. ## 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 - - [x] Minimal impact (explain below) - - [ ] Moderate impact (explain below) There are many new triggers, multipliers, and actions, but they will be evaluated only if the "hyjal" strategy is added. Additionally, I've attempted to order and implement checks in a manner to limit performance impact and have tested with .pmon active. In general, I consider performance to be highly important so am always working on ways to limit the impact (e.g., trying to use the most targeted grid searches available when needed). - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) Only in the Hyjal instance, for obvious reasons. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (explain below) New decision branches apply only in the new Hyjal instance, for obvious reasons. Maintenance complexity should not be increased as code outside of the new Hyjal files is not impacted, except to the extent needed to register and implement the strategy in the same manner as all existing strategies. Exception: As noted, I did add new spell hooks, but if they become problematic, they can easily be removed. ## 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? - - [ ] 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. --> Claude Sonnet 4.6 was used for more complex implementation and occasionally GPT-5 mini was used for simple questions. I do not use AI for brainstorming or developing strategies, only for implementation and review of code. Most of this was written by me directly, but most notably I needed AI support to implement the spell hooks and triggers/actions that relied on them. Everything was reviewed and tested many times. ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. Caveat: The full impact of implementing the spell hooks on a broad scale is beyond my knowledge to evaluate. - - [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-05-08 22:39:32 -07:00
Keleborn	38caa1daa7	Randombots respect realm PVP setting (#2342 ) <!-- 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 --> Fix an issue where bots would eventually have pvp set by reset. THis ensures bot pvp states are consistent with realm type. ## 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? - - [ ] No - - [x] Yes (explain why) Corrects behavior to match server intent. - 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. --> searching code, writing it. <!-- 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-03 21:41:45 +02:00
Keleborn	ccce14238e	Core Update, change to DeserterCheck and signature (#2354 ) <!-- 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 --> Required change for https://github.com/azerothcore/azerothcore-wotlk/pull/24641 ## 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) - - [ ] Moderate impact (explain below) - Does this change modify default bot behavior? - - [ ] No - - [ ] Yes (explain why) - Does this change add new decision branches or increase maintenance complexity? - - [ ] 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 - - [ ] 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 - - [ ] Stability is not compromised. - - [ ] Performance impact is understood, tested, and acceptable. - - [ ] Added logic complexity is justified and explained. - - [ ] Any new bot dialogue lines are translated. - - [ ] 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-03 07:16:34 -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
kadeshar	ed5791eabf	Pull target overlap fix (#2335 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Fixed "pull target" value which was overlap with new pull strategy. Related with #2334 ## 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 tank bot to party 2. Use `nc +debug` 3. Use command `do attack my target` 4. In debug shouldnt be `reach pull` or similar ## 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. --> To analyze problem with value <!-- 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-04-25 14:40:53 -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
Keleborn	eb268c7507	Init guilds on login. (#2325 ) <!-- 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 --> Guild solution to #2148 ## 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 - - [x] Minimal impact (explain below) - - [ ] Moderate impact (explain below) Minimal cost on bot login. - 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. -->	2026-04-24 23:05:35 +02:00
Keleborn	866a73dfbf	Clean up unused variables (#2268 ) <!-- 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 --> Clean up a bunch of additional unused variable warnings. ## 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) ## 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? - - [ ] 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. --> Claude reviewed the warnings log from a build and suggested a series of changes. I focused just on these warnings for now. Every line was reviewed. Some sections need to be reviewed by author for intent. ## 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. -->	2026-04-24 23:03:36 +02:00
Keleborn	a4b37c9fbc	Revert "Feat: Reintroduce timed logouts" (#2329 ) Reverts mod-playerbots/mod-playerbots#2289	2026-04-24 12:27:06 -07:00
kadeshar	19249e90a0	Pull strategy migration (#2310 ) <!-- 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 --> Pull strategy migration from cmangos for tank specializations ## 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 tank 2. Use `reset boAI` or `nc +pull,+pull back` + `co +pull,+pull back` 3. Order bot to pull using command `pull my target` or `pull rti target` 4. Bot should run to mob, use ranged skill and back to point where he started pull Without `pull back` strategy bot run to mob, use ranged skill and wait on mob until he come to bot ## 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. --> Help with migration and solving some problems <!-- 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. - - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> Stability test after randomize new bots <img width="465" height="172" alt="obraz" src="https://github.com/user-attachments/assets/6e39a8c0-f23b-47cc-852a-71fa98044a31" /> --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>	2026-04-17 14:07:47 -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
NoxMax	6c517eb9d1	Feat: Reintroduce timed logouts (#2289 ) <!-- 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 --> Timed logouts was enabled in the past, but was disabled due to a misdiagnosis on an issue that caused crashes. That issue was better understood and resolved in #2131. Now timed logouts are reintroduced for alt-bots and addclass-bots. As before, random-bots do not and should not accept logout commands. Note that if the bot's master has instant logout privileges according to `InstantLogout` in worldserver.conf, so would the bot. If not, neither would the bot. ## 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. Feature at minimum logic needed to implement. No measurable processing cost. ## 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. Have your account gmlevel set to 2 in acore_auth>account_access just to test how it works with security parameters. 2. Set `InstantLogout = 3` in worldserver.conf. 3. Invite an addclass or alt-bot. 4. Bot should logout if whispered "logout" to or if you logout. 5. If not in a resting place, neither you nor the bot should be able to instant logout according to the security setting. 6. After the bot logout, log it back in and whisper "logout" again, but right after whisper "cancel logout" or "logout cancel". That should cancel the logout. 7. Have your account gmlevel set to 3 in acore_auth>account_access. (when you change your gmlevel, you need to log out of your account for the change to take effect) 8. You are now at admin gmlevel, and with `InstantLogout = 3`, you and any bot under your command should be able to logout instantly. ## 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) Bots now trigger instant or timed logout under the same circumstances that would apply to their master. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (explain below) Checks if bot is eligible for instant logout or not. If not, timed logout applies to them. ## 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. --> While testing this I was having some odd issues with the command `account set gmlevel`. Not sure what's going on there, but for purposes of testing this and changing your account security level, doing it directly in the DB at "acore_auth>account_access" is going to be most reliable.	2026-04-17 11:27:44 -07:00
Crow	a34681bd7e	Modify UpdateAI to Allow Future Methods to Interrupt Bot Spells (#2295 ) Note: Resubmitted because the prior PR had master for the source <!-- 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 adds to PlayerbotAI::UpdateAI a boolean variable, pendingCastInterrupt, and a public function, RequestCastInterrupt(), that toggles the variable and would then call InterruptSpells in UpdateAI. This lets an external script hook into UpdateAI to interrupt a spell that is in the process of being cast. This should allow raid/dungeon strategies to actually interrupt spells, such as for avoiding hazards, as you cannot do so by calling InterruptSpells() or Reset() or anything else with a raid/dungeon action method. ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the minimum logic required to achieve the intended behavior. - Describe the processing cost when this logic executes across many bots. There is no processing cost from this PR itself since it just adds a simple boolean check that will always return false unless other methods are implemented to call RequestCastInterrupt(). ## 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. --> This PR doesn't do anything by itself, but confirmation of no performance impact can be tested by just playing with the PR merged. I tested this by introducing scripts that called RequestCastInterrupt() for Archimonde (included in the Hyjal PR now) and for Auchenai Crypts (built on the strategy from flashtate's PR just for test purposes), and spells were interrupted as intended. ## 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? - - [ ] No - - [x] Yes (explain below) I'm not sure if it counts as "yes" here, but this PR opens up the ability for scripts to be added that would add real checks to UpdateAI. The impact of such scripts will depend on how they are implemented, however. It is possible (and intended) for the external calls to be highly limited in scope (e.g., only bots in a particular circumstance in a particular boss fight). ## 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. --> Claude Sonnet 4.6 was used to brainstorm different possibilities to allow external scripts to interrupt spells. I considered different options before settling on this one due to it not requiring core changes, being easily usable in boss strategies, and not having any performance impact on its own. <!-- 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:27:11 -07:00
Hokken	ce1adebc78	fix(Core): scope AddPlayerBot loading count to master account (#2307 ) ## Problem `AddPlayerBot()` falsely rejects player bot additions with "You have added too many bots (more than 40)" even when the player has zero personal bots. This happens because the `MaxAddedBots` check at `PlayerbotMgr.cpp:124` adds `botLoading.size()` to the player's personal bot count: ```cpp uint32 count = mgr->GetPlayerbotsCount() + botLoading.size(); ``` `botLoading` is a `static std::unordered_set<ObjectGuid>` on `PlayerbotHolder` — shared by both `PlayerbotMgr` (per-player) and `RandomPlayerbotMgr` (singleton). When `RandomPlayerbotMgr` loads random bots at startup (up to 60 per interval via `RandomBotsPerInterval`), their GUIDs go into the same global set. During the startup loading window, `botLoading.size()` can easily reach 100–300, far exceeding the default `MaxAddedBots = 40` limit. The result: any player who logs in during the random bot loading window and tries `.playerbot add <name>` gets blocked, even though the limit is intended to be per-player. ### How to reproduce 1. Set `AiPlayerbot.RandomBotAutologin = 1` (default) with 500 random bots 2. Start the server 3. Log in immediately while random bots are still loading 4. Run `.playerbot add <character_name>` for an offline character on your account 5. Get "You have added too many bots (more than 40)" despite having 0 personal bots 6. Wait 1–2 minutes for random bot loading to finish, try again — works ### Root cause - `PlayerbotHolder::botLoading` is declared `static` at `PlayerbotMgr.h:60`, so both `PlayerbotMgr` and `RandomPlayerbotMgr` share the same set - `AddPlayerBot()` inserts into `botLoading` at line 147 for ALL callers — both player-initiated adds (`masterAccountId > 0`) and random bot spawns (`masterAccountId = 0`) - The count check at line 124 uses `botLoading.size()` (the entire global set) instead of filtering to bots being loaded for the requesting player - The config comment confirms the intended scope: "The maximum number of bots that a player can control simultaneously" ## Fix Change `botLoading` from `unordered_set<ObjectGuid>` to `unordered_map<ObjectGuid, uint32>` where the value is the `masterAccountId` passed to `AddPlayerBot()`. Random bots are loaded with `masterAccountId = 0`. The count check now iterates the map and only counts entries matching the current player's `masterAccountId`: ```cpp uint32 loadingForMaster = 0; for (auto const& [guid, acctId] : botLoading) { if (acctId == masterAccountId) ++loadingForMaster; } uint32 count = mgr->GetPlayerbotsCount() + loadingForMaster; ``` ### Callsite compatibility All 10 existing `botLoading` callsites were audited: \| Callsite \| Operation \| Compatible \| \|----------\|-----------\|-----------\| \| `PlayerbotMgr.cpp:85` \| `find()` by key \| Yes \| \| `PlayerbotMgr.cpp:153` \| `emplace()` (was `insert()`) \| Changed \| \| `PlayerbotMgr.cpp:174` \| `erase()` by key \| Yes \| \| `PlayerbotMgr.cpp:209` \| `erase()` by key \| Yes \| \| `PlayerbotMgr.cpp:229` \| `erase()` by key \| Yes \| \| `PlayerbotMgr.cpp:1163` \| `find()` by key \| Yes \| \| `RandomPlayerbotMgr.cpp:429` \| `empty()` \| Yes \| The six unchanged callsites use `find()`, `erase()`, and `empty()` which operate on keys identically for both `unordered_set` and `unordered_map`. ## Files changed \| File \| Change \| \|------\|--------\| \| `src/Bot/PlayerbotMgr.h` \| `botLoading` type: `unordered_set<ObjectGuid>` → `unordered_map<ObjectGuid, uint32>` \| \| `src/Bot/PlayerbotMgr.cpp` \| Definition type updated, `insert` → `emplace` with `masterAccountId`, count check filters by `masterAccountId` \| ## What is NOT changed - `MaxAddedBots` config key and default value (40) — unchanged - Random bot loading behavior — unchanged - The `botLoading.empty()` throttle in `RandomPlayerbotMgr` — unchanged - In-game group invite flow — unaffected (does not go through `AddPlayerBot`) - No new config keys, no schema changes, no API changes --------- 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> Co-authored-by: Hokken <Hokken@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-17 11:26:42 -07:00
Flashtate98	8f7d352f7e	Implement Auchenai Crypts Strategies and TBC Dungeon Contexts (#2229 ) <!-- 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 aims to add bot strategies to the Auchenai Crypts dungeon, specifically for the boss Shirrak the Dead Watcher, as his focus fire mechanic is really annoying to deal with. Additionally I have added TbcDungeonActionContext.h and TbcDungeonTriggerContext.h for future reference as I add more strategies to TBC dungeons that need it. A HUGE thank you to @brighton-chi for all his help. This has been a fun learning experience! ## 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. Trigger: A 20 yard radius grid search is performed to locate the focus fire trigger NPC Action: Bots will flee from the trigger NPC using MoveAway with a 5 yard safety buffer Multiplier: A for loop that prevents bots from running back into the focus fire mechanic while its active. Tanking: Tanks have a set coordinate to drag the boss to for the duration of the fight. - Describe the processing cost when this logic executes across many bots. Minimal, these scripts only execute when Shirrak has been engaged. ## 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 into Auchenai Crypts (Normal or Heroic) and engage Shirrak the Dead Watcher ## 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) This logic is only applied to Auchenai Crypts and activates during Shirrak's encounter. - Does this change modify default bot behavior? - - [ ] No - - [X] Yes (explain why) Behavior only applies when in the instance and when engaged with Shirrak. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [X] Yes (explain below) New dungeon contexts were added (TbcDungeonActionContext and TbcDungeonTriggerContext) to provide a clean and dedicated structure for future TBC dungeon strategies that will be developed. This was done to be in alignment with the existing WOTLK contexts that already exist. ## 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? - - [ ] 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. --> Gemini was used to help me understand existing code in the module I was referencing and reusing to develop this strategy as I am not a programmer and hardly know anything about C++. ## Final Checklist - - [X] Stability is not compromised. - - [ ] Performance impact is understood, tested, and acceptable. - - [ ] Added logic complexity is justified and explained. - - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> If there are any better alternatives that could be used to help improve the strategy in any way, please suggest it. I am very new to this and want to learn and improve. --------- 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:08 -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
kadeshar	e13aa7d2f6	IsTank fix for Death Knight (#2296 ) <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Death Knights with Frost Presents are recognized by bots as tank Related with: #2290 ## 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. Create Death Knight and apply Frost Presence 2. Invite Restoration Druid bot to party 3. Bot should apply "Thorns" on you ## 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) Bots now identify Death Knight with Frost Presence as tank - 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. --> Example of non Blood Death Knight tank build https://forum.warmane.com/showthread.php?325582	2026-04-10 22:15:57 -07:00
bashermens	4bcf8fd2c4	Performance(Core): Some activity sec to ms init fixes, global activity loop check and some additional minor fixes (#2288 ) <!-- 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 1. Corrected the init activity times; Since ive changed (previous) the calc from seconds to ms to increase more scope for the offset execute jitter (removed timer(), 0 is correct way todo now with MS) (also broke self-bot) 2. Global loop checks in activityAllowed instead vs multiple loops, this function is called very often so we better optimize it. 3 Fixed the broken 'HasManyPlayersNearby' function and then deleted it :O To fragile due various edge cases and rather expensive call, besides lets activeAlone deal with this situation which is way more controlled. 4. Some additional small fixes that where unnoticed overtime. 5. Added/Changed inline comments which makes more sense and explains what it does. 6. Removed dead code freeze bots during init. 7. self-bot fix ## 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) When playing with larger amount of real players makes the allowed activity perform better. - 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. -->	2026-04-08 19:35:18 +02:00
Benjamin Jackson	7b04c56956	Add default case to mount initialization for bots. (#2276 ) ## Pull Request Description <!-- Describe what this change does and why it is needed --> This PR adds a default case for the mount initialization function for player bots, allowing custom race additions to not crash when added to an AzerothCore server (such as [`mod-worgoblin`](https://github.com/heyitsbench/mod-worgoblin)). ## Feature Evaluation This feature ideally does not get touched in standard `mod-playerbots` usage, as it only adds a case to a switch statement, and would not be getting taken with Blizzlike data (which the vast majority of users likely use). ## How to Test the Changes 1. Add custom races to your AzerothCore instance (most easily accomplished with the above linked module). 2. Start the server and configure it to create random player bots (that fall under the added custom races). 3. Observe no crash. ## Impact Assessment - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [X] No, not at all - Does this change modify default bot behavior? - - [X] No - Does this change add new decision branches or increase maintenance complexity? - - [X] Yes (explain below) This does add another path in a switch statement. It also creates another set of data for that case. This could have been avoided by consolidating the human/orc cases into the default case, but I elected not to do that in case players make their own changes. If preferred, I can definitely consolidate the cases to not have those redundant data points. ## Messages to Translate - Does this change add bot messages to translate? - - [X] No ## AI Assistance - Was AI assistance used while working on this change? - - [X] No ## Final Checklist - - [X] Stability is not compromised. - - [X] Performance impact is understood, tested, and acceptable. - - [X] Added logic complexity is justified and explained. - - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers Pretty please? 🥹 --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>	2026-04-04 13:22:27 +02:00
kadeshar	4c9b0adb72	Fire mage cc (#2281 ) <!-- 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 fire mage cc spells like: Dragon's Breath (disorient) and Blast Wave (knockback) ## 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 fire mage to party 2. Add strategy `nc +duel` 3. Start duel and go near bot 4. Bot should use frost nova/dragon's breath/blast wave depends of cooldowns ## 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) Mages cc by default - 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? - - [ ] 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. --> OpenCode, for research differences between CcStrategy implementation between cmangos and ac playerbots ## 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. -->	2026-04-04 13:00:51 +02:00
Keleborn	ca54cff6f5	Bug fix. Edge case where bots would get stuck in cities. (#2269 ) <!-- 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 refactored flight destinations, I wanted to make where bots go more intentional. so I made it dependent on the allianceHubsPerLevelCache and hodeHubsPerLevelCache. This system relied on there being an innkeeper in each area that the bots would fly to. However, not every zone has an innkeeper, and so there was an odd situation where bots had nowhere to fly to. (Most notably at level 53.) This solves that by hardcoding the flightmasters in those areas into the cache. I also put back in the city teleport probability check which was forcing every bot to teleport to a city on level up. ## 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) ## 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? - - [ ] 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. --> Debugging and comments. ## 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. -->	2026-04-04 13:00:01 +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
kadeshar	76dd91c4fa	Hand of Freedom support (#2233 ) <!-- 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 Added Hand of Freedom action for paladin. Related with: #2002 ## 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. --> - invite paladin bot to party - start fight (can use dummy target) - apply some snare effect to bot or yourself (for example `.aura 1715`) - bot should use hand of freedom ## 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) Yes, paladin bots start using Hand of Freedom - 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? - - [ ] 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. --> OpenCode, as helper to create and review code ## 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. --> <img width="424" height="93" alt="obraz" src="https://github.com/user-attachments/assets/3cac4454-35af-474d-8ea0-67c462973c79" />	2026-04-03 13:25:29 -07:00
Crow	79562be2e5	Fix Hunter Aspect Switching + Trigger Cleanups (#2203 ) # Pull Request Note: When I reference Aspect of the Hawk below, it also means Aspect of the Dragonhawk (the code will use Dragonhawk if the Hunter has it, Hawk if not, they share actions, triggers, and strategies). Hunter Aspects are currently bugged. All Hunters, regardless of spec or strategy, are hardcoded to use Aspect of the Hawk when mana is at 70%+ and Aspect of the Viper when mana drops to "lowMana" from the config (default is 15%), divided by 2. This means the following: - Hawk (bdps) and Viper (bmana) strategies are useless - Pack (bspeed) and Wild (rnature) strategies are applied, but bots will rapidly switch back and forth between Pack/Wild and Hawk/Viper, depending on strategy and mana level. This PR addresses the issues by doing the following: - Global Hawk strategy is removed. Now you need to set bdps for Hunters to use Hawk, but bdps remains the default Aspect strategy for all Hunters. - Dedicated Viper strategy is removed, leaving the global strategy. However, Viper will be used (when lowMana/2) ONLY if the bot is set to bdps. If the bot has the Wild or Pack strategy, they will not switch to Viper at all. I did this because I am assuming if you are using Wild or Pack, you need them for reasons other than to pump DPS. - The threshold to switch back to Hawk is lowered from 70% to 60%. The gap between lowMana/2 and 60% is now filled--if bdps is on, Hunters will switch to Hawk whenever above the Viper threshold, _except_ for when they have the Viper aura, in which case they will not switch to Hawk until 60% mana. This lets the Hunter build back mana before swapping back to Hawk (more like general player behavior) while still letting them swap from other Aspects to Hawk without needing to be all the way at 60% mana. - Gets rid of a weird condition in the Hawk trigger that would make it so that Hunters would switch to Hawk when at exactly 0 mana. I'm not sure what the point of that is. Also, I refactored the triggers a bit because I noticed there was some dead code in there. I didn't do a comprehensive refactor, but there was a lot of stuff that clearly didn't make sense even to my eyes, like back-to-back returns. I think there's more unnecessary code even just in the triggers, but I didn't want to get too into the weeds with this PR. --- ## 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? I don't expect there to be any impact on costs, and if anything this PR removes some unneeded checks from triggers. --- ## 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 The easiest way is to go shoot a dummy with Volley until low on mana and then toggle on selfbot. You can do this with various Aspects active to test. ## 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) Described above. Default behavior is broken. 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? - - [ ] No - - [X] Yes (explain below) I asked Claude some questions about the triggers to make sure I didn't screw anything up. 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-04-03 13:24:37 -07:00
Crow	91eac70ca2	Implement Zul'Aman Strategies (#2186 ) # Pull Request _Implement strategies for all bosses in Zul'Aman. See next post for overview of implemented strategies._ --- ## 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? _I have attempted to order checks while taking into account cost and likelihood and have opted to find lower-cost methods where possible. I have also not gone as in depth as I have with other strategies, partially because it is not necessary to complete encounters but also to try to limit the performance impact. From my observation, including with pmon, none of the methods should be overly taxing._ --- ## 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 _Run Zul'Aman. See next post for strategies to test._ ## Complexity & Impact Does this change add new decision branches? - - [ ] No - - [x] Yes (explain below) _Only in the context of raid strategies, with new methods to consider and new multipliers to evaluate when bots perform actions with the instance strategy active._ Does this change increase per-bot or per-tick processing? - - [ ] No - - [x] Yes (describe and justify impact) _The impact is only with the "zulaman" strategy active, which will be applied only in the instance. There is currently a PR open to also remove instance strategies when leaving the map to get rid of the residual performance impact._ Could this logic scale poorly under load? - - [ ] No - - [x] Yes (explain why) _Technically yes, but I think it is unlikely to have an appreciable difference unless there are many groups running the instance at the same time on a large server._ ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] Yes (explain why) _Only in the instance. It is a necessary trade-off to consider with raid strategies that I always keep in mind (degree of automation vs. player choice)._ If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable _Not exactly sure how to address this question in the context of this PR, but there aren't any techniques or methods for this strategy that I have not tried before (or something very similar)._ ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [x] 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 _Gemini and GPT for some questions about the codebase and C++ and assistance with drafting a few things like containers that I find more tedious to do myself._ 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-27 10:38:12 -07:00
NoxMax	c7ac849fbe	Fix: Logout refactor and RNDbot logout error handling (#2131 ) # Pull Request * Improper crash fix by 297f11d3e59f52a29f68188245e6b786c9fa838e. That fix worked not because setting `logout = true` stops the server from crashing, but because it stopped the following `if (!logout)` block from executing at all. In that block `delete target;` was the actual cause of the crashing and this was recreated in testing. `botWorldSessionPtr->LogoutPlayer(true);` already deleted target internally, then comes `delete target;` to delete already freed memory and the whole thing crashes. * Players had the ability to logout anyone's alt/addClass bots. Now there's a check to make sure command is from master. * When commanded to logout, RNDbots in player's party used to reply with "I'm logging out!", but they don't, because they shouldn't, because they are not alt/adClass bots. Now they say "You can't command me to logout!" * Added early exits for the "logout cancel" block, then I remembered bots were made to always instantly logout because of past issues with timed logout. Need to review whether or not we should re-implement timed logout, or if it's not worth it and its dead code removed with instant logout remaining the only option. --- ## 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? This PR removes more code than it adds, and makes sure that exits happen as early as possible. It has no effect on processing power and makes the code slightly more maintainable. --- ## How to Test the Changes 1. Whisper `logout` to any bot whose master is not you. The bot can be RND/alt/addClass. The bot may have someone else as a master or may not have a master at all. The bot may be part of a party or not. Regardless, you are not its master. It should tell you "You are not my master!". Two players or two instances of the client from two different accounts are needed for this test, in order for Player A to command a bot to logout, when the bot's master is Player B. 2. Invite an RND bot to your party. As along as it's in your party, you are it's master, but RND bots cannot be logged out through chat commands. If you whisper `logout` to it, it should say "You can't command me to logout!", and not logout. 3. Whisper to an alt/addClass bot `logout`. The bot can be in your party or could've been uninvited. All that matters is that you are its master. It should reply "I'm logging out!" ## 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) In that it fixes wrong behavior. If this introduces more advanced or AI-heavy logic: - - [x] 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? - - [ ] No - - [x] Yes (explain below) Used Claude for code review, and translations. 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. --- ## Lines to Translate These are keys and defaults of lines that were added/edited, and to be translated at a later SQL update. \| Key \| Default line \| \| --- \| --- \| \| bot_not_your_master \| You are not my master! \| \| bot_rndbot_no_logout \| You can't command me to logout! \| --- ## 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-27 10:38:02 -07:00

1 2

88 Commits