3 Commits

Author	SHA1	Message	Date
Crow	80860d72a3	Some simple improvements to Karazhan strategies (#2173) ... # Pull Request I've made a few simple changes to the Karazhan strategies that should result in notable improvements in game. - **Attumen**: I was using a GetExactDist2d() check for phase 2 when bots stack behind him. That resulted in ranged bots being too close to attack. It's now switched to the correct GetDistance2d() check to account for the hitbox. - **Maiden of Virtue**: The tank continuously ran side-to-side when trying to tank her because it was trying to turn the boss with TankFaceAction but not being able to due to being required to be within a short distance of a set waypoint. I didn't understand the cause when I was originally working on Karazhan. To fix this, a new multiplier disables CombatFormationMoveAction (the "co+ disperse" strategy) and its inherited classes, except for SetBehindTargetAction. The only other class that inherits from CombatFormationMoveAction is TankFaceAction. I disabled the parent class also because the ranged bots have a coded positioning strategy and should not observe the co+ disperse strategy. - **The Curator**: Same deal as Maiden with a new multiplier. - **Nightbane**: Same deal as Maiden with a new multiplier. - **Malchezaar**: Infernal avoidance for non-enfeebled bots had movement priority set to MOVEMENT_FORCED. This was not good because it made bots refuse to cross Hellfire so if you got unlucky, they could be stuck on the other side of an Infernal from the boss and completely out of the fight. MOVEMENT_FORCED needs to be reserved for situations in which the bot absolutely cannot step in the AoE at all, and that's not the case for non-Enfeebled bots here. Priority is now changed to MOVEMENT_COMBAT. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? No additional complication in logic from these changes, and additional performance impact is exceedingly small (just a few more multipliers with inexpensive checks that would apply only in Karazhan). --- ## How to Test the Changes - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it Should be straightforward. Engage the above-mentioned bosses in Karazhan and observe the mechanics. I did test all of them. ## Complexity & Impact Does this change add new decision branches? - - [X] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [ ] No - - [X] Yes (**describe and justify impact**) Barely due to the additional multipliers. Could this logic scale poorly under load? - - [X] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [X] No - - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - - [X] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [X] No - - [ ] Yes (**explain below**) --- ## Final Checklist - - [X] Stability is not compromised - - [X] Performance impact is understood, tested, and acceptable - - [X] Added logic complexity is justified and explained - - [X] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com>	2026-03-06 07:58:02 -08:00
Crow	b31bda85ee	Refactor raid strategy framework (#2069) ... # Pull Request The purposes of this PR are to (1) establish a general raid helper framework for the benefit of future raid strategies and (2) make some improvements to problematic areas of the raid strategy code. List of changes: 1. Added new RaidBossHelpers.cpp and RaidBossHelpers.h files in the Raid folder. 3. Moved reused helpers from Karazhan, Gruul, and Magtheridon strategies to the new helper files. 4. Modified the prior function that assigned a DPS bot to store and erase timers and trackers in associative containers--the function now includes parameters for mapId (so a bot that is not in the instance will not be assigned) and for the ability to exclude a bot (useful for excluding particular important roles, such as a Warlock tank, so they are not bogged down by these extra tasks at critical moments). I also renamed it from IsInstanceTimerManager to IsMechanicTrackerBot. 5. Moved all helper files in raid strategies to Util folders (was needed for ICC, MC, and Ulduar). 6. Renamed and reordered includes of Ulduar files in AiObjectContext.cpp to match other raid strategies. a. This initially caused compile errors which made me realize that the existing code had several problems with missing includes and was compiling only due to the prior ordering in AiObjectContext.cpp. Therefore, I added the missing includes to Molten Core, Ulduar, and Vault of Archavon strategies. b. Ulduar and Old Kingdom were also using the same constant name for a spell--the reordering caused a compile error here as well, which just highlighted an existing problem that was being hidden. I renamed the constant for Ulduar to fix this, but I think the better approach going forward would be to use a namespace or enum class. But that is for another time and probably another person. 7. Several changes with respect to Ulduar files: a. The position constants and enums for spells and NPCs and such were in the trigger header file. I did not think that made sense so moved them to existing helper files. b. Since the strategy does not use multipliers, I removed all files and references to multipliers in it. c. I removed some unneeded includes. I did not do a detailed review to determine what else could be removed--I just took some out that I could tell right away were not needed. d. I renamed the ingame strategy name from "uld" to "ulduar," which I think is clearer and is still plenty short. 8. Partial refactor of Gruul and Magtheridon strategies: a. I did not due a full refactoring but made some quick changes to things I did previously that were rather stupid like repeating calculations, having useless logic like pointless IsAlive() checks for creatures already on the hostile references list, and not using the existing Position class for coordinates. b. There were a few substantive changes, such as allowing players to pick Maulgar mage and moonkin tanks with the assistant flag, but a greater refactoring of the strategies themselves is beyond this PR. c. I was clearing some containers used for Gruul and Magtheridon strategies; the methods are now fixed to erase only the applicable keys so that in the unlikely event that one server has multiple groups running Gruul or Magtheridon at the same time, there won't be timer or position tracker conflicts. ## How to Test the Changes 1. Enter any raid instance that has any code impacted by this PR 2. Engage bosses and observe if any strategies are now broken I personally tested Maulgar, Gruul, and Magtheridon and confirmed that they still work as intended. ## Complexity & Impact I do not expect this PR to have any relevant changes to in-game performance, but I will defer to those more knowledgeable than I if there are concerns in this area. As I've mentioned before, you can consider me to be like a person who has taken half an intro C++ course at best. ## AI Assistance None beyond autocomplete of repetitive changes. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>	2026-02-06 11:55:43 -08:00
bashermens	41c53365ae	[HOT FIX] MS build issues regarding folder / command lenght usage or rc.exe (#2038)	2026-01-19 22:45:28 +01:00