Code reconciliation by SmashingQuasar · Pull Request #117 · ShatteredDawn/mod-playerbots

SmashingQuasar · 2026-07-23T15:05:03Z

No description provided.

mod-playerbots#2295  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.   - 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.   - 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.  - Does this change add bot messages to translate? - - [x] No - - [ ] Yes (**list messages in the table**) | Message key | Default message | | --------------- | ------------------ | | | | | | |  - Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  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. - - [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).  --------- 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>

@DustinHendrickson

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

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

…hant Spellcasting (mod-playerbots#2345)   Fix for issue mod-playerbots#2343 I excluded the MISC and FISHING POLE weapon subclasses from weapon enchants. MISC includes the entry profession "weapons" (skinning knife, mining pick, blacksmithing hammer, arclight spanner) and some other crap that I suspect is not enchantable, but even if it is there's no good reason to do so (like Brewfest steins). The subclass doesn't include weapons that can be used for professions but you might actually want to use for fighting (like Finkle's Skinner). To clean things up overall, I removed the intermediate class CastEnchantItemAction between CastSpellAction and CastEnchantItemMainHandAction and CastEnchantItemOffHandAction. CastEnchantItemAction is not doing anything helpful that can't easily be replicated in the MH/OH classes, and I can't think of any future reason for keeping CastEnchantItemAction. I also brought the CanCastSpell check into the MH/OH classes--previously it just wasn't run for the weapon enchant spells, and I can't think of any good reason why it shouldn't be. I also added Execute functions to both CastEnchantItemMainHandAction and CastEnchantItemOffHandAction so they actually directly cast the enchant on the specified hand instead of running through CastSpellAction's Execute (and thus going through item for spell). I wasn't having problems with the wrong hand being applied under the prior approach, but this is a more direct and better approach anyway. Other changes are just formatting.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. The new path is very similar to the old one but just adds a check that is common to all spells and early returns to avoid invalid results.  1. Log into a Shaman and activate selfbot 2. Check to make sure the correct enchantments are applied (e.g., MH Windfury and OH Flametongue for a dual-wielding Enhancement Shaman) 3. Equip a profession weapon such as a skinning knife and make sure the Shaman does not attempt to enchant it  - 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**) This just stops Shamans from trying to enchant stuff that they can't. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  I kicked around some ideas with GPT-5.4 with respect to the refactoring aspect of the PR after I had fixed the bug.  - - [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).

## Pull Request Description  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   - 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  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  - 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  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  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.  ## 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: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

## Pull Request Description This change fixes two cases of broken bot text with respect to inventory items. 1. Reserved inventory qualifiers such as "mount," "food," "drink," etc. no longer also trigger generic item name matching. I first noticed this problem when my resto Shaman who had the "Mounting Vengeance" weapon in her inventory would repeatedly give error messages of failing to use it while mounting (because mounting also causes bots to use items that fit the reserved "mount," which due to this bug, also caused bots to try to use any item with "mount" in its name). 2. Custom cast output text no longer reports an inferred bag item as the spell target for normal unit-targeted casts such as "cast chain heal on Keleborn." There was a bug where the action would first parse the actual target and then parse the spell text and then try to match the last word of the string to a bag item (so the bot would say it was casting chain heal on a healing potion, even though the heal was in fact cast correctly on a player). ## Feature Evaluation - Describe the **minimum logic** required to achieve the intended behavior. - Add a reserved-qualifier check in InventoryAction::parseItems() so reserved selectors do not also run through FindNamedItemVisitor. - In custom cast output text, choose the displayed target based on the actual target type already resolved for the cast. - It does not change mount selection behavior itself. - It does not add new spell-target parsing rules. - Describe the **processing cost** when this logic executes across many bots. - None. ## How to Test the Changes Reserved qualifiers: 1. Give a bot in your party the "Mounting Vengeance" weapon. 2. Mount up, and the bot should mount too without saying anything (before the fix, the bot would say it is using the weapon and that the item was not found). Spell cast text: 1. Give a bot an inventory item whose name overlaps with part of a spell name, such as a healing potion. 2. Command a bot to cast some heal on a player. 3. The bot should cast the spell on the intended player (as was the case previously), and the status text names the player instead of the inventory item. ## 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**) - 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**) Very minor changes. InventoryAction gets one explicit reserved-qualifier guard. Custom cast text selection becomes more explicit about which target type should be displayed. ## AI Assistance Was AI assistance used while working on this change? - [ ] No - [x] Yes (**explain below**) GPT-5.4 was used to trace the relevant code paths for the errors and propose the changes. ## 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>

mod-playerbots#2361)  ## Pull Request Description The previous logic contained two contradictory guards back-to-back: ``` // First check: passes only if IsRealPlayer() == true if (!leader || !GET_PLAYERBOT_AI(leader) || !GET_PLAYERBOT_AI(leader)->IsRealPlayer()) return false; // Second check: returns false if IsRealPlayer() == true PlayerbotAI* leaderBotAI = GET_PLAYERBOT_AI(leader); if (!leaderBotAI || leaderBotAI->IsRealPlayer()) return false; ``` The first guard (due to the erroneous `!` before `IsRealPlayer()`) only passes when the leader **is** a real player. The second guard then immediately returns `false` for the same reason, making the function incapable of ever returning `true`. ## Feature Evaluation   - 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  ## 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

…od-playerbots#2365)  ## Pull Request Description  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   - 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  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  - 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  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Review only in case I was missing something, and then to easily refactor duplicate code with HandleStrategyCommon.  ## 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  [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

…-playerbots#2156) Feature - Enable multi node flying for bots - Bots currently only do node to node flying. This PR makes it so they can connect multiple noted. -- This is enabled by sending a vector containing the node sequence instead of a single destination node -- To minimize the run-time cost of searching for available nodes and connection, a cache of all possible connections is prepared at start up using a BFS search algorithm. Refactor - Move all world destination logic (cities, banks, inns) to existing Travel manager - Eliminate flightmastercache and integrate to new manager - replace SQLs calls with in-memory data search by core - Add in new map that stores creature areas by template. Clean up - Move other rpg files to related folder. (Next steps) The selection for where bots fly to should be smarter than it is. Instead of trying to determine where a bot can go, it should first decide where it should go, and then identify the correct way to get there. --- 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? --- - 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 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**) The call itself is fairly infrequent, and although now there are a greater number of paths available for the bots, I dont think it would be significant. Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [x] Yes (**explain below**) Gemini first suggested the use of a BFS algorithm. This was rewritten by me to actually work as intended. Verification by additional logging not present in final code. Claude code converted the SQL filtering to the atrocious if statements found in PrepareDestinationCache, but after verifying them it works. If there are better ways to do this Im open to it. --- - - [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 --- Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging.

## Pull Request Description  Bot locations were not correctly registered, so they werent picking it as often as they should. In part related to mod-playerbots#2369 ## Feature Evaluation   - 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  ## Impact Assessment  - 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  Was AI assistance used while working on this change? - - [ ] No - - [ ] Yes (**explain below**)   ## 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

Incorrect var types when I refactored away from SQL lookup.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.   - 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**)  Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**)   - - [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).

## Pull Request Description  Some of the specs needed improvement. ## Feature Evaluation   - 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  ## 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. - - [ ] 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>

…conflict.

## Pull Request Description  Fix for polymorph spam in combat ## How to Test the Changes  1. Invite mage bot which have polymorph (check `spells polymorph`) 2. Enter combat and mage should not spam polymorph 3. Enter another combat best with multiple mobs and one of this mobs mark moon 4. Mage should cast polymorph on marked mob ## 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

## Pull Request Description  Added storing outfit in database. Related with: mod-playerbots#2239 ## How to Test the Changes  1. Invite altbot 2. Use command `outfit testcollection +[itemlink]` to add outfit collection and item 3. Check that is added `outfit ?` 4. Logout bot for example via multibot 5. Login bot 6. Check that is still added `outfit ?` ## 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**)  To identify places to change.  ## 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  Result after bot relogin: <img width="701" height="206" alt="obraz" src="https://github.com/user-attachments/assets/ea6c875a-65dd-4a01-9d35-381c8b374abd" />

## Pull Request Description  Fix for `lfg` to include healers in invitations and requester role. ## How to Test the Changes  Use command `/1 lfg 40` on server which contains correct amount of bots possible to be invited. Such group should be create. ## 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**)  To identify reason.  ## 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

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.   - 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.  Run the Black Temple raid and see if my descriptions of strategies in the next post check out.  - 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**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  GPT-5.4, mainly for calculations and things that are more intermediate concepts that I’m not proficient with like lambdas.  - - [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).

## Pull Request Description  Paladin no longer using Hand of Freedom on Rogue with Stealth Related with: mod-playerbots#2385 ## How to Test the Changes  1. Invite paladin and rogue to group 2. Start fight 3. Rogue should use Stealth on fight beginning, Paladin should cast Hand of Freedom 4. Apply some snare effect to Rogue bot (for example .aura 1715) 5. Paladin bot should use hand of freedom ## 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

…layerbots#2395)  ## Pull Request Description  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   - 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  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  - 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

…ts reliably with Ninja instead of the Visual Studio/MSBuild generator (mod-playerbots#2383) Added a Windows CI fix to build with Ninja and avoid Windows command-line length failures.  This PR updates the Windows CI workflow to build AzerothCore + mod-playerbots reliably with Ninja instead of the Visual Studio/MSBuild generator. The previous Windows build could fail during the final `worldserver` build steps because MSBuild/RC generated command lines that exceeded Windows command-line limits. Enabling long-path support was not enough, because the failure was caused by tool command length rather than only filesystem path length. This workflow now: - installs and uses Ninja as the CMake generator; - creates an AzerothCore `conf/config.sh` for CI; - forces the compiler to MSVC `cl`; - enables CMake/Ninja response files to reduce command-line length; - moves the source tree to a short path (`C:\ac`) before configuring and building. This keeps the Windows build on MSVC while avoiding the MSBuild/RC command-line length issue. **Pros:** - Fixes Windows CI command-line length failures; - avoids unreliable `rc.exe` / `MSB6003` errors from the MSBuild generator; - keeps the build on MSVC; - makes the Windows CI build more predictable; - does not affect runtime code or bot behavior. **Cons:** - Visual Studio project files (`.vcxproj`) are no longer generated in CI; - the workflow now copies the source tree to a short path before building. - Minimum logic: CI-only workflow changes to use Ninja, force MSVC, enable response files, and build from a short path. - Processing cost: None at runtime. This only affects GitHub Actions build tooling. - Run the Windows CI workflow on GitHub Actions. - Confirm that CMake reports `-- Building for: Ninja`. - Confirm that CMake detects MSVC as the C and C++ compiler. - Confirm that the Windows build completes successfully. - Confirm that no MSBuild `MSB6003`, `rc.exe`, or Ninja `CreateProcess` command-line length errors occur. - 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] No Was AI assistance used while working on this change? - [x] No Maybe if should so i'd made less commits... - [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). This change is CI-only and does not affect gameplay, bot logic, database logic, or runtime performance. The Windows workflow was failing because generated build commands became too long for Windows process creation. Switching the CI build to Ninja, forcing MSVC, enabling response files, and building from `C:\ac` fixes the issue while keeping the compiler/toolchain consistent with the Windows target. --------- 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>

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.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.   - 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**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)   - - [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).

@kadeshar

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 mod-playerbots#1421 mod-playerbots#2120 Fixes mod-playerbots#1219 NOTE: Not all of them, I have updated affected changes in working on that in near future. Before posting bugs check mod-playerbots#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.    - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.   - 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  Was AI assistance used while working on this change? - - [ ] No - - [x ] Yes (**explain below**)  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.  - - [ 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).  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>

This PR refactors the Blackwing Lair strategy to align with newer raid strategy implementations. It extracts repeated Blackwing Lair spell IDs, game object IDs, and suppression device checks into a shared helper, so the action and trigger code use the same centralized definitions instead of duplicating literals and condition chains. No gameplay behavior changes are expected. This PR is intended as a base for follow-up PRs that introduce additional boss-specific strategy logic.   - Describe the **minimum logic** required to achieve the intended behavior. - Move existing BWL-specific constants and the suppression device condition into a shared helper. - Keep all existing trigger names, action names, spell IDs, game object IDs, and condition checks unchanged. - Update the affected action/trigger implementations to call the helper instead of duplicating the same logic inline. - Describe the **processing cost** when this logic executes across many bots. - No meaningful increase. The logic executed per bot remains effectively the same. - This refactor only replaces duplicated inline checks with a shared helper function and named constants. - There are no additional scans, branches, state tracking, or new decision loops.  Run the Blackwing Lair raid and check if the already implemented features still work: - _Onyxia Scale Cloak handling_: Confirm the bot still applies/checks the same aura as before. - _Suppression device handling_: Confirm bots still detect nearby active suppression devices and turn them off under the same conditions as before. - _Chromaggus bronze affliction handling_: Confirm bots still use Hourglass Sand if they have the bronze affliction.  - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [x] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) A small helper call was introduced for the suppression device check, so there is technically a minor additional call overhead compared to the previous inline condition. In practice, the executed logic, iteration scope, and decision flow remain unchanged, so the impact is negligible and does not introduce meaningful scaling risk. - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  AI was used for review support and drafting the pull request text. The refactoring itself was done manually.  - - [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).  This PR is intended to be behavior-preserving only. The main change is consolidation of repeated Blackwing Lair constants and suppression device logic into a shared helper used by both actions and triggers. Review can focus on verifying that the extracted helper matches the previous conditions.

## Pull Request Description  Fixed bug with finding russian texts (loc8) Related with: mod-playerbots#1884 ## How to Test the Changes  1. Use ru client 2. Invite bot 3. Use command `focus heal ?" ## 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**)  Find and fix wrong places checking texts  ## 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

Disc Priests currently do not use Power Word: Shield until a party member is at "medium health" (configurable, default 65%). That is the second-level healing threshold; at the highest level, "almost full health" (configurable, default 85%), Disc Priests will use only Prayer of Mending and Renew. This PR adds PWS as the highest priority healing action starting at "almost full health."   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Added new action "power word: shield on party" to "party member almost full health" trigger in HealPriestStrategy.cpp (the "heal" strategy, which is the default strategy for Disc Priests, as Holy Priests use the "holy heal" strategy).  Group up with a Disc Priest and take damage; confirm that PWS is cast when you drop below your configured almost full health threshold.  - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) PWS is the signature ability of Disc. Priests, and delaying it to 65% is significantly limiting their effectiveness in group content, particularly with raid bosses that deal raidwide damage and in heroic dungeons, where waiting until the tank hits 65% is a death wish. This single change makes an enormous difference in their effectiveness. See below for before/after change for Eredar Twins (focus on the activity). Before: <img width="693" height="397" alt="Screenshot 2026-05-18 201949" src="https://github.com/user-attachments/assets/18ad84c7-9ad8-4c39-94e7-650c9bb5f36e" /> After: <img width="746" height="409" alt="image" src="https://github.com/user-attachments/assets/6240f118-e12f-44c7-a1af-373e94985957" /> - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**)  Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**)   - - [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).

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

@Dreathean

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).   - 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.  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.  - 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**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  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.  - - [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).  @Dreathean Perhaps the wiki can be updated to document the bdps and bmana strategies for Mages?

@brighton-chi

Hello playerbots community! Through testing and feedback, two issues have been brought to my attention with the druid update: 1. **The blanketing strategy is messing with the healer dps/healer should attack function**, as outlined in issue mod-playerbots#2428 . It's also clunky in small groups/solo play. I have decided to remove the blanketing strategy from the list of default resto strategies. It is now an optional strategy only, enabled on resto druid by typing "co +blanketing" for those difficult healing fights. 2. **Prowl both existing in the combat strategy (catdruidstrategy) and noncombatstrategy has proven to be taxing/higher cpu usage than I would like** - @brighton-chi identified that prowl was high on the pmon output, and I confirmed locally that it was quite taxing. To fix this, I tested this by removing the prowl trigger/action from the non-combat strategy, and the numbers went down significantly. It's because it was constantly scanning for targets while not in combat, similar to how the pvp strategy does (not enabled by default, very taxing). Most rndbots aren't in combat, so this was scanning on all rndbots that were feral (cat) while out of combat. Now, it being only in the combat strategy is appropriate - the trigger returns early, and doesn't even scan if the bot is in combat. This is the prowl trigger: Bot is not already prowling and not in combat Bot has the Prowl spell and it's off cooldown A valid target exists within engagement range (checks enemy player → grind target → dps target in priority order) Distance check: 30y base, −10y if target has a victim, −10y more if target is also moving (floor 10y), +15y in BG or Arena After I made this change locally, I tested it, and the only difference is that the cat will no longer go into prowl when outside of combat (walking around with master, unengaged to enemy target). It will still go into prowl when told to attack a target, or dps assist. We could potentially look at adding this back in, in a different way, when pvp becomes more of a focus.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. This reduces the processing cost of prowl and the blanketing strategy quite a bit, while still being functional in the situations that need those abilities/strategy.   - 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**) It reduces processing costs. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) The cat druid will no longer preemptively go into prowl before the enemy is set to be attacked. It was cool to see the cat go into prowl when getting close to a mob, but there was a lot of processing cost with this outside of combat, so it's being shelved. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)   - - [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).

)  ## Pull Request Description  There's really no good reason to have it disabled as default. Let them have their class quest spells on levelup. ## Feature Evaluation   - 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  ## 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? - - [ ] No - - [x] Yes (**explain why**) They learn their class quest spells by default now. - 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

Adds strategy for ranged and tank bots when fighting Death Talon Wyrmguards. Ranged will stay 16 yards away so as not to get hit by war stomp. Tanks that are actively tanking at least one wyrmguard will move away from other wyrmguards not they are not tanking. The main issue I'm still having is healer positioning, sometimes the tanks will outrange the healers in their attempt to stay away from eachother, but imo the fight is already alot smoother.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.  Go to BWL and pull the Wyrmguard 3 packs. Ranged should stay away from all Wyrmguards, and tanks should attempt to spread out the wyrmguards. I still split the pull between tanks using rti targets and pull back, since the tanks done actively pull mobs off of eachother.  - 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**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Claude was used to generate the tank actions that checks for nearby untanked wyrmguards. I have reviewed and refined claude output afterwards.  - - [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).  --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>

…layerbots#2478)   When a bot has the Enchanting skill but its level is insufficient to disenchant an item, the old code returned `ITEM_USAGE_NONE` immediately. This caused the bot to pass on loot rolls for items it could have used for other purposes (equip, quest turn-in, crafting reagents, guild tasks) because the function never reached those downstream checks. The fix combines the skill check and binding check into a single positive condition: the bot only returns `ITEM_USAGE_DISENCHANT` when it is both skilled enough and the binding allows it. Otherwise, execution falls through to the remaining item usage evaluations as intended.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. - **Minimum logic:** Replace two separate guards (one early-return `NONE`, one positive `DISENCHANT`) with a single combined `if` that returns `DISENCHANT` only when both conditions are met. No new branches — one fewer than before. - **Processing cost:** Identical. The same two comparisons execute once per disenchant-eligible item evaluation. No change to per-bot or per-tick cost.  1. Spawn a bot with Enchanting skill at a low level (e.g. 1/75). 2. Loot or roll on an armor/weapon item with `RequiredDisenchantSkill` higher than the bot's skill (e.g. a level 50 blue with required skill 225). 3. **Before:** The bot returns `ITEM_USAGE_NONE` and passes on the item, even if it could equip it or use it for a quest. 4. **After:** The bot correctly evaluates remaining usages (equip, quest, etc.) and rolls Need/Greed appropriately.  - 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**) Same number of comparisons, one fewer early-return path. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Bots with insufficient enchanting skill will now correctly consider non-disenchant uses for items they previously passed on entirely. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) Reduces branches from two `if` statements to one.  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) AI was used to refactor the two-condition guard into a single combined condition. The logic was reviewed and the behavioural difference (fall-through vs early return) was verified manually.  - - [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).  The root cause was that `return ITEM_USAGE_NONE` on the skill check short-circuited the entire `Calculate()` function, skipping all downstream item usage evaluations. The fix simply lets execution continue past the disenchant block when disenchanting isn't viable. Co-authored-by: avirar <avirar@users.noreply.github.com>

## Pull Request Description  This is mainly to address the issue of bots continuing to attack Mages with Ice Block and Paladins with Divine Shield. I made the actual check a little broader to capture all cases of when a target is both physical and magical immune. ## Feature Evaluation   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Just added immunity checks to AttackersValue::IsPossibleTarget() ## How to Test the Changes  The easiest way is to play a Mage or a Paladin and go zerg into the opposing team, then put up Ice Block/Divine Shield. ## 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**) This is a new check when determining possible targets, but it should be very cheap. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Default bot behavior is idiotic as they stick to immune targets like glue. - 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**)  I wanted to capture more than just Ice Block and Divine Shield (which would have been simple aura checks) so I had DeepSeek *shudder* look at the spell flags.  ## 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

Well, this is what I was doing while I let AI do the buff announcements PR... GL was the first strategy I wrote alone (Revision started Karazhan), and it sucks. Since AC has now fixed Olm to actually chase and Kiggler to no longer move to within his Arcane Explosion distance, it was a good time to redo things. Overall, the code should be much simpler and better for performance. I also tweaked several strategies. My raid is close to expansion BiS now so I tested at 20/20 damage/healing IP nerfs. One shot both, and overall the bot coordination is a lot smoother than I remember when I was actually running these raids. Some stuff is still not great, like GruulTheDragonkillerSpreadRangedAction() is overdone for sure, but I've spent all the time I'm willing to on this one. I don't want this to become a longer project.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Same structure as before. Improved commonly used methods based on experience since I did the original strategy (e.g., how to do tank movement or spread bots), threw out some super complicated, bulky methods in favor of much simpler ones that work better anyway, yadda yadda.  Go fight HKM and Gruul. For HKM, bring three tanks, a mage, and a boomin. For Gruul, bring an alarm clock.  - 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**)  Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**)   - - [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).

**Pull Request Description** The admin team have voted to relicensing from GNU AGPL v3.0 to GNU GPL v2.0, aligning mod-playerbots with the licenses of both its upstreams — AzerothCore (GPLv2) and the CMaNGOS playerbots Bot AI core it is derived from (GPLv2). This PR begins that process by defining all future code at GPLv2 while any previous code undergoes approval by the contributors, or has its licenses fixed to the correct attribution. **What this PR does** - Replaces the root LICENSE with GNU GPL v2.0 text. - Updates PULL_REQUEST_TEMPLATE.md with a Code Provenance / Attribution question (was any code copied/adapted from a sister project — if so, name the project and original authors) plus checklist items for attribution and the GPLv2 header on new files.

## Pull Request Description  Alts retain the taxi cheat flag on log out. This removes it without impacting behaviours. ## Feature Evaluation   - 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  Logging into a alt after they have been a bot should no longer show all the flight paths they havent learned. ## 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**)  All of it. Manually verified.  ## 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

Bots will now learn the flight node when interacting with the flight master. The goal is to try to reduce instances of cheating.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.   - 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**) They will learn the nodes. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Claude authoring.  - - [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).

## Pull Request Description  Currently Loot and Gather strategies cannot be removed by bots. After introducing bot professions players have noted that they have to compete with bots, and we just cant have that. This will enable the gather strategy to be removed from random bots. This disables all Herb/Mining/Skinning from bots if the strategy is removed (In config). ## Feature Evaluation   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. It actually improves performance. ## How to Test the Changes  Remove strategy in config. Bots no longer herb/mine ## 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**)  Yes.  ## 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

@kadeshar

Related to what was discussed with @kadeshar during the group buff/greater blessing rewrite PR. This adds a general announcement that bots will make when they try to cast a group buff or greater blessing but don't have the requisite ingredients and instead cast the single version (the announcement is not made unless the single version is successfully cast). The announcement is enabled by default, but I'm fine with disabling by default too. I have no real opinion there. The frequency of the announcement can be configured also and is 5 minutes by default. I also set up the framework for the message to be translatable. I deleted an old sql that was related solely to the prior announcement system. There are other sqls that add the lines for the prior announcement system, but I didn't want to partially edit old sqls since that seems like a bad path. Also, I did not renumber entries so there are now some unused entries in the tables.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. The announcement is made through GroupBuffSpellAction::Execute() for group buffs and CastGreaterBlessingAssignmentAction::Execute() for greater blessings. Helpers were added to get the announcements and handle the delay and pruning of the associated map. Announcements are gated behind the bot actually attempting the group/greater variant so are controlled by the respective configs (disabled, raid only, group only).  Enable AutoGreaterBlessings and/or AutoPartyBuffs. Make bots destroy reagents if they have them. Check for announcements when they cast single variants. Check to see if gap between announcements matches MissingBuffReagentMessageCooldown.  - 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 a map used to throttle the announcements, but it's small and gets pruned whenever the next announcement is made or the bot can cast the greater buff again. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Announcements are made by default. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Translations will be needed.  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  I'll be honest--this one was very much a "needed to be done but also super uninteresting" PR. So I totally took a backseat to AI here.  - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [ ] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands).

…od-playerbots#2110) performance improvements This refactor makes `RandomItemMgr` faster, safer, and easier to maintain. It reduces cache scans, cuts extra copies, improves DB work, and makes item checks more direct across equip, ammo, rarity, and random item logic. - **Switched `std::map` to `std::unordered_map`** - internal caches now use hash maps, and `BotEquipKey` has a proper hash function, so most lookups are faster. - **Switched `std::set` to `std::unordered_set`** - item and slot containers now use hash sets for faster insert, find, and erase operations. - **Fixed argument order** - many methods had arguments in the wrong order, for example `CanEquipWeapon(class, item)` is now `CanEquipWeapon(item, class)`, and the same style is used everywhere. - **Aligned method signatures with header definitions** - method order and parameter types were cleaned up to match the header and make the code easier to follow. - **Used one DB transaction for cache build** - `BuildCacheEquip`, `BuildCacheRandomItem`, and `BuildCacheRarity` now add all records in one transaction instead of one by one, so there are fewer DB round-trips. - **Split cache load and cache build** - each cache now tries to load data from DB first, and only rebuilds if the cache is empty, so startup does less work. - **Fixed cache bucket logic** - food and trade caches now use the correct level buckets, and rarity loading now reads query results in the right way. - **Reduced cache lookup cost** - old code used linear scans and extra loops over item lists, while new code uses direct hash map lookups. - **Reversed `viableSlots` mapping** - it now goes from `InventoryType` to `EquipmentSlot`, so code can find needed slots directly without scanning the whole map. - **Pre-computed weapon use rules at init** - weapon checks are now prepared once in `InitWeaponProficiency`, so class-to-weapon checks are just a fast bitwise check. - **Simplified `CanEquipArmor`** - armor rules were cleaned up and moved into one clear place instead of a long `if/else` chain. - **Rewrote `CanEquipItem`** - the method now uses the new cache layout and simpler checks, with better defensive handling for invalid data. - **Renamed and improved `IsTestItem` to `IsInternalItem`** - it now checks item flags and names in a better way, so test and internal items are skipped more reliably. - **Renamed and improved `GetCachedEquipments` to `GetEquipmentNew`** - it now returns a reference to avoid copying the whole item list every time the method is called. - **Added `GetEquipment`** - equipment lookup now uses `equipCache` directly and has extra checks for null or invalid item data. - **Removed extra trainer processing** - `IsCraftedBySkill` now uses a direct `SkillLineAbility` lookup instead of looping through all trainers, which saves time. - **Added `IsValidItem`** - all item validation rules were moved into one shared method, so other code can reuse the same checks. - **Changed `GetAmmo`** - it now returns a single item id instead of a vector, which makes the logic simpler and faster. - **Used `IsInternalItem` in bot item setup** - test and internal items are filtered with the shared check during item init. - **Made `Query` safer** - it is now `const` and uses direct map lookups instead of default inserts and full scans. - **Made item getters return from cached buckets** - `GetAmmo`, `GetRandomPotion`, `GetRandomFood`, and `GetRandomItem` now use cached data directly and avoid extra copying. - **Improved cache load logs** - `LoadCacheEquip`, `LoadCacheRandomItem`, and `LoadCacheRarity` now clearly report empty cache cases. - **Used `IsValidItem` before random item cache fill** - item validity checks are now handled in one place before the cache is filled. - **Kept most of `BuildCacheItemInfo` unchanged** - the heavy weight calculation and the commented quest or vendor code were mostly left for a separate refactor. - **Initialized helper tables in one place** - weapon proficiency, predicates, viable slots, and weight links are now set during `RandomItemMgr` init. - **Moved predicate setup into `InitPredicates`** - this keeps constructor code smaller and makes cache rules easier to follow. - **Simplified `GetRandomItem`** - random item selection now uses the cached list directly, without manual index handling. - **Improved `BuildCacheRandomItem` filtering** - temporary, invalid, and internal items are skipped earlier, before the cache is filled. - **Removed some dead code** - old vendor and loot drop scan code that was already unused or commented out was cleaned up where it was safe. - **Improved logging** - cache load and build functions now show timing and record counts in a consistent way. - **Added better defensive checks** - several methods now guard against null pointers and invalid templates before using item data. - **Fixed server loading messages and comments** - load logs and code comments were updated for clearer output and easier maintenance. - **Fixed warnings and broken trinket logic** - warning cleanup also corrected a bad trinket-related condition. The main result is faster and cleaner item processing for bots. Cache lookups are cheaper, startup work is smaller, and item checks are more direct, which should help both performance and stability. This also makes the code easier to change later. The new structure gives clearer methods, better cache flow, and fewer repeated checks across equip, ammo, rarity, and random item logic. - Did not touch anything related to item weight calculations, loading, and building - this part should be refactored separately. - Did not rewrite `PlayerbotFactory` methods, as they are clearly duplicating `RandomItemMgr` ones and also have their own logic problems with loop order and iteration - that is a separate topic. - Did not clean up most of `BuildCacheItemInfo` and did not remove dead code or methods used inside commented-out blocks (`GetQuestIdForItem`, `GetQuestIdsForItem`). --- 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. --- - 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 - 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**) --- - Does this change modify default bot behavior? - [x] No - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - [ ] Lightweight mode remains the default - [ ] More complex behavior is optional and thereby configurable --- - Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - [x] No - [ ] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- - [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 --- 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>

## Pull Request Description  There are two changes in this PR. Tank RTI Targetting: Right now tanks don't really care about their RTI target other than when using "pull rti target" With this change a tank who is given an RTI target will make keeping the rti target aggrod to them priority 1, even from other tanks. Regular tank assist targetting follows after. "Main tank" ambiguous behaviour: When running with multiple tank bots where no tank has main tank assignment, the "default" main tank (whichever tank comes first in the lookup) will taunt off of other tanks. Imo this is ambiguous behaviour, since the player never actually set any main tank they would expect the tanks to never be taunting off of eachother. ## Feature Evaluation   - 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  RTI targets: Get two tank bots and assign one bot an rti mark like "rti cross". Go to a pack of at least two enemies and mark one with the rti mark. (I used the first pull in MC) Mark skull on a different enemy. Both tanks will go and attack the skull. After the change the rti mark tank will go and attack the marked target instead of skull. Main tank behaviour: This one is difficult to test because its hard to tell which tank is considered the default main tank. Get two tank bots and do not mark any as main tank. Tell one tank to attack something, keeping the other tank on passive or flee until the first tank gets aggro. Send the second tank to attack. If the second tank was the default main tank it will taunt the mob off the first tank. Otherwise reset and reverse the tank attack order to see the behavior. After the change neither tank should tank off eachother. ## 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**)  Claude generated IsExplicitMainTank function. It was thoroughly reviewed and tested.  ## 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

@Celandriel

…2470)   Followup to several warnings cleanups done few months ago by @Celandriel. The hope is that we can live in a world where our children never see a compiler warning on the master branch. PR is in fourcommits. 1. The first one is obvious incorrect casts, reordering of header signatures, incorrect brackets. 2. The second deletes unused variables/code and redundant user-defined copy constructor. 3. The third removes EquipmentSlots enum declaration, and it must be merged with this core commit mod-playerbots/azerothcore-wotlk#222 Four years ago there was a crash happening in RandomItemMgr.h because of the declaration of EquipmentSlots. NoxMax/azerothcore-wotlk@db71f47 The correct fix was to include Player.h. Instead the enum was forward-declared in Playerbots, and changed in Player.h to uint32. That fixed the crash, but left a warning ever since. The third commit is a proper fix to the crash, that reverts the core changes, and doesn't create warnings. 4. Last one modifies the PR template to remind people not to add new warnings. I think we should eventually edit the .yml file for GH Action to treat warnings as errors, but for now, I am just adding this as an advice for the short term before we enforce it. I pasted the checkbox in this PR description too just as an immediate example.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.  Changes should compile without any errors and warnings, if you apply it to the current state of test-staging. There might be other errors introduced from accompanying new PRs.  - 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**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Had Claude go through a long, long, list of warnings of all those int/uint comparisons.  - - [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). - - [x] New and modified files do not introduce new compiler warnings.  Do not fear the 70 file diff. The 70 file diff should fear you. But seriously it's not as scary as it looks. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>

## Pull Request Description  Just another instance of me doing something stupid and thereby uncovering an issue that would probably affect nobody else ever. Plus some other stuff I noticed along the way. I had set my Druids to Swift Flight Form in the preferred mounts table, which is totally unnecessary since they will prefer SFF (or regular Flight Form) anyway. But by using the preferred mounts table, I caused SFF (and would have happened with FF too) to move very slowly in short bursts. This is because ShouldFollowMasterMountState, which should return false if the bot is already mounted, didn't recognize Flight Forms as being mounted. So it would return true, call Mount, then call TryPreferredMount, and because I had SFF in the preferred mounts table, the bot was trying to recast SFF every tick while already in it. So I've added the Flight Forms (and Travel Form) to the checks in ShouldFollowMasterMountState to stop this. I also noticed that TryForms required the master to have a 280% mount for a Druid bot to use SFF, meaning that the Druid wouldn't use it if the master has a 310% mount. It will still use a 280% mount, but not SFF. Druids should always be able to use SFF because if they obtain a 310% mount, SFF gets upgraded to 310%. So I just changed the masterSpeed check from == 279 to >= 279. Finally, TryRandomMountFiltered was looping mounts from slowest to fastest, meaning that if a bot had 280% and 310% mounts, it would always pick a 280% mount. This makes no sense so I reversed the order, and now it will prioritize picking a 310% mount. ## Feature Evaluation   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Minimum logic is described above. This should have no impact on processing cost. ## How to Test the Changes  1. Make Flight Form or Swift Flight Form the preferred mount in the preferred mounts table for a Druid. Mount up and make sure the Druid transforms and follows properly. 2. Use a 310% mount with a bot Druid in your party that doesn't have a preferred mount. Make sure the Druid uses Swift Flight Form instead of picking a random mount. 3. Use a 310% mount with a bot in your party with at least one 310% mount and at least one 280% mount. Try this repeatedly and make sure the bot always picks a 310% mount. ## 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? - - [ ] No - - [x] Yes (**explain why**) Bots will pick a 310% mount over a 280% mount if they have both; before it was always the opposite. - 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 DeepSeek v4 Pro to figure out the cause of the stuttering movement in Flight Form and to implement the fix for the TryRandomMountFiltered loop reversal.  ## 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

Strategies for RS Tested all bosses all diffs. For optimal results: 10 Man 2 tanks 2 healers 3mdps 3 rdps 25 Man 2 tanks 6 healers 8mdps 9rdps tank and healer number is a must since bots will split into 2 groups during P3, half of bots must do physical realm, other half must do twilight realm and while each group doing seperate tactics they need to synchronize boss hp (if one group gets ahead boss will heal). Whole fight will only function if bots are tanks (main and assist) since whole Halion fight is dynamic it is crucial to let tanks tank both bosses. Player need to know tactics, since player can wipe raid if they fail to move away from group.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Eneter Ruby Sanctum, engage bosses, bots will do boss stragies now and clear raid on all diffs. Gearing and knowing tactics is crucial for real player. (eg. 25hc with naxx gear will wipe, player not moving with combustion will wipe raid, etc...) Minimal cost and its cross instance safe.  1. Enter RS 2. Engage bosses 3. Try not to wipe group by not tracking your debuffs 4. Kill bosses 5. Gear up!  - 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**) Adds new strategy for RS. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Adds new strategy for RS.  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Used AI for complex math calculations for dynamic cutters avoidance and scanning for them in arch instead of directly since boss needs to be rotated constantly during cutters are active.  - - [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).

…t 5 (mod-playerbots#2502)  ## Pull Request Description  Fixes `.playerbots bot add` silently dropping the bot that becomes the **6th** member of a group. **Symptom:** when the master is already in a full 5-person, non-raid party and one more bot is added, that bot is silently dropped and never joins. The party usually still converts to a raid (the client shows *"You have joined a raid group"*) but the new member is missing; in some timing paths the client instead shows *"You are not in a raid group."* Same root cause either way. **Root cause:** in `PlayerbotHolder::OnBotLogin()` (`src/Bot/PlayerbotMgr.cpp`), the `>= 5 members` branch queues a `GroupConvertToRaidOperation` and then gates the `GroupInviteOperation` behind `if (mgroup->isRaidGroup())`. The convert is only **queued** (not applied) at that point, so `mgroup->isRaidGroup()` is still `false` on the next line — the invite is never queued and the member is dropped, while the queued convert still runs (leaving the party converted but without the new member). This appears to have surfaced with the move to the queued `PlayerbotWorldThreadProcessor` model; an earlier synchronous `ConvertToRaid()` would have made the group a raid before the guard was evaluated. **Fix** (in the `>= 5` branch): 1. **Remove the now-redundant queued `GroupConvertToRaidOperation`.** `GroupInviteOperation::Execute()` already self-converts a non-raid group with `>= 5` members to a raid before adding, so a separate convert op is unnecessary. (The `GroupConvertToRaidOperation` class is unchanged — it still has other callers in `src/Ai/Base/Actions/InviteToGroupAction.cpp`.) 2. **Widen the invite guard** so the invite is queued for a plain party too — the case the old code converted but never invited into: ```cpp // before: if (mgroup->isRaidGroup()) // after: if (mgroup->isRaidGroup() || (!mgroup->isLFGGroup() && !mgroup->isBGGroup() && !mgroup->isBFGroup())) ``` The branch collapses to a single guarded invite; `Execute()` does the party→raid conversion before adding. This deliberately does **not** simply remove the guard: that would queue an invite for LFG/BG/battlefield groups and force-convert them. ## Feature Evaluation  - **Minimum logic required:** delete the queued-convert block and change one boolean guard. No new operations, no new state, no new per-tick work. - **Processing cost across many bots:** strictly **lower** than before — this path now queues **one fewer** operation (the redundant `GroupConvertToRaidOperation`) each time a bot logs into an already-full group. The guard itself is a cheap boolean evaluated only on bot login (not per tick). ## How to Test the Changes  Setup: a normal 3.3.5 realm with playerbots; a master account with several alt bots. **Deterministic reproduction (before the fix):** 1. Log in as a player (the master), solo. 2. `.playerbots bot add` four bots and wait until they are actually in your party — you now have a full, non-raid party of 5. 3. `.playerbots bot add` one more bot. - *Before:* the party converts to a raid, but the 6th bot is **not** in it (dropped). - *After:* the 6th bot joins; the party becomes a raid containing all members. > Note: adding all bots in a single command often "works" even unpatched, because > the bots' logins can all be processed before the group fills (each takes the > group-creation path). Adding the 6th to an **already-full** party reproduces it > every time. Full matrix verified in-client with the fix (all pass): party `<5` add; solo add (creates group); existing-raid add; and a 5-man **LFG** group add (correctly left untouched — no force-convert). Verified with a temporary instrumented build: ``` QUEUE invite (>=5): raid=false ... <- plain party (the bug) -> now joins QUEUE invite (>=5): raid=true ... <- existing raid -> joins SKIP invite (>=5, LFG/BG/BFG): raid=false lfg=true ... <- LFG left untouched ``` `Errors.log` was empty across all scenarios. ## 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**) Runs only on bot login, and removes one queued operation — net less work, no per-tick cost. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Only the broken case changes: adding a bot past 5 in a plain party now succeeds instead of dropping the bot. Behavior is bit-identical for raids and LFG/BG/battlefield groups (see the truth table in Notes for Reviewers). - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) It removes a branch (the queued-convert block); the `>= 5` case collapses to a single guarded invite. ## AI Assistance  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) AI (Claude) assisted with investigating the root cause, building a temporary diagnostic logging harness to trace the exact code path on a live test realm, and drafting this description. I reproduced the bug myself, deterministically, on a live 3.3.5 realm (adding a 6th bot to a full 5-person party), verified the fix in-client across the group-type matrix above, and reviewed and understand the one-file logic change. I own this change. ## 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. (N/A — no new dialogue.) - - [x] Documentation updated if needed (Conf comments, WiKi commands). (N/A — no config/command changes.) ## Notes for Reviewers  **Why LFG/BG/battlefield behavior is unchanged.** The only externally observable change is whether the `GroupInviteOperation` is queued. Comparing the old guard `R` against the new `R || (!L && !B && !F)` over every group kind (`R`=isRaid, `L`=isLFG, `B`=isBG, `F`=isBFG): | Group kind | R | L | B | F | old `R` | new `R \|\| (!L&&!B&&!F)` | change | |-----------------------|---|---|---|---|---------|---------------------------|--------| | Raid (incl. BG raid) | 1 | * | * | * | 1 | 1 | none | | LFG party | 0 | 1 | 0 | 0 | 0 | 0 | none | | Battleground party | 0 | 0 | 1 | 0 | 0 | 0 | none | | Battlefield party | 0 | 0 | 0 | 1 | 0 | 0 | none | | Plain party (the bug) | 0 | 0 | 0 | 0 | 0 | **1** | **fix**| The guards are bit-identical for every raid/LFG/BG/battlefield combination and differ only for a plain non-raid party — the bug. Removing the redundant convert op is likewise invisible for those kinds (it only ever fired for the plain-party case). Scope: single C++ file, pure logic change — no schema, config, DB, or API impact.

…2494)   **The tl;dr version**: This PR lets you make dungeon/raid strategies that allow tanks or dps to do what they normally do, except completely ignore [insert target] under [insert conditions]. **The longer version:** This PR implements the ability for scripts to modify values used for bot target selection in order to exclude specified NPCs. Currently, doing this is possible only through assigning the moon icon, and even that doesn’t block actions that target through the “on attackers” path (i.e., actions relating to multi-dotting). Under this PR's approach, a bot evaluates its target, exclusions are gathered from all active combat strategies, and then they are applied before the strategy's own selection logic runs. This means excluded NPCs never enter the candidate pool in the first place. The bot simply acts as if they aren't there, rather than the strategy reacting after a bad target has already been chosen. This capability is useful because it allows dungeon/raid scripts to command bots (or certain bots or types of bots) to ignore particular targets without completely suppressing their standard target selection behavior. Previously this could be done only with blanket overrides of TankAssistAction or DpsAssistAction and then creating an entirely new custom targeting scheme, which practically would have to be much simpler than the default targeting schemes, especially for tanks. I use this for SWP strategies, and therefore they cannot be implemented until this system (or a similar one) is in place. The system is very easy to use and can be done entirely in the strategy.cpp and strategy.h files for the dungeon/raid strategy you are working on. 1. Declare a HasTargetExclusions member of the dungeon/raid strategy class (bool HasTargetExclusions() const override { return true; }). 2. Declare an AppendTargetExclusions member (void AppendTargetExclusions(GuidSet& exclusions, TargetValueExclusionType type) override) 3. Make a void function for each exclusion that contains the conditions for your exclusion and the target(s) being excluded. 4. In the definition of AppendTargetExclusions for the dungeon/raid strategy class, you can then select between any or all of tank, dps, and attackers value exclusions with a switch statement. For example, the following sets up an exclusion that prevents tanks and melee dps from considering Shield Orbs as valid targets during Kil’jaeden: ``` void AppendKiljaedenShieldOrbExclusions(PlayerbotAI* botAI, GuidSet& exclusions) { if (!botAI->IsMelee(botAI->GetBot())) return; if (!botAI->GetAiObjectContext()->GetValue<Unit*>("find target", "kil'jaeden")->Get()) return; for (ObjectGuid const guid : botAI->GetAiObjectContext()->GetValue<GuidVector>("attackers")->Get()) { Unit* attacker = botAI->GetUnit(guid); if (!attacker) continue; if (attacker->GetEntry() == static_cast<uint32>(SunwellNpcs::NPC_SHIELD_ORB)) exclusions.insert(guid); } } ``` The above is needed because I need tanks and (depending on positioning) melee dps to switch to Sinister Reflections when they spawn and back to KJ, but they should not go after the Orbs. There are four Sinister Reflections that spawn at a time so manually setting up a system for tanks and melee dps to decide between which to attack on every tick is far less effective and efficient than just telling them to ignore Shield Orbs and letting them pick between KJ and each Sinister Reflection. Another example: I have another exclusion on KJ so that dps doesn’t attack Sinister Reflections unless a tank has aggro. If I used just a multiplier or action to implement such a block, it would result in dps rapidly swapping targets if their standard logic would want them to attack Sinister Reflections (they would attempt to attack the Sinister Reflection, then either be blocked (multiplier) or forced back to another target (action), and there would just be an ongoing fight between the raid implementation and standard strategy). But this way, dps simply does their own thing until a tank gets aggro, which is crucial because the Sinister Reflection mechanic is that they do not aggro immediately unless attacked first, and they will kill non-tanks almost immediately if aggroed onto them. Conditions can basically be whatever you’d use for strategies anyway—presence of particular mob, role of bot, position of bot or mob, aura present on bot or mob, casting status, casting target, victim identity, distance comparisons, blah blah blah.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. I think this is already pretty much covered by the description above and "Impact Assessment" below, but LMK if anything else is needed.  Right now, just play with this merged and make sure there isn't some terrible performance impact.  - 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**) When no strategy with target exclusions is active (i.e., right now), there is no performance impact. During Engine::Init(), the presence of a boolean flag is checked by scanning loaded strategies to see if any of them use target exclusions. Any strategy that doesn't call HasTargetExclusions gets ignored. This doesn't happen per-tick. When a strategy with exclusions is active, there is a performance impact, but I think it is minimal. GatherStrategyTargetExclusions iterates each bot's combat strategies and calls AppendTargetExclusions on each. If there is no exclusion, the cost is just iterating the strategies. The real cost comes with implementing exclusions and the conditions on which the exclusion kicks in (but that's basically the same consideration as everything else with respect to dungeon/raid strategies). - 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**) I wouldn’t say so. There’s not much code added here, and it has no impact on anybody who isn’t seeking to utilize it for a specific purpose.  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  I had GPT-5.4 assist with analyzing the best sites in the target valuation paths to hook into and help with the overall implementation.  - - [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).

## Pull Request Description  Three functions, IsAssistTankOfIndex, GetGroupMainTank, and GetGroupAssistTank, check IsMainTank for every group member when iterating, thus creating a second layer of looping. This is bad for performance and is easily fixed by a per-call cache to get the main tank before iterating. I'm sure there are better ways of doing it, but this one is simple for a plebe like me to do and should be enough to improve the situation. ## Feature Evaluation   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. I added a new helper, GetMainTankGuid, which is now used in the boolean tank role checks in PlayerbotAI.cpp and tank role getters in RaidBossHelpers.cpp. The ignoreMemberFlag parameter was removed from IsMainTank. This is because I couldn't think of a simple way to keep it in a fashion that makes sense. Previously, IsMainTank would influence determination of assist tanks too, but now it doesn't, and so keeping the parameter there potentially creates an inconsistency between who the main tank is considered to be for purposes of being the main tank vs. purposes of being an assist tank. Moving the parameter to the new helper preserves the old pattern, but since nobody is actually going to directly call that helper, it's useless to exist there. Ultimately, the parameter has not been used a single time, and it's hard for me to imagine why anybody would want to use it, so it's safe to remove and it doesn't seem like anybody would be bothered by it. I tested ingame by temporarily adding an IsAssistTankOfIndex call at the beginning of all 61 Black Temple triggers and sitting in the instance with 24 bots in a raid, though there were only 3 tanks so practically there were only 3 callers of relevance. Over 60s, pmon showed a reduction of 0.125s on triggers after the change (1.868s reduced to 1.743s). ## How to Test the Changes  1. Run instances with strategies that rely on designated main tanks and assist tanks and confirm the strategies still work. 2. Check pmon before/after changes in the PR to evaluate performance differences. ## 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**)  I used DeepSeek v4 Pro, but it's terrible and might actually have caused me to spend more time on this than I otherwise would have. I ended up practically doing this all myself so please check carefully.  ## 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) (mod-playerbots#2510) ## Pull Request Description Two unrelated deadlocks in the shared loot pipeline. In both, a bot stops doing anything until something higher up resets it, and both hit any bot that loots or gathers. I ran into them while testing gathering, but neither is specific to it. **1. Gathering a node that also drops a needed quest item.** `LootObject::Refresh` bailed the moment it found a quest item the bot needs, before it read the gameobject's lock. So for a skill-locked node that also carries such an item (Barrens herbs drop a Root Sample for the *Root Samples* quest), `skillId` stayed `SKILL_NONE`. `OpenLootAction` then treated it as nothing it could gather and never cast the gather spell, so the bot just stood on the herb. It now finishes reading the lock and sets `skillId`. Gathering the node hands over both the herb and the quest item, so nothing is lost; a node is still skipped when its whole loot table is quest items the bot doesn't need. **2. A stale loot target stops the bot looting.** Once a target is picked, anything that makes it unreachable before the bot loots it (pulled into combat on the way, or the target despawns) leaves it set but no longer loot-possible. With that target out of range and other loot around, `LootAvailableTrigger` returned false, which gated off the one thing that would have replaced it. The bot kept the dead target and never looted again. The trigger now reports active in that case so the loot action can drop it. ## Feature Evaluation - **Minimum logic.** Fix 1: when the needed quest item is found, set the guid but keep going to the lock read every other node already does (one extra bool). Fix 2: when out of range with other loot around, also report active if the current target isn't loot-possible (one `IsLootPossible` call). - **Processing cost.** The only added work is that one `IsLootPossible` call, and only when loot is available, the target is out of range, and other targets exist. Every other path is unchanged, and the no-loot path now returns before it computes distance. Fix 1 adds nothing per tick. ## How to Test the Changes 1. Put a bot with Herbalism or Mining in a zone whose nodes drop a quest item, with that quest active (the Barrens, *Root Samples*). Before: it stands on the herb forever. After: it gathers it and receives the quest item. 2. Get a bot to pick a loot target and then lose access to it before looting, e.g. pull it into combat while it runs toward a corpse. Before: it keeps the dead target and stops looting. After: it drops the target and carries on. ## Impact Assessment - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] Minimal impact (**explain below**) The one added `IsLootPossible` call fires only in the out-of-range-with-other-loot case. Nothing else changes per tick. - Does this change modify default bot behavior? - - [x] Yes (**explain why**) Bots that used to freeze (on a quest-item gather node, or on a stale loot target) now keep going. Bots that weren't stuck behave as before. - Does this change add new decision branches or increase maintenance complexity? - - [x] Yes (**explain below**) One small branch each: a `neededQuestItem` flag in `Refresh`, and a stale-target check in the trigger. Both have an inline comment. ## AI Assistance Was AI assistance used while working on this change? - - [x] Yes (**explain below**) Used to help diagnose the two deadlocks and draft the changes. I reviewed all of it and understand it. ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [ ] Any new bot dialogue lines are translated.  - - [x] Documentation updated if needed (Conf comments, WiKi commands).  ## Notes for Reviewers

Implements bot behavior for _Razorgore the Untamed_ and _Vaelastrasz the Corrupt_ in Blackwing Lair. **Razorgore**: - General: - Fire resistance aura: Reduces damage from [Fireball Volley](https://www.wowhead.com/classic/spell=22425/fireball-volley) and [Conflagration](https://www.wowhead.com/classic/spell=16805/conflagration). - Phase 1: Eggs - One tank bot marks Razorgore with the moon rti and tanks him whenever he is not mind-controlled. => All other bots ignore the boss (He wipes the raid if he dies before all eggs are destroyed!) - Mind-controlling the boss and destroying the eggs must be done by the real player. - Phase 2: Razorgore - The moon rti is removed => Bots engage the boss - All bots except the current tank dodge the frontal cone AoE ([Cleave](https://www.wowhead.com/classic/spell=19632/cleave)) => move behind the boss - Additionally, ranged bots avoid [War Stomp](https://www.wowhead.com/classic/spell=24375/war-stomp) by moving away - Tanks not currently tanking the boss suppress TankFaceAction to avoid cleave damage **Vaelastrasz**: - General: - Fire resistance aura: Reduces damage from [Fire Nova](https://www.wowhead.com/classic/spell=23462/fire-nova) and [Flame Breath](https://www.wowhead.com/classic/spell=23461/flame-breath). - All bots except the current tank position themselves on the rear flank to avoid damage from _Flame Breath_, [Cleave](https://www.wowhead.com/classic/spell=19983/cleave), and [Tail Sweep](https://www.wowhead.com/classic/spell=15847/tail-sweep) - Tanks not currently tanking the boss suppress TankFaceAction to avoid AoE damage - ~~Because the boss starts at 30% hp, warlocks suppress Drain Soul until 3% HP (negligible damage before that)~~ - Handling of [Burning Adrenaline](https://www.wowhead.com/classic/spell=18173/burning-adrenaline): - The current tank stays in place. The rear flank positioning ensures that other bots won't get hit by the explosion. - Other bots will move away from raid members. - Bots will prefer a position within LOS. - Ranged bots will try to find a spot where they can still reach the boss with their attacks. - If a bot gets pushed back by Tail Sweep, they will try to reach the boss without coming near other raid members. - If the boss is dead, bots with Burning Adrenaline will still try to avoid other raid members. - Movement direction is calculated using weighted repulsion. **Miscellaneous**: - _BwlTurnOffSuppressionDeviceAction_ restricted to Rogues (or raid cheat) - New helpers _IsNonBABotNearPosition_, _ClearTargetIcon_ - Multiplier infrastructure enabled (was commented out)   - Describe the **minimum logic** required to achieve the intended behavior. - Razorgore: check if eggs are alive (scans nearest game objects), boss position + frontal cone check for AoE avoidance, moon marker assignment by the off-tank - Vaelastrasz: group position comparison for weighted repulsion, aura check for Burning Adrenaline, tank comparison for flank positioning - Describe the **processing cost** when this logic executes across many bots. - _AreRazorgoreEggsAlive()_: Scans all nearest game objects. Expensive, but only called by the Razorgore tank action and multiplier - Frontal cone check (_HasInArc_): inexpensive geometric calculations - Group iteration in _BwlVaelastraszMoveAwayAction_: O(n) over raid members, only active during Vaelastrasz encounter or while _Burning Adrenaline_ aura is active - All triggers/multipliers are encounter-bound, so they should never fire outside the instance  1. Enter BWL with enough bots with the appropriate level. 2. Engage Razorgore in the first room: The player must mind control the boss and destroy the eggs Expected behavior: - A paladin bot should enable their fire resistance aura. - The off-tank should immediately mark and tank Razorgore until he gets mind controlled - Bots should handle all enemy NPCs - When all eggs are destroyed, the rti mark should be removed and all bots should engage the boss. - Bots should position themselves to avoid AOE damage. 3. Engage Vaelastrasz in the next room: Talk to him and wait for the RP to finish. Expected behavior: - A paladin bot should enable their fire resistance aura. - A tank should gain threat. Every other bot will position itself at the rear flank. - If the current tank gets Burning Adrenaline, the bot will not run away. - Every other bot with Burning Adrenaline will try to find a safe spot to explode. - ~~Warlocks should not Drain Soul before 3%~~ - If the boss is dead and a bot still has Burning Adrenaline, it will still try to avoid other raid members. 4. Reach the suppression room. If cheats are enabled, all bots should be able to deactivate the suppression devices. Otherwise only rogues will do that.  - 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**) Encounter-bound triggers/actions, only active in BWL instance - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) New boss behavior for Razorgore & Vaelastrasz (BWL-specific) - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Self-contained within BWL modules (triggers/actions/multipliers), no changes to global systems  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  **brainstorming and code generation** The code in this PR is mostly written by me. Originally, when bots got Burning Adrenaline from Vaelastrasz, they went to one of 12 hard-coded positions inside Vaelastrasz' room. But I didn't like that approach, so I asked Big Pickle from OpenCode for some advice and it generated the initial version of the current weighted repulsion approach. The following finalization of this code was done by me again. **review** I used Big Pickle during development for code reviews. Reasonable suggestions were reviewed and applied by me. Also the first iteration of the text of this PR was generated by AI.  Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) below**)   - - [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] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [x] New source files use the GPLv2 header. - - [x] Documentation updated if needed (Conf comments, WiKi commands).  I know that this PR only contains the first two bosses but I wanted to take a break from playing AzerothCore, so I decided to submit and merge my current progress.

Moved code duplicates to shared file Optimized code Fixed bots not removing RS strategy when leaving raid   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.   - 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**)  Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**)   Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) below**)   - - [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] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [x] New source files use the GPLv2 header. - - [x] Documentation updated if needed (Conf comments, WiKi commands).

## Pull Request Description  This change expands (and fixes) the current implementation of showing/hiding helmets and cloaks on randombots based on the conf option. Previously, if the option was turned on to show helms/cloaks, it would still roll urand and have a 20% chance to hide helm/cloak. Since this happens every randomization and the flag never gets removed, it would mean that after enough randomizations, all bots would have helm/cloak hidden even though config option is enabled to show them. I've changed the config to now have these options: 0: helm/cloak is never shown 1: helm/cloak is always shown 2: helm/cloak visibility will be random The settings for helmet and cloak are still separate from each other, I'm just writing "helm/cloak" to save time. Now, when a bot is randomized or re-randomized, it will check the config value, and apply/remove the show helm/cloak flags based on the conf option. ## Feature Evaluation   - 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  1. disable the option, randomize bots a bunch of times. Helm/cloaks should never display on bots. 2. set the option to 1, randomize bots a bunch of times. Helms/cloaks should always display on bots. 3. set the option to 2, randomize bots. bots should have helms/cloaks 80% of the time. Randomize multiple times to confirm if a bot changes their visibility state. ## 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**) Hopefully it is cleaner and easier to understand than it was before ## AI Assistance  Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**)  ## Code Provenance / Attribution  Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) below**)   ## 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. - - [ ] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [ ] New source files use the GPLv2 header. - - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers  I've kept with the seemingly original design intent of having the bots hide their helm/cloak 20% of the time if the option is on randomize. If a different % is desired, I can update the urand. Let me know! --------- Co-authored-by: wetbrownsauce <you@example.com>

I hated this strategy, and when I tried Magtheridon the other day, it didn't even work, so I decided it was time to just rewrite it. Notable changes with respect to functionality include: - The main tank's waiting position and actual tanking position have been changed so now the tank should wait between the boss and the group when the Channeler phase ends, and then the move to the final tank position should leave the tank in range of healers easily. - Ranged positioning logic was significantly simplified, with a priority of staying away from the boss and then a minor spread, instead of the overly complicated ranged/healer locations that the prior strategy attempted. - Various silly behaviors have been solved through multipliers (e.g., main tank charging and taunting on the way to the waiting position, tank running back and forth to avoid Conflagration while tanking). - Debris avoidance actually works now. - Blast Nova timer no longer becomes desync'd by a failed or late interrupt, and Quake and ceiling collapse delays are accounted for.   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. The main changes with respect to the code are: - Using spell hooks for Debris and Quake. Debris is cast by a trigger NPC, but the triggers pat and what remains is a dynamic object. When the ceiling actually falls 5s later, it is a one-shot. So this is crucial to avoid and cannot be detected without a spell hook. Quake is an instant cast by Magtheridon with no associated NPC or object and thus cannot be detected without a spell hook. Whenever it is cast, it pushes the next Blast Nova out by 7 seconds, so bots need to read it to determine timing for cube clicking. - Calling RequestSpellInterrupt() to move out of Debris. - Having dedicated, standalone functions for assigning and replacing cube clicker bots instead of the prior version of those processes being scattered haphazardly through actions and triggers. A couple of maps were added, and a couple were removed. I tried to scope locally where possible, but the remaining maps need to be shared, either across actions and/or bots (for example, the MechanicTracker manages the Blast Nova timer, and that needs to be shared in case the MechanicTracker dies and is reassigned).  Fight Magtheridon. Try killing off cube clickers to make sure replacement assignments are made and timers are not desynced.  - 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 - - [ ] Yes (**explain why**) Only with the “magtheridon” strategy active. - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Used for Debris spell hook and cube clicker assignment logic  Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) below**)   - - [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] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [x] New source files use the GPLv2 header. - - [x] Documentation updated if needed (Conf comments, WiKi commands).  There is a super weird bug with Magtheridon that seems inexplicable based on his boss script. After about 20% HP, instead of casting Blast Nova every ~54s or so, he starts casting it with a repeating ~42s/~21s pattern, and without delays for Quake. This screws up the ability to stop Blast Nova, and actually makes it impossible with a single cube-clicker group for the 21s cast because the Mind Exhaustion debuff has not expired yet. There are ways I could try to work around this, but this is a clear bug and I don't have the patience to try to adapt something for this purpose. The fight is beatable anyway.

…od-playerbots#2541) Maintenance PR Test: <img width="790" height="679" alt="obraz" src="https://github.com/user-attachments/assets/cf475221-2406-4353-ace4-c733c1eb464a" />

… some confusing local variables (mod-playerbots#2526)   1. IsAlt is standardized into the convention of having "Bot" added to it like IsRandomBot and IsAddClassBot. 2. One local definition of IsRandomBot was dropped. That local variable should techically be named isRandomBot, but the whole usage here is confusing. Used inline directly. It's better and cleaner given the usage here. 3. One local definition of isSelfBot was dropped. Globally IsRealPlayer is used to refer to self-bots, so for now lets follow that convention. In the future I would like to globally define IsSelfBot for self-bots, and IsRealPlayer would then be defined as a real player under the players control (no botAI).   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.  Check that everything compiles correctly. If it fails, it must be that you have another module that calls IsAlt and requires the term over there to be updated.  - 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**)  Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**)   Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) below**)   - - [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] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [x] New source files use the GPLv2 header. - - [x] Documentation updated if needed (Conf comments, WiKi commands).  If you know of a module that calls onto Playerbots' `IsAlt`, please share it.

…layerbots#2533)  ## Pull Request Description  AiPlayerbot.FreeMethodLoot is used to determine whether bots will loot when the loot method is set to FFA (default disabled). This PR makes it so that even if AiPlayerbot.FreeMethodLoot is disabled, selfbots will loot on FFA. However, selfboot looting on FFA can still be disabled by removing the "loot" strategy from the selfbot (nc -loot). ## Feature Evaluation   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Add check for selfbot, ```PlayerbotAI::IsRealPlayer()```, in ```LootAction::isUseful()```. ## How to Test the Changes  Make sure AiPlayerbot.FreeMethodLoot is _disabled_ in the config. Make a group with loot method on FFA. Selfbot, kill some mobs, confirm selfbot loots and other bots do not loot. Remove the loot strategy from the selfbot, confirm selfbot no longer loots. ## 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**) Any additional check is a non-zero performance impact, but the selfbot check will run only for a bot in a group with FFA active. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Making this behavior not default would require selfbots not to be given the loot strategy by default, which would impact groups with other loot methods and would be a novel approach in the codebase. I think most people would want selfbots to loot in FFA (certainly anybody on a solo server) so the default for them to loot makes sense. - 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**)  ## Code Provenance / Attribution  Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) 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] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [x] New source files use the GPLv2 header. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers

…2561)   - Added new license to all files for raids I worked on that were missing a license - Reformatted private members in actioncontext and triggercontext files to make them fit actual C++ convention   - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots.   - 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**)  Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**)  Nobody got time to do this kind of stuff manually. I did read it, lols.  Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)? - - [x] No, all code in this PR is original - - [ ] Yes (**name the project and the original author(s) below**)   - - [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] Any code ported/adapted from another project is attributed (project + author(s), `Co-authored-by:` trailer + in-file note). - - [x] New source files use the GPLv2 header. - - [x] Documentation updated if needed (Conf comments, WiKi commands). - - [x] New and modified files do not introduce new compiler warnings.

brighton-chi and others added 30 commits June 22, 2026 16:36

fix: Resolved all issues from cherry-picking.

0603677

fix: Resolved remaining syntax issues.

fd7b6da

chore: Adapted changes made by commit dbea120 manually due to entire …

a19c555

…conflict.

chore: Resolved a few errors.

9d85831

ThePenguinMan96 and others added 28 commits July 14, 2026 11:36

[CI/CD] Changed way to get git diff to mark label with translation (m…

d0225c1

…od-playerbots#2541) Maintenance PR Test: <img width="790" height="679" alt="obraz" src="https://github.com/user-attachments/assets/cf475221-2406-4353-ace4-c733c1eb464a" />

SmashingQuasar merged commit 439cd68 into main Jul 23, 2026
1 check failed

SmashingQuasar deleted the dev/SmashingQuasar/cherry-pick-2026-06-22 branch July 23, 2026 15:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Code reconciliation - #117

Code reconciliation#117
SmashingQuasar merged 93 commits into
mainfrom
dev/SmashingQuasar/cherry-pick-2026-06-22

SmashingQuasar commented Jul 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

18 participants

Uh oh!

Conversation

SmashingQuasar commented Jul 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

18 participants