157 Commits

Author	SHA1	Message	Date
bash	6aea0c2ba7	feat(Core/Travel): Add transportTeleportType config + teleport-across-water branch in UpcommingSpecialMovement	2026-05-31 15:17:20 +02:00
bash	7278a3bfcb	refactor(Conf): Hardcode master-walk-pace distance to 5y, drop config	2026-05-30 20:29:01 +02:00
bash	1d0aeec7b9	feat(Core/Travel): Align MoveFarTo and probe pipeline with cmangos	2026-05-30 13:53:16 +02:00
bash	3269d1a4b3	feat(Core/RPG): MoveFarTo flow, quest-pursuit at POI, MoveRandomNear retries	2026-05-30 13:53:16 +02:00
Crow	9bba4b78dd	Overhaul party buff/greater blessing system (#2358) ... ## Pull Request Description These changes I originally made for myself because as a person who really likes to raid with bots, I felt like the current group buff system is fundamentally broken, and I needed something more consistent and optimal. I debated a lot whether to PR this because it's such an extensive overhaul that was almost entirely reliant on AI, and I know that wishmaster still has a PR open regarding the greater blessings. I decided to after a couple of conversations so at least people can look at it and see if it's something that they want. The tl;dr version is that this PR overhauls buff handling in two related areas: 1. It adds a dedicated greater blessing assignment system. 2. It generalizes party/raid reagent-buff handling for Paladins, Druids, Mages, and Priests. Under this PR, greater blessings are determined by assignments for the current group, and those assignments are determined based on: 1. a hardcoded priority list of blessings for each spec; 2. the number of Paladins in the group; and 3. whether any Paladins have talents for Blessing of Sanctuary, Improved Blessing of Might, or Improved Blessing of Wisdom. Assignment determinations are cached in a value to avoid constant reevaluation. The exact priority list is: - All casters: Kings, Wisdom, Sanctuary, Might - Physical-only DPS (Rogues, Warriors, DKs): Might, Kings, Sanctuary, N/A - Hybrid DPS (Enh, Ret, Hunters, Cats): Might, Kings, Wisdom, Sanctuary - Druid tanks: Kings, Might, Sanctuary, Wisdom - Warrior and DK tanks: Kings, Might, Sanctuary, N/A - Paladin tank: Sanctuary, Might, Wisdom, Kings Note that Sanctuary is preferred over Kings for Paladin tanks because of the mana regen component but deprioritized for other tanks because Kings provides Agility. The extra 3% damage reduction from Sanctuary does not stack with Disc Priests’ Renewed Hope, which will have 100% uptime. For group buffs, logic is centralized so that class triggers use the same gating and upgrade rules for Gift of the Wild, Arcane Brilliance, Prayer of Fortitude, Prayer of Spirit, and Prayer of Shadow Protection. Also, Shadow Protection is now a default strategy for Priests (rshadow, which existed before but wasn’t added by default). I’ve added a config setting for the greater blessing system and adjusted the current config setting for group buffs. In each case, you can pick whether to disable the feature entirely, use it in all groups, or use it only in raid groups. The default is raid only for greater blessings and all groups for group buffs. Note that for group buffs, even if the config is enabled, they will be used only if at least 3 group/raid members on the same map are missing the buff family. This is mainly to stop group buff spamming during wipe recovery as bots are revived one-by-one. I renamed the Paladin buff strategies to align them with the actual blessing names: - `bhealth` -> `bsanc` - `bmana` -> `bwisdom` - `bdps` -> `bmight` - `bstats` -> `bkings` This is an intentional breaking change for saved strategy strings. Bots will need a one-time strategy reset after update. I removed bots telling you when they are out of reagents for greater blessings. If people like that though, I can add it back. A small cleanup is also included in TankPaladinStrategy: Holy Shield was subject to three overlapping health triggers with the same priority; I removed the two lower health thresholds which have no purpose. ## Feature Evaluation - Describe the **minimum logic** required to achieve the intended behavior. I’m going to let the AI answer this one. > The minimum logic is: > - a shared config-gated check for whether group/raid buff variants are allowed > - a shared way to treat single and group variants as equivalent aura families > - a shared upgrade path from single-target buff to group buff when the group variant is appropriate > - a Paladin-only cached assignment model that decides which blessing family each Paladin should cover for the current group > - trigger/action wiring that only attempts casts when a group member is actually missing the assigned buff > > This avoids scattering separate per-class heuristics across many triggers and actions. - Describe the **processing cost** when this logic executes across many bots. Processing cost should be minimal but non-zero. The general party buff changes are limited to existing buff trigger paths and mostly replace duplicated checks with shared helpers. They do not add expensive default per-tick behavior outside those existing trigger evaluations. The Paladin greater blessing logic does add extra decision-making, but it is limited to Paladins, gated by config and group eligibility, subject to a delayed trigger evaluation of only once per 4s, and cached per group assignment set instead of recomputing the full assignment model on every action attempt. This PR also increases the throttle duration for group buff triggers to limit performance impact; I’m open to adjustments to these durations: - Mark of the Wild triggers were increased from 4s to 8s - Arcane Intellect triggers were increased from 4s to 8s - Priest buff triggers were increased to 8s (previously, Fortitude was 6s, Spirit was 4s, and Shadow Protection had no throttle) - There is now a 5s delay on buffing (greater blessings and group buffs) after bots log in—I was getting bots spamming buffs as soon as they logged in even when it was not necessary I’ve tested with pmon, and the impact is minimal—these are very cheap triggers even compared to standard bot rotational ability triggers. ## How to Test the Changes 1. Try different config settings to confirm that they work to enable/disable greater blessings/group buffs in the configured scenarios 2. For greater blessing changes: - test with one Paladin in a party/raid - test with multiple Paladins in a party/raid - confirm the Paladins divide blessing coverage instead of repeatedly overwriting each other - include at least one Paladin with Improved Blessing of Might and make sure it casts Might over Paladins without the talent; check the same with a Paladin with Improved Blessing of Wisdom - do not include a Paladin that knows Sanctuary, confirm any Paladin tank receives Kings instead (you’ll need a low-level Paladin for this since Sanctuary is a prot talent) - confirm bots cast blessings only when a member is actually missing the relevant blessing family - confirm there is a 5s delay on buffing when bots log in 3. For group buff changes: - confirm there is a 5s delay on buffing when bots log in - confirm that single buffs are used when there aren’t at least three unbuffed members in the same map, even if group buffs are enabled in the config 4. For all buffs, test with reagents missing to confirm fallback to single-target buffs and single blessings 5. Confirm the Paladin buff strategy names are changed after resetting AI ## Impact Assessment - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [x] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) Discussed above in processing costs. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Yes—that is the purpose of this PR, to change default buffing behavior. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Yes, but I think it’s inevitable to add complexity to get greater blessings to function consistently, given the challenges brought by their mechanic of applying across each class. ## AI Assistance Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) I used GPT-5.4 extensively for this overhaul. It’s much more complicated than I could handle on my own. I’ve done a lot of testing and have reviewed the code and provided plenty of revisions, but I cannot say I can perfectly explain each addition and how it works, not even close. ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com>	2026-05-29 23:08:21 -07:00
Mat	c7b4b9aa80	ICC V2, Autogear BiS cmd (#2363) ... ## Pull Request Description <!-- Describe what this change does and why it is needed --> Big thanks to @kadeshar for providing the bis list for many raids and ilvls :D Video demo for ICC 25HC: https://studio.youtube.com/video/nACyjn817iQ/edit Video demo for autogear bis chat command: https://www.youtube.com/watch?v=2YqyVBaSb2g split main IccActions.cpp into sperate per boss .cpp files changed style to be more aligned with https://www.azerothcore.org/wiki/cpp-code-standards (WIP) added bisicc chat command for bots to gear with ICC bis gear if autogear and bisicc is enabled in cfg https://gist.github.com/metal0/0bb094bf65d27e17044308ad0646cae1 bis list used LM Added multiple spike marking and focus for faster spike clearing, each spike will get its own kill group, tank spike will never get melee bots (only assist tank and ranged dps) Added coldflame detection so that melee bots dont go for spikes that are in flames During bonestorm assist tank will go far away spot so that once bonestorm is fixed, LM will bounce back and forth from MT to AT (atm it targets randomly, it should always pick furthest target) Coldflame avoidance is handled by avoid AOE, important to keep it on in cfg Tested on ALL diffs LDW Improved skull marking of adds, add handling by tanks and dps Changed 1st position for ranged bots for easier adds handling in HC and NM Improved tanking logic for tanks, assist tank will focus on collecting adds and bring them near boss Real players will also get cyclone aura when mind controlled Improved ranged position during 2nd phase, they should not get stuck in corners/walls anymore Tanks will remove LDW ToI aura in HC (really hard to tank with it since many things are happening at once) Added Cheat for LDW fight to help tanks with agro in 2nd phase of heroic modes Changed tank position in phase 2 closer to pillars opposed to stairs (bots love to fall thru floor and run thru walls if near them) this fixed the issue Fixed edge case for escaping from shades, it could happen that multiple shades would target bot, and it was running from 1st one he found, now it will run form all that are targeting it Hunters will cast viper sting now, to increase shield draining speed Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) In short cleared LDW without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. GS Changed triggers and actions to enable cross faction play Assist tank will now actually tank adds on friendly ship Dps will properly jump to attack mage and go back to their ship, if stuck on enemy ship /p reset, /p summon or /p follow fixed trigger for cannons, if cannons are frozen bots wont try to mount them anymore which prevented them from attacking mage properly bots will use rocket packs to jump to and from enemy ship instead of teleporting Main tank will now jump 1st. tank enemy boss and wait until all bots have jumped back before he jumps back All bots will wait for main tank to engage enemy captain before jumping to enemy ship Cannons will focus rockets 1st, then other adds now (for when gs gets scripted) Rdps will focus nearby adds on enemy ship and mark with star rti icon when there is no deep freeze todo: remove tanking bypass when core fixes enemy ship boss threat reseting Tested crossfaction on horde with single ally bot, ally bot did everything right, need to test more. note horde side is heavily bugged due to threat issue of adds, tanks cant take threat, on ally its somewhat ok, on horde rip. Horde is doable, but annoying cus of threat issue. Tested on ALL diffs DBS Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get rune of blood Tanks will tank adds better now, no loose adds anymore Tested on ALL diffs Dogs Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get 8 mortal wounds stacks Tanks will tank adds better now, no loose adds anymore Tested on ALL diffs Festergut Hunters sometimes populated row 0 which would make them in melee range of the boss (bad for dps). They should pick correct rows now Healers will populate row 0 1st then other rows for optimal healing position Ranged bots should properly choose unique spots to avoid stacking when there is no spore present Remade tank taunt logic, tanks should now properly taunt boss and let other tank taunt it if they get 6 gastric bloat stacks Changed ranged spore position closer to boss Spore bots should be able to attack/do non movement action when they have spore and are in position Solved malleable goo detection via direct boss hooks to detect boss targets! Tested on ALL diffs Rotface Tanks should not fight over big ooze anymore Improved big ooze kiting Improved small ooze stacking logic (when no big ooze present, stack at small ooze position, when big ooze is present move to it) Fixed edge cases when main and assist tank get small ooze (they used to move to big ooze, that was really bad since main tank would start to tank big ooze and get hit by big ooze, assist tank would stop kiting and get hit by big ooze) stopped mutated plague from dispelling instantly (as fight goes on, rotface cast mutated plague more and more, thus making it impossible to pass due to sheer numbers of small oozes and big oozes on the map, this will delay their spawning and give enough time for bots to handle them properly) Fixed edge case of multiple small oozes and big oozes being alive at same time (bots would detect wrong oozes and wipe raid or get stuck) Improved flood avoidance Improved ranged positioning in heroic mode, instead of letting them choose positions (which is a nightmare on dynamic fight as rotface, they now will choose 1 spot of 22 premade ones and populate them based on guid and adopt spot based on flood position) Improved Explosion avoidance by making bots remember their starting position so that they can return to it after big ooze explode, their movement is not chaotic anymore, and improved timers, they will wait 2 sec at new position before returning to starting position so that they can avoid explosion projectiles properly, they should also avoid moving to other bots starting positions. These changes ensure minimal movements so that bot can do maximum dps possible. Tested on ALL diffs PP Fixed many logic conflicts that caused bots to freeze, do bad dps to ooze/clouds Fixed triggers and multipliers Improved Gas Cloud avoidance, bloated bot will now remember its previous position to avoid backtracking/getting stuck in corners Added boss hooks to finally detect malleable goo, it is not an npc, object or creature and PP doesn't target anyone, bots will flee from it now Boss stacking now only in last phase Added cheats for players also (if enabled in cfg) only bots used to get auras Fixed tank switching in last phase, atm PP doesn't apply aura, but it should work, since same logic works for dogs, festergut and dbs Assist tank will now become abo if there is no abo before first puddle appears Abo will during puddles, slow oozes, slash boss & oozes In last phase assist will return to normal Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) Tanks switched in last phase flawlesly and shared stacks as they should (mutated plague got fixed in core) In short cleared PP without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. BPC Added center position to prevent bots from pulling BQL or other adds when they glitch thru walls/floor and thus resetting raid back to icc entrance teleporter Added additional z axis resetting since bots like to "fly" up in the air when attacking kinetic bombs. using cheat bypass for ball of inferno flames (atm bugged, doesn't shrink), bots will simply kill them when they spawn. Improved tanking for main tanks, improved collection of dark nuclei for assist tank Improved kinetics bomb handling Improved shock vortex spreading Improved valaran spreading for ranged Added shock vortex (non empowered) detection to avoid it while moving into safe positions Fixed jittery movement Tested on ALL diffs BQL Removed center position block so that bots can spread our easier in 25 mode, not ideal but makes 25hc easier Replaced repulsion based spreading, now each bot will have its own spot and move if needed to new spot Improved air phase spreading Fixed assist tank taking 1st bite Tested on ALL diffs VDW Due to recent core changes bots got bugged in portals if no real player entered and changed Z axis, if there was no z axis change bots would chill under the cloud on the ground and do nothing. I could not figure out how to fix this (thus breaking immersion) without force teleporting them to the clouds. Bots that go into portals will now teleport at the same time to clouds instead of following leader bot. Added feature that if players enter the portal, player with lowest guid will become bot "leader" and they will follow that player so that there is at least a little bit of immersion left. Fixed cloud collection for Heroic Mode, bots will now time clouds more precisely to avoid loosing stack due to not picking them up Improved RTI marking Improved group splitting Improved zombie kiting and avoiding explosion Tested on ALL diffs Sindragosa Bots will mark tomb positions with red smoke bomb in air phase so that real player know where to go with when beacon on them in last phase they will mark with blue smoke tomb position Fixed tank positioning Fixed wrong tomb choice and positioning Fixed tomb marking In last phase healers will stack with melee to allow boss healing In last phase when waiting for mystic debuff to pass, bots will damage tomb like in air phase to speed up the kill todo: tank switch to reset mystic buffet stacks Tested on ALL diffs Edit 19.5. : Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world cfg ICC buff on max (30%) In short cleared LDW without ICC cheats with bis gear but unoptimized enchants, talents, gems. I still recommend using ICC cheats for better and fun experience. LK Changed add gathering logic for 1st phase and winter phase, instead of tank moving to shamblings, he will keep taunting until they agro him. necrotic plague is easy now, ditched complex timing logic for a simple logic ( move to shambling, wait until dispeled, go back. Healers dont dispel until defile ally is near shambling ) Fixed winter phase gathering logic, assist tank will now properly move to raging spirits asap and bring them to main tank, melee dps will no properly move behind/flank spirits and shamblings to avoid instant death. Rdps will now properly focus frost orbs and adds, Transition should also be smoother now, but still needs /p reset if they get stuck. Other phases are ok, LK fight is now even better than before, but player still need to know tactics and use multibot addon to help out bots when needed, especially during defile phase since its random and position matter for valkyrs and future defiles Non winter phase AT will collect raging spirits and move them to main tank, ranged bots will keep distance, melee bots will flank them to avoid aoe Defile, ditched complex spreading which was mostly gamble with boss hooks to detect defile victim. If bot, bot will move away from raid, if real player main tank will yell Player name move away defile. bots will stay in center now if safe from defile, raging spirits or vile spirits Vile spirits soaking by assist tank. Assist tank will stand between spirits and raid and chase spirits. healers are allowed to move from position to heal assist tank. one hunter if alive will be at center position to place traps to slow down spirits HC Real players will also get buffs if cheats are enabled now Assist tank will now never move towards the raid to gather adds, instead it will taunt them instead so that they come to it Assist tank will rotate shamblings at all times away from raid Assist tank will stun shamblings before transition to avoid shockwave wipe Winter phase ice sphere location changed, ranged will focus sphere faster and better now Fixed jittery movement and low dps during winter phase Fixed most of the bots getting stuck during winter phase Valkyrs will be properly marked now, one by one, in hc bots will now ignore low hp valkyrs and focus on grabbing valkyrs or boss After winter raging spirit will have top priority for killing After winter ranged bots will 1st handle ice spheres then skull targets Spirit bomb avoidance improved, main tank should not back track into unsafe positions anymore Since real player is leader its crucial that player know the tactics, bots can not handle edge cases during the fight alone, they need some of reset, follow, summon here and there since its a long fight and things can go wrong. Tested on ALL diffs NOTE: If server crash, bots will sometimes drop ICC strategy even though they are in ICC, simply re enter or write /p nc +ICC to re enable. NOTE: addons that mark icons during fight could break bots, since icons are used for RTI by bots NOTE: I did not use any raiding addons besides unbot and multibot to control bots NOTE: In theory everything should work wihout ICC buff from world cfg, and ICC cheats from playerbots cfg, didnt test it, didnt try, its too hard core for hc mode to go raw, but it should be possible good luck :) NOTE: For normal about 5k gs should be enough to do most bosses. For HC T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for fun experience. NOTE: As player its good to know every strategy for Bosses, so that you can spot and help out with reset, follow, summon if bots seem stuck or are doing something strange, a lot of stuff is happening on most fights so expect some intervention with reset, summon, follow. 10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for bress (its not set in stone, but most success with this setup) 25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for bress (its not set in stone, but most success with this setup) GL & HF, happy raiding :D Closes #1421 #2120 Fixes #1219 NOTE: Not all of them, I have updated affected changes in #1219. Trash, quest, cheats are still nice to haves, but I don't see working on that in near future. Before posting bugs check #1219 and write there. As I said, I dont plan to implement certain things in near future, but I am more than willing to fix bugs that crash server if they happen ASAP. <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. Enter ICC Test Bosses bis ICC command type bisicc into party chat or whisper and bots will reply and equip gear - Any required setup (e.g. multiple players, number of bots, specific configuration). NOTE: If server crash, bots will sometimes drop ICC strategy even though they are in ICC, simply re enter or write /p nc +ICC to re enable. NOTE: addons that mark icons during fight could break bots, since icons are used for RTI by bots NOTE: I did not use any raiding addons besides unbot and multibot to control bots NOTE: In theory everything should work wihout ICC buff from world cfg, and ICC cheats from playerbots cfg, didnt test it, didnt try, its too hard core for hc mode to go raw, but it should be possible good luck :) NOTE: For normal about 5k gs should be enough to do most bosses. For HC T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for fun experience. NOTE: As player its good to know every strategy for Bosses, so that you can spot and help out with reset, follow, summon if bots seem stuck or are doing something strange, a lot of stuff is happening on most fights so expect some intervention with reset, summon, follow. 10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for bress (its not set in stone, but most success with this setup) 25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for bress (its not set in stone, but most success with this setup) - Expected behavior and how to verify it. If requirements are met, bots should not struggle with killing bosses Compare to https://www.youtube.com/watch?v=nACyjn817iQ&t=460s --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [X ] Minimal impact (**explain below**) In theory it should not impact, didnt test with hi bot count or large player count - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [X ] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [X ] Yes (**explain below**) Impacts in raid, new actions, triggers Impacts with new bisicc cmd that will gear bots Everything should make it easier for maintenance since each boss is in seperate file now ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x ] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> AI was used for analyzing code for ac code standard violations, edits were made by me. It was used for fixing bugs, brainstorming and code generation (for complex math problems, such as dynamicaly kiting oozes around, assiging positions during multiple complex situations in rotface encouter. Everything was checked and tested multiple times until it was polished (to my abilites and understanding). It helped me to solve Malleable goo detection, defile, by hooking directly to boss in order to detect it, since it was detectable only by split second since it was not npc, spell or object. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [ x] Stability is not compromised. - - [x ] Performance impact is understood, tested, and acceptable. - - [x ] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> I have not tested with multiple players, or large servers or with 3k+ bots --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com>	2026-05-22 19:23:35 -07:00
Ivan Novokhatski	8caf37af97	Add EnableAutoTradeOnItemMention config option (#2323) ... ## Pull Request Description This PR adds a config parameter `AiPlayerbot.EnableAutoTradeOnItemMention` that controls whether trade dialogues and inventory listings will be triggered for messages that contain keywords anywhere in their text (for example "got some food?"). The default value is `1/true`, so for existing installs there will be no change. This is useful for other mods that could utilise game chats for other purposes, specifically my [mod-playerbots-characters](https://github.com/deseven/mod-playerbots-characters) and @DustinHendrickson 's [mod-ollama-chat](https://github.com/DustinHendrickson/mod-ollama-chat). Individual users might also benefit from the ability to disable this functionality. ## Feature Evaluation N/A ## How to Test the Changes 1. Start the server with default config and join the game. 2. Get into a party with one or more bots. 3. Write `got some food?` to the party chat. 4. A trade dialogue along with the whispers from the bots should pop up. 5. Stop the server, change `AiPlayerbot.EnableAutoTradeOnItemMention` to `0`. 6. Start the server, join the game. 7. Get into a party with one or more bots. 8. Write `got some food?` to the party chat. 9. Nothing should happen. > [!NOTE] > In both cases the commands `t something` and `c something` should still work. ## Impact Assessment - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## AI Assistance Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**) ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers N/A	2026-05-08 22:39:55 -07:00
ThePenguinMan96	605f1d7aaa	PvP Gear, Autogear Tuning, and Stat Weight Corrections (#2322) ... <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Hello playerbots community! I have been working diligently whilst on vacation to help get pvp gear up and running for pvp specs. Throughout this process, I have looked at our current autogear system, tested it through and through, and made some changes to make gearing more appropriate per spec. _I am going to have my description of the changes in italics_, **and the AI description overview will be bolded.** Let's begin! **This PR makes some improvements to the bot autogear system across item scoring, spec tracking(pvp specs and gear), and stat weights. Changes are split between those that are always active and those controlled by new config options.** **Mandatory Changes:** **PvP Spec Detection (IsSpecPvp) A new method RandomPlayerbotMgr::IsSpecPvp(botGuid, cls) checks the bot's stored specNo against the spec name string defined in config. If the name contains "pvp", the bot is treated as a PvP spec throughout the entire gear pipeline. This is the single source of truth used by both InitEquipment() and ItemUsageValue. In the future this detection can be expanded to drive bot behavior decisions — such as prioritizing dueling players in the world, joining Wintergrasp, or preferring BG and Arena queues over PvE content.** _This is scalable, so if someone were to create their own pvp spec in the config, it would still be tracked if the name contains "pvp". I like the idea of pvp specced random bots having an identifier for pvp events._ **PvP Weights Applied During Loot Evaluation ItemUsageValue::QueryItemUsageForEquip() now calls IsSpecPvp() before scoring a looted item. If the bot is on a PvP spec, it passes SetPvpSpec(true) to the StatsWeightCalculator, ensuring looted items are evaluated with PvP stat priorities (including resilience weighting) rather than PvE weights. Previously, a PvP-specced bot would score loot identically to a PvE bot.** _So, during autogear and upgrade equips, pvp specced bots will now heavily prioritize resilience. On the flip side, pve bots really don't want resilience gear, so a negative weight modifier (penalty for resilience items) has been applied to pve autogearing and upgrade equips. This is important, because you can switch a bot from a pve spec to a pvp spec, and it will automatically consider resilience items in it's inventory as upgrades, and equip them. Same for when you switch a bot from a pvp spec back to a pve spec - the resilience penalty will encourage the bot to switch back to the best available pve gear._ **Resilience Weighting After all per-spec weights are generated in GenerateBasicWeights(), a global resilience modifier is applied unconditionally:** **PvP specs: +7.0 resilience weight — strongly prioritizes resilience gear Non-PvP specs: −3.0 resilience weight — actively discourages resilience gear Resilience is additionally excluded entirely from trinket slot scoring via SetExcludeResilience(true), preventing the PvP resilience bonus from inflating the scores of non-CC trinkets.** _I tried several different numbers here - as high as 10 and as low as 3 for resilience. I ended up with 7 so nearly all specs will slot resilience in every slot EXCEPT for trinkets. I stopped weighing resilience on trinkets because they ended up being garbage trinkets for the most part - other endgame pve trinkets were way more impactful. In my testing, the only class/specs that wont use 100% resilience gears are the tanks, since defense rating/parry/block/dodge weights are so high._ **CC-Break Trinket Cache At server startup, PlayerbotFactory::BuildCcBreakTrinketCache() queries the world database for all trinkets (InventoryType=12, Quality≥2) whose spell IDs include spell 42292 — the CC-break / PvP trinket effect shared by items like Medallion of the Alliance/Horde. Results are sorted by item level descending and cached in a static vector, ready for fast lookup during gearing.** _This creates a cache of cc trinkets on startup, for this:_ **CC-Break Trinket Force-Equip During InitEquipment(), PvP-specced bots at level 50 or higher (level minimum for autogear to apply trinkets) run a pre-selection pass over ccBreakTrinketCache to find the best CC-break trinket they meet the level requirement and quality limit for. Human and Undead bots are excluded from this — they have racial abilities (Every Man for Himself, Will of the Forsaken) that share the PvP trinket cooldown, making a dedicated trinket redundant.** **If a suitable trinket is found, it is stored as pvpTrinket1 and force-equipped into TRINKET1 before the main gear loop runs. If an item already occupies the slot, it is moved to bags first. The second-chance pass also skips TRINKET1 when pvpTrinket1 is set, so the CC trinket is never overwritten.** _This is the catch-all forced pvp trinket for trinket slot 1. In my testing, I really found out how few cc trinkets there are - most of them are epic, and blue ones start showing up super late in the game. An heirloom patch would really help the lower levels, being able to equip a pvp trinket at level 10 or something. Keep in mind, that if your bot isn't getting a pvp trinket with autogear, make sure they aren't human or undead, and check your config for what quality items are allowed with autogear. NOTE - PVP TRINKET STRATEGIES ARE NOT CURRENTLY CODED, SAME WITH CC RACIALS. They will not break out of stun/cc currently. This is for future updates if/when I make a trinketstrategy._ **Enhancement Shaman Dual Wield Fix Classes like Rogues, Frost DKs, and Fury Warriors have their dual wield capability established through class initialization code in the core. Enhancement Shamans acquire Dual Wield only through a specific talent (spell 30798, learned around level 40), and the bot factory had no code to detect and apply this. The result was that Enhancement Shaman bots would sometimes have their offhand weapon unequipped — despite having the talent. After talents are applied in both InitTalentsTree() and InitTalentsBySpecNo(), the code now checks for spell 30798 and explicitly grants SKILL_DUAL_WIELD and SetCanDualWield(true) when present.** _When testing the weapon speed preferences, I noticed that randombot enhancement shamans were unequipping their offhand randomly. They would just walk around with a single 1-hand weapon. This is because they were not considered in the system as dual wielding, so when initequipment or autoequipupgrades was ran, it would unequip the offhand through a function, despite having the dual wield talent. Looking at the code, the other classes already have this flag (warriors, rogues, dks, hunters) because they didn't acquire it through talents._ **CalculateItem() Slot Awareness StatsWeightCalculator::CalculateItem() now accepts an optional slot parameter (default -1). When provided and the item is a weapon, ApplyWeaponSpeedGovernance() can be called. Both item scoring calls inside InitEquipment() — the candidate scoring loop and the incremental old-item comparison — now pass the current equipment slot.** _This change allows the calculate item function to know what slot it's working with, and that's how it modifies it's decision making for some of the optional features below._ **Holy Paladin Weapon Scoring Fix Prior to this change, Holy Paladin could end up equipping 2H weapons because haste and crit sticks (2H weapons) were outscoring appropriate 1H caster weapons — the item type penalty was not catching them correctly. Holy Paladin is now explicitly added to the dual-wield penalty group (preventing 2H weapons from being viable), excluded from the generic caster 1H penalty (since they use 1H + shield rather than a staff), and given a 0.8x soft preference for 1H weapons.** _In autogear testing, sometimes 2h weps with high crit/haste would win over caster gear - this is especially noticeable at lower levels, with shallower item pools (greens only). You'd hit autogear and the holy paladin would equip a 2h axe with crit :( So this makes it so holy paladins only use 1h weapons. They can use either a shield or an offhand, depending on stat weights._ **PvP Spec Slots Added for All Classes The existing RandomClassSpecProb / RandomClassSpecIndex config entries control what percentage of random bots in the world are assigned each spec. Previously only PvE specs (indices 0–2, or 0–3 for Druids) were defined, giving server operators no way to introduce PvP-specced random bots into the world population. This PR adds PvP spec slots for every class (indices 3–6 depending on class), all defaulting to 0 probability. Server operators can raise these values to spawn PvP-specced random bots — e.g., setting RandomClassSpecProb.1.3 = 20 would make 20% of Warrior bots run Arms PvP. Two additional PvE specs have also been added: Death Knight index 3: Double-aura Blood (a hybrid Blood/Frost PvE tank variant) Mage index 3: Frostfire (a PvE hybrid spec) All existing spec entries have been annotated with comments identifying each one (e.g., # arms pve, # holy pve) for readability.** _This change was actually added at the start - I realized that there was no way for pvp-specced randombots to spawn naturally, so I added optional probabilities to the config. They are currently set at 0% by default, but giving the user the option I feel is necessary. Also, it would have been impossible for me to test the init on randombots with pvp gear otherwise. Also, I noticed that the frostfire mage and the dual-aura dk didn't have an option, so I added them in as well, as well as names above each option for quality of life._ **Stat Weight Corrections The following per-spec stat weights were adjusted to better reflect actual WotLK priorities. Entries marked NEW did not previously exist; unmarked rows show old → new values.** <img width="795" height="268" alt="arms warrior" src="https://github.com/user-attachments/assets/cb0deb00-a985-432d-81a1-133fc953088b" /> _Arms warriors would prefer leather/ap gear about half of the time - the combined weights of both would often beat strength gear, especially at lower levels, or where the item pool was shallow. Also, they continued to spawn with spell power gear and defense gear occasionally, especially on gear with resilience (resilience, spell power, crit, haste, stam items)._ <img width="796" height="301" alt="fury warrior" src="https://github.com/user-attachments/assets/715ff3a3-3d20-4e0e-a953-7ed6fd9386db" /> _Fury warriors had the same issues as arms warrior, but really can't afford to lose a strength item - beserker stance increases strength by 20%. Also had to reduce haste here because haste really isn't nearly as important as strength, crit, arp. Haste items would win often over strength/crit/arp gear._ <img width="796" height="300" alt="prot tanks" src="https://github.com/user-attachments/assets/624de09a-2506-4aee-95aa-c49cbc5b85d3" /> _So, prot paladins and prot warriors currently are weighed identically fyi. Look at that whopping 2.0 agility - twice as important as strength? I noticed that my prot paladins/warriors were equipping agility/haste/crit items instead of defense gear on their neck, rings, trinkets, and back. This adjustment pretty much ensures that defense gear takes those slots if it's available. Removed the crit/haste weightings, because realistically if a tank wants more damage, it will just get strength. Lastly added the spell power penalty because prot paladins would spawn in fully holy gear if they were pvp specced (resilience is weighted so high, resilience/spellpower/stam/haste gear would often win). This aims to prevent that._ <img width="802" height="421" alt="dps dks" src="https://github.com/user-attachments/assets/371d1344-2382-4460-b3a7-f38b33025b73" /> _Same issue with plate dps as the warriors had. Spell power gear would occasionally spawn on crit/hit items in pve, and a ton of spell power resilience gear would spawn. There is no scenario where a DK wants spell power, this isn't patch 3.0.1..._ <img width="796" height="447" alt="blood dk" src="https://github.com/user-attachments/assets/c84a2bbf-7daa-4805-acf3-cd3bf815eda4" /> _Similar issues to prot paladin/warrior. I was really tired of seeing block rating/value gear as a result of getting gear with defense/stam. This results in a lot more defense rating/expertise/hit/dodge/parry gear, and basically makes shield stats nearly non-existent (unless the upgrade is good enough, it could still win)_ <img width="794" height="226" alt="ret paladin" src="https://github.com/user-attachments/assets/b09f40ed-b25f-4945-940c-2ce92f81c7c4" /> _Prior to this PR, the positive spellpower and int weights were enough for ret paladins to spawn with spellpower/int/haste/crit gear. This is unlikely now. And agility/ap was reduced to favor more strength gear._ <img width="795" height="306" alt="Enhancement Shaman" src="https://github.com/user-attachments/assets/1e5231fd-36ea-4b7e-a546-cf0075d17bd4" /> _While spell power is a decent stat on enhancment shamans, it was appearing on too much gear, especially on items that were haste/crit/spell power. And for elemental shamans, they were getting agi/haste/crit gear, so this aims to get rid of those items entirely without reducing haste/crit._ <img width="800" height="119" alt="shaman pally" src="https://github.com/user-attachments/assets/6ea3300a-effd-4a03-8f6f-4ae13c5383a5" /> _Holy paladins and resto shamans are scored the same, but this prevents attack power/haste/crit gear, since haste and crit are weighted high._ <img width="1025" height="385" alt="mage" src="https://github.com/user-attachments/assets/03191dfd-dc09-477d-8424-8fd56f3e0d71" /> _Prevents mages from equipping/autogearing items with attack power, some attack power/crit/haste/hit items were winning with shallow item pools._ <img width="1022" height="502" alt="hunter rogue" src="https://github.com/user-attachments/assets/06fa67c9-7709-4ee8-a0e2-34de18594018" /> _Prevents hunters and rogues from getting spell power leather gear with hit/crit. Crit is very heavy for hunters so this was decently common._ **Optional Changes (Config-Controlled)** **AiPlayerbot.PreferClassArmorType (default: 0) Applies a 3x score multiplier to armor matching the bot's class-appropriate type (plate/mail/leather/cloth). A significantly better off-type item can still win — this is a soft preference, not a hard filter.** _Are you tired of your fury warrior being a leather daddy? Are you tired of your holy paladin running around in cloth lingerie? This will fix that. For mail classes (hunters/shamans) and plate classes, this only kicks in after level 40. But it really helps adhere to the highest armor class available. This would be the perfect solution to the quarterly question "Why is my paladin wearing leather?". This definitely should remain optional, as quite a few BIS lists would disagree with it. Leather at certain stages is great for hunters/shamans/warriors/dks._ **AiPlayerbot.AutogearAllowsQuestRewards (default: 0) Builds a cache of equippable armor and weapon quest rewards at startup. Bots can then equip these items during autogear, using the quest's minimum level as the effective required level gate.** _So, I noticed that autogear didn't allow items without a level requirement (quest rewards), because it didn't know how to handle that when giving out gear. It would previously just flat out reject all quest rewards, as they wouldn't be a part of the item pool. This option enables quest rewards to be considered in the item pool, and the level correlates to the lowest level you could get the quest. I have tested this for about 3 hours across all specs and using blue/green gear, it seems like a really nice bonus. Keep in mind that I do 0 quests on my way to 80, so players like me could still benefit from those items. I think this should remain optional._ **AiPlayerbot.EquipAllSlotsAtAnyLevel (default: 0) Bypasses the low-level slot restrictions in InitEquipment(): Trinkets normally locked until level 50 Head/Neck until level 30 Rings until level 20 All other non-weapon slots until level 5** _Autogear currently has level floors for slots - they will not ever give items below the above thresholds. This config option bypasses that. I have not tested this as much as I should have, so as people test this, they could let us know of items that should be blacklisted._ **AiPlayerbot.WeaponSpeedGovernance (default: 0) When enabled, ApplyWeaponSpeedGovernance() applies a 3x score multiplier to weapons matching the spec's ideal attack speed profile. Applies to mainhand, offhand, and ranged slots only. Per-spec preferences: Arms Warrior: Slow 2H (>=3400ms) in mainhand; poleaxes and axes preferred (Axe Specialization) Ret Paladin / Blood & Unholy DK: Slow 2H (>=3400ms) in mainhand Prot Warrior & Paladin: Slow 1H (>=2600ms) in mainhand Fury Warrior dual wield: Slow 1H (>=2600ms) in both hands Fury Warrior titan's grip: Slow 2H (>=3400ms) in both hands Frost DK: Slow 1H (>=2600ms) in both hands; 2H excluded Enhancement Shaman (dual wield): Slow 1H (>=2600ms) in both hands; synchronized MH/OH speeds for flurry procs Enhancement Shaman (pre-dual wield): Slow 2H (>=3400ms) in mainhand Combat Rogue: Slow MH (>=2600ms) + Fast OH (<=1500ms) Assassination / Subtlety Rogue: Slow dagger MH (>=1700ms) + Fast dagger OH (<=1500ms) Hunter: Slow ranged (>=2600ms); melee is a stat stick, speed ignored Feral Druid: No preference (forms normalize attack speed)** _Besides pvp gearing for pvp specs, I feel like this is one of the nicest additions. It was really frustrating to see an enhancement shaman put windfury on a 1.5 dagger. Without this, weights for melee dps are calculated on dps alone, not weapon speed. You'll see 2h specs use fast 2h weapons (3.0), rogues use 2 fast weapons or slow weapons, frost dks occasionally using 2h weapons while having dual wield talents. I tested this for about 6 hours across all mentioned specs at levels 20, 30, 40, 50, 60, 65, 70, 75, and 80, with 3 quality types (greens, blues, purples). I would actually consider making this mandatory, simply because of the impact I saw in the dps charts. Super happy and proud of this._ <img width="1021" height="470" alt="files changes" src="https://github.com/user-attachments/assets/f55d955c-8760-4adf-b4d9-84797da2dc65" /> ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. _Two caches are built upon startup - the pvp trinket cache and the quest reward cache. From there, this directly modifies the stat weight calculations involving initequipement (autogear) and autoequipupgrades, as both go off of stat weight calculations. I tried to implement these changes with as little custom functions and coding as possible, and relied as much as I could on the pre-existing framework._ - Describe the **processing cost** when this logic executes across many bots. _Fortunately most of the gates are boolean so it shouldn't impact performance much at all. I ran these changes on my local server with stock 500 bots, noticed no pmon difference from the main branch. Did a 24h stress test on my server yesterday, stats looked consistent with the stress test I did prior to making any changes on 3-31-26._ _It helps that it uses pre-existing functions such as initequipment and autoequipupgrades, and it really just modifies them with slightly more logic. That being said, autogear didn't lag my server at all, nor did the bots equipping upgrades._ ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> _So, with the basic stock playerbots config (do not forget to copy the new config!), the only thing that should change is the pvp gear appearing on pvp specs, and the classes preferring more appropriate stats across the board. You can load into the game, level a bot to 20, autogear, and notice the difference. Same at level 40, 60, 75, or whatever. You could add in the optional config settings to further streamline the gear you want. I currently run with all 4 enabled, 2 of which increase the item pool, and 2 of which help guide them to more appropriate gear (armor/weps)._ ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) _The code is only used on startup (cache generation) and when autogear/autoequipupgrades is called. Not all the time, and not per tick. I noticed no performance impact after these changes._ - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) _It modifies the decision making as far as equipment goes, but as far as priority/strategies, this does not affect that._ - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) _Not to my knowledge, but I'll rely on testers and the community to let me know if it does._ ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> _AI was used in the research of the initequipment system, stat weights, and cache building. As far as generating the code, using AI was 2 steps forward, 1 step back. I used Claude Code with Sonnet 4.6 (high) and had gemini/copilot review the work. **AI did generate a large portion of the code being used.** I have personally reviewed every line, and a lot was removed out of being obsolete/new system that copied an old one/too many comments. I don't think anything else can be trimmed, though. I also used AI in the PR description, and made my own comments in italics below each entry. I hate explaining/writing._ <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> _I would like atleast 5-10 people to review this over the next 1-6 months. The big problem I used to have with my PRs was I was acting like they were a sprint, when it's really a marathon - good changes take time, and I was too quick to bust out new content. The old PRs I made introduced just as many new bugs as they did features. I learned my lesson, and have tested this extensively (code was pretty much complete on 4-10-26, been testing alone for the last 11 days) and it's ready for the test realm for others to try out. I think it's going to be a good step forward when it comes to gear decision making for bots as a whole. PvPers have come and gone too much from this project due to the lack of options, and this helps captivate that audience. Please reach out to me on discord at Zhur#4391, I am happy to hear results/suggestions there as well as here._ --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>	2026-04-24 23:22:52 +02:00
Scarecr0w12	c0c2b6ab5b	feat(Core/Playerbots): Initialize bot professions and specializations (#2287) ... ## Pull Request Description Initialize random bot professions from the factory using class-matching or weighted-random profession pairs, respect the active primary profession cap, and restore required profession tools during bot init/refresh. This PR also initializes profession specializations for eligible bots so crafted professions are not left in an unspecialized state after profession assignment. Supported specialization families include: - Alchemy: Transmute / Elixir / Potion - Engineering: Goblin / Gnomish - Leatherworking: Dragonscale / Elemental / Tribal - Tailoring: Spellfire / Mooncloth / Shadoweave - Blacksmithing: Armorsmith / Weaponsmith, plus Hammersmith / Axesmith / Swordsmith for eligible Weaponsmith bots Specialization choices are stored in bot values so they remain stable across later refreshes. Required tool items are also restored for relevant professions during maintenance. ## Feature Evaluation - Describe the **minimum logic** required to achieve the intended behavior. - Select one or two professions during factory initialization from a small weighted list. - Clamp the assigned professions to the configured primary profession limit. - Learn the profession starter spell and set skill to the bot’s profession cap. - For professions with supported specialization branches, assign exactly one valid specialization when the bot meets the same level/skill gates used by AzerothCore profession scripts. - Persist the specialization selection in stored bot values so the choice is stable and does not need to be recalculated repeatedly. - Restore missing profession tools only when the bot has the related profession and the tool is absent. - Describe the **processing cost** when this logic executes across many bots. - The added logic executes only during bot init/refresh, not as part of per-tick combat or trigger evaluation. - Runtime cost is limited to a few small switch statements, stored value lookups, spell checks, and item presence checks. - No expensive repeated searches, map scans, or per-trigger decision trees were added. - The design keeps specialization selection deterministic after first assignment by storing the result, avoiding repeated random branching later. ## How to Test the Changes 1. Build and restart the server with this branch. 2. Trigger random bot creation, refresh, or level-based reroll for multiple bots. 3. Verify in `Playerbots.log` that bots receive profession pairs and, when eligible, profession specializations. 4. Check that low-level bots do not receive specializations before the required thresholds. 5. Check that eligible bots do receive one specialization for supported profession families. 6. Verify that specialization choices remain stable across subsequent refreshes. 7. Verify that profession tools are restored when missing: - Mining Pick - Blacksmith Hammer - Arclight Spanner - Runed Arcanite Rod - Skinning Knife 8. For a few bots, inspect in game or via debug tooling that profession spells/specialization spells are present as expected. Expected behavior: - Bots receive professions that respect the configured primary profession limit. - Profession skill values are initialized to the level-based cap. - Eligible bots receive exactly one valid specialization for supported profession families. - Specialization assignments are logged and persist across refreshes. - Profession tools are restored only when required. ## Impact Assessment - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [x] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) Explanation: - The added work runs during initialization/refresh rather than normal per-tick behavior. - Logic is bounded, data-local, and based on direct skill/spell/value checks. - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Explanation: - Bots can now start with initialized professions, required tools, and eligible profession specializations instead of remaining partially configured or unspecialized. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Explanation: - The factory now contains specialization assignment branches for supported profession families. - Complexity is intentionally limited to init-time switch-based logic with stored specialization values to preserve predictability. ## AI Assistance Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) AI assistance was used for: - code generation and refactoring in `PlayerbotFactory` - drafting and refining profession/specialization initialization logic - PR description preparation All generated and suggested code was reviewed, adjusted, built locally, and validated before submission. ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers - Target branch is `test-staging`. - Profession/specialization logic is intentionally limited to init/refresh paths to avoid per-tick cost. - Specialization selections are stored to keep bot behavior stable across later refreshes. - Recent changes also add debug logging for assigned specializations and save the bot after specialization learning so assignments are visible and persisted. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com>	2026-04-17 13:54:36 -07:00
Keleborn	53a607e147	Enable bots to do Outdoor pvp (#2217) ... ## Pull Request Description Bots will now engage with outdoor pvp targets when in an area with them. I carved this out of the guildrpg system Im working on since it should work just fine as a standalone. Note this requires a core update https://github.com/azerothcore/azerothcore-wotlk/pull/25103 ## Feature Evaluation Its not expensive. the status checks are fairly light and simple. Should be on par with current rpg system actions ## How to Test the Changes You can try to use selfbot to enable this while in EPL, or set the probability of all other rpg actions to 0. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - [ ] No, not at all - [x] Minimal impact (**explain below**) - [ ] Moderate impact (**explain below**) There is some impact, but should be minimal overall. - Does this change modify default bot behavior? - [ ] No - [x] Yes (**explain why**) It will activate automatically based on default config. - Does this change add new decision branches or increase maintenance complexity? - [ ] No - [x] Yes (**explain below**) ## AI Assistance Was AI assistance used while working on this change? - [ ] No - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> Nothing beyond search functionality and autocomplete. ## Final Checklist - [x] Stability is not compromised. - [x] Performance impact is understood, tested, and acceptable. - [x] Added logic complexity is justified and explained. - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> --------- Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com>	2026-04-10 22:16:58 -07:00
bashermens	c0390a24fd	feat(Performance): BotActiveAlone activity interval fixes and default settings for avg player (#2250) ... <!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description - Bugfix the jittering on/off of botAlone activity - BotActiveAlone activity duration configurable - Updated the default config values for general user for a smoother experience - Added offset jittering for the check allowedActivity and check next AI delay to prevent cpu spikes (disabled WhenIsFriend can cause race conditions) ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [ ] Minimal impact (**explain below**) - - [x] Moderate impact (**explain below**) In a positive way, bots in your zone and 150 radius will always be active, meanwhile other bots will be active 40% of the time with intervals for 60 seconds per bot. With much lower latencies. All configurable without say. 40% and 60 seconds for more balance for those who seek bots create world feel more natural and live vs bots leveling without killing the server performance. Why not 50 due activity of bots itself 40% will result more into 45-50% like behavior and 50% prolly more 55%-60%. This it not something we want incorporate when calculating the value since it depends on various config and situation. But 40% is good base with default config. - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## Messages to Translate <!-- Bot messages have to be translatable, but you don't need to do the translations here. You only need to make sure the message is in a translatable format, and list in the table the message_key and the default English message. Search for GetBotTextOrDefault in the codebase for examples. --> - Does this change add bot messages to translate? - - [x] No - - [ ] Yes (**list messages in the table**) | Message key | Default message | | --------------- | ------------------ | | | | | | | ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> - Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com>	2026-04-03 14:54:46 -07:00
Keleborn	2ce8993986	Correct Loot rolling behavior (#2190) ... # Pull Request This fixes the loot rolling behavior issue created by #2068 . Introduce the ability for enchanter bots to disenchant items they dont need, and roll need on recipes they also need. Make it so ITEM_USAGE_AH ensures the item is not BOP. Try to reduce the call for item_usage in CalculateRollVote by passing usage if available. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? -- Add a new check that downgrades greed rolls to desired levels, or bools for the other two options. - Describe the **cheapest implementation** that produces an acceptable result? -- As implemented. - Describe the **runtime cost** when this logic executes across many bots? -- Same as before. Item usage is the heaviest part, and that hasnt changed to accommodate this. --- ## How to Test the Changes - multiple bots in a group with group loot on, do a dungeon or something. One bot should be an enchanter. ## Complexity & Impact Does this change add new decision branches? - - [ ] No - - [x] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [X] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [X] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [X] Yes (**explain why**) - - - Corrects the looting behavior to original design. If this introduces more advanced or AI-heavy logic: - - [ ] Lightweight mode remains the default - - [X] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [x] No - - [ ] Yes (**explain below**) --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging.	2026-03-20 20:37:02 +01:00
kadeshar	28a888b6e0	Added unobtainable items to config (#2133) ... # Pull Request Moving hardcoded values to config ## How to Test the Changes - use maintenance command - unequip and destroy item get from this command - turn off server - add item to config - turn on server - use maintenace command - check that different item was provided ## Complexity & Impact Does this change add new decision branches? - - [X] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [X] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [X] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [X] No - - [ ] Yes (**explain why**) --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [X] No - - [ ] Yes (**explain below**) --- ## Final Checklist - - [X] Stability is not compromised - - [X] Performance impact is understood, tested, and acceptable - - [X] Added logic complexity is justified and explained - - [X] Documentation updated if needed --- ## Notes for Reviewers	2026-03-06 07:56:53 -08:00
NoxMax	b7b67e0fd9	Feat/Fix: Expand follower bot flightmaster distance search and use correct config patterns (#2140) ... # Pull Request Feat: A common problem I have with follower bots is that if I quickly run up to a flightmaster and select a destination, as I go on my way, the bots can't get on a damn bird and say "Cannot find any flightmaster to talk". Guy was 8 yards away and they're completely blind to him. This is because when you select a destination, at that moment the bot would check `GetNPCIfCanInteractWith` from core, which uses `INTERACTION_DISTANCE`, which is defined as 5.5 yards. So the bot has to have caught up with you to be within 5.5 yards of the flightmaster. This PR expands that distance to use our own `sPlayerbotAIConfig.farDistance`, which is by default set to 20 yards. So just as long as bots have caught up to be within 20 yards from the flightmaster, they will follow you. Fix: While I was doing this, I noticed that the timings for bot flight staggering (introduced in #1281) are defined in TaxiAction and PlayerbotAIConfig. So I removed their definitions from TaxiAction, made proper calls to the configs, and renamed them to similar format that other configs use. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? Changes here use a minimal amount of code to accomplish the objective, including using pre-defined distance values rather than creating new ones. Changes have no effect on processing. --- ## How to Test the Changes For expanding flightmaster search distance: You will be using the `stay` command. A bot commanded to `stay` will still take a flight with you, if it is near a flightmaster. So you can use the command to position the bot exactly where you want it to be 1. Place your follower bot immediately next to the flightmaster 2. Take a flight and the bot should follow. Nothing new here 3. Place the bot about 12 yards away from flightmaster. 4. Take a flight and the bot should follow. Same as before. 5. Repeat again, but this time place the bot 22 yards away. It should not follow you and instead say "Cannot find any flightmaster to talk" 6. The change should work correctly with `InstantFlightPaths = 0` in worldserver.conf, or if it's set to 1/2 and bots can instantly fly. For the config of staggering: 1. Make sure `InstantFlightPaths = 0` in worldserver.conf. 2. Change the timings in playerbots.conf under the `# FLIGHTPATH` section. 3. Changes should be correctly reflected in world. ## Complexity & Impact Does this change add new decision branches? - - [x] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [x] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [x] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) Follower bots search a slightly bigger distance for nearby flightmasters. If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [x] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [x] No - - [ ] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging.	2026-02-27 16:07:42 -08:00
Rikus Louw	ea60b38eb9	Add Serpentshrine Cavern attunement quest to bot factory (#2136) ... # Pull Request I've being getting ready to test Serpentshrine Cavern strategy on `test-staging`, but noticed the bots don't currently have attunement setup. Added attunement quest. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? --- ## How to Test the Changes - Add bots and convert to raid - Make sure you have attunement by completing [this](https://www.wowhead.com/tbc/quest=13431/the-cudgel-of-kardesh) quest - Teleport to SSC and summon bots. The bots should appear in the raid. ## Complexity & Impact Does this change add new decision branches? - - [x] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [x] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [x] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) This adds the attunement quest for SSC by default If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [x] No - - [ ] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging.	2026-02-23 11:02:11 -08:00
privatecore	2f7dfdbbfc	Fix rest of trainers' related stuff + codestyle changes and corrections (#2104) ... # Pull Request * Fix the rest of the trainer-related functionality: list spells and learn (cast vs. direct learn) spells. * Rewrite `TrainerAction`: split the logic between appropriate methods (`GetTarget`, `isUseful`, `isPossible`) instead of pushing everything inside a single `Execute` method. * Change method definitions to remove unnecessary declarations and parameters overhead. * Move the `Trainer` header into the implementation. Rewrite `RpgTrainTrigger` to fit the original logic and move all validation to `RpgTrainAction` (`isUseful` + `isPossible`). * Implement "can train" context value calculation to use with `RpgTrainTrigger`. * Update and optimize "train cost" context value calculation -- it should be much faster. * Replace `AiPlayerbot.AutoTrainSpells` with `AiPlayerbot.AllowLearnTrainerSpells` and remove the "free" value behavior — please use `AiPlayerbot.BotCheats` if you want bots to learn trainer's spells for "free". * Add `nullptr` checks wherever necessary (only inside targeted methods/functions). * Make some codestyle changes and corrections based on the AC codestyle guide. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## How to Test the Changes Force bots to learn spells from trainers using the chat command `trainer learn` or `trainer learn <spellId>`. Bots should properly list available spells (`trainer` command) or learn them (based on configuration and command). ## Complexity & Impact - Does this change add new decision branches? - [x] No - [ ] Yes (**explain below**) - Does this change increase per-bot or per-tick processing? - [x] No - [ ] Yes (**describe and justify impact**) - Could this logic scale poorly under load? - [x] No - [ ] Yes (**explain why**) --- ## Defaults & Configuration - Does this change modify default bot behavior? - [x] No - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - [x] Lightweight mode remains the default - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance - Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - [x] No - [ ] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Final Checklist - [x] Stability is not compromised - [x] Performance impact is understood, tested, and acceptable - [x] Added logic complexity is justified and explained - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>	2026-02-23 11:00:24 -08:00
Keleborn	ee2a399ac8	Refactor newrpginfo data union to std::variant (#2079) ... # Pull Request As I began modifying the newrpginfo to change the types of data it stored, or add new data I found myself with the issue of ending up either with garbage memory if the information wasnt properly stored on status change, or needing complicated destructor patterns for non trivial data sets. --- ## Design Philosophy Make rpginfo able to handle more complicated information in a strongly --- ## Feature Evaluation No Feature changes --- ## How to Test the Changes - Server should be stable for an extended period of time. - Bots should be able to complete quests, fly, etc as they did before. ## 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**) Potentially as there can be more memory involved in the object. - 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: - [ ] Lightweight mode remains the default - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance - Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - [ ] No - [ X] Yes (**explain below**) If yes, please specify: - Gemini suggested the use of std::variant as an alternative data structure. I found additinal external references that correlated with the same suggestion of moving away from a union. - Implementation was performed manually with Co-pilot auto-complete --- ## Final Checklist In progress. - [ ] Stability is not compromised - [ ] Performance impact is understood, tested, and acceptable - [ ] Added logic complexity is justified and explained - [ ] Documentation updated if needed --- ## Notes for Reviewers Im not 100% sure if this is a good design choice. There are some things I didnt quite like by the end of this, specifically having to double check whenever accessing data whether exists or not even though an action has already been triggered. But I have a PR in the works where I want to store a full flight path vector, and the union was giving me issues. (It appears that state changes may be occuring in the same tick between RPG status update and the stated action, leading to incorrect data gathering. I ended up solving it by first checking a pointer to the object, and then getting the reference. ```c++ auto* dataPtr = std::get_if<NewRpgInfo::DoQuest>(&info.data); if (!dataPtr) return false; auto& data = *dataPtr; ``` --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>	2026-02-13 09:19:54 -08:00
bashermens	13fff46fa0	Improper singletons migration to clean Meyer's singletons (cherry-pick) (#2082) ... # Pull Request - Applies the clean and corrected singletons, Meyer pattern. (cherry picked from @SmashingQuasar ) Testing by just playing the game in various ways. Been tested by myself @Celandriel and @SmashingQuasar --- ## Complexity & Impact - Does this change add new decision branches? - [x] No - [ ] Yes (**explain below**) - Does this change increase per-bot or per-tick processing? - [x] No - [ ] Yes (**describe and justify impact**) - Could this logic scale poorly under load? - [x] No - [ ] Yes (**explain why**) --- ## Defaults & Configuration - Does this change modify default bot behavior? - [x] No - [ ] Yes (**explain why**) --- ## AI Assistance - Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - [x] No - [ ] Yes (**explain below**) --- ## Final Checklist - [x] Stability is not compromised - [x] Performance impact is understood, tested, and acceptable - [x] Added logic complexity is justified and explained - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Nicolas Lebacq <nicolas.cordier@outlook.com> Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>	2026-01-30 21:49:37 +01: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
bashermens	a1137dbddc	[FIX] Folder restructure (#2018) ... As requested Poll ``` 1. Yes 2. Yes 3. Maybe, but yes ``` --------- Co-authored-by: Celandriel <22352763+Celandriel@users.noreply.github.com>	2026-01-17 10:34:58 +01:00
Keleborn	83c6977de5	Refactor guild managment into a singleton (#1913) ... The idea is to centralize the creation, assignment, and management of bot guilds into a single class that can be referenced. The way this is intended to work. when the manager is created, if the config option to delete guilds is set, then it deletes all bot guilds. On startup 1. Load all guild names from database. Shuffle keys for some randomization. 2. Load Guilds from database 3. For existing guilds, identify the guild faction, number of members, and assess if the guild is 'full' based on the number of bots set in config. 4. Determine if the leader of the guild is a real player based on the leader account. 5. Mark any playerbot guild names as not available (false). The validation process (2-5) is set to run once an hour. Guild Creation. Now guild creation occurs on an as needed bases during the initialization process. Previously, all of the guilds would be created at once, and then randomly assigned. When a bot is not in a guild during initialization, it will check if there are any partially filled guilds of that bots faction where the bot can be assigned to. If not, and the cache of bot guilds is less than the set number in config, it will randomly return the available name. This then goes to the CreateGuild function where the core guild manager creates a guild, the guild emblem is set, and the cache updated. If a bot is assigned to guild, but fails to join then it throws an error. Checking for real player guilds function now lives in the guild manager. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>	2026-01-03 15:15:28 +01:00
Keleborn	9917863ca1	Feat. Add Fishing action and fish with master. (#1433) ... ### Update :Thank you to @notOrrytrout from prompting me to work on this. Its been a huge learning experience. With @notOrrytrout I started working on enabling bot fishing with master, but also on their own. The first commit didnt crash, showing that it was possible to have a bot cast when master does. Currently it compiles but crashes when you try to fish with a bot in the group, whether the bot has fishing or not. It makes me think that the check in FishingValues is broken somehow, but I cant figure out how. --------- Co-authored-by: bash <31279994+hermensbas@users.noreply.github.com>	2025-12-27 19:50:18 +01:00
nick	a37dd2b9ae	Clarify random bot timing configuration section and parameter descriptions (#1826) ... This update reorganizes and rewrites the random bot timing configuration section for clarity and accuracy. The previous section was mislabeled as "INTERVALS" and lacked precise descriptions. The new version: 1. Renames the header to RANDOM BOT TIMING AND BEHAVIOR 2. Adds concise, standardized comments for each parameter 3. Corrects misleading terminology (not all values are intervals) 4. Documents defaults and actual behavior clearly for easier tuning and maintenance 5. No functional code changes — documentation and readability only. Note, this is derived information from reading the code. Please double check if I have captured each param accurately!	2025-11-11 09:21:13 +01:00
bash	377ac199a7	Revert "Feat: Filter bot logins by level range" (#1705)	2025-10-03 22:58:30 +02:00
IainD92	f2b5580495	Maintenance config for altbots (#1693) ... * Maintenance config controls bools in config * Update TrainerAction.cpp removed some note-to-selfs (personal config preferences) * Set default to true Also tidied up some comments * Update playerbots.conf.dist * Reorganised Changed the description in conf to be less conversational. Rearranged the order that options are arranged, grouping by what made sense to me (the type of gameplay made easier/skipped by the option being enabled). Rearranged the order the variables and method calls are listed in the code to match the order they are presented in the conf to make future maintenance of maintenance (:P) more intuitive. * Update playerbots.conf.dist Revert previous commit (change to call order in MaintenanceAction::Execute) conf settings grouped	2025-10-03 11:56:16 +02:00
kadeshar	1ea17e593a	Merge pull request #1499 from NoxMax/login-range ... Feat: Filter bot logins by level range	2025-10-01 17:42:39 +02:00
bash	0cc15411c1	license update (#1674)	2025-09-30 15:19:44 +02:00
Iain Donnelly	6f79193d7a	Config option to set max number of guild members in random bot guilds	2025-09-28 14:04:09 +01:00
bash	c8f32569a8	Merge branch 'master' into login-range	2025-09-28 00:27:05 +02:00
Alex Dcnh	e175eb1178	Paladin buff logic: Sanctuary+Kings synergy, role-aware targeting, safer Greater buffs (#1603) ... * Paladin buff logic: Sanctuary+Kings synergy, role-aware targeting, safer Greater buffs * Update PaladinActions.cpp * Update PaladinActions.cpp * All configs should be implement into PlayerbotAIConfig and sPlayerbotAIConfig used in code * added: prayer of fortitude * Magic number removed * Update PaladinActions.cpp * Update PaladinActions.cpp * Update PaladinActions.cpp * Update PaladinActions.cpp * Update PaladinActions.cpp * Add patch for solo paladin in group * Correction review * Update PaladinActions.cpp * Add harcoded text to DB	2025-09-18 19:52:26 +02:00
zeb139	bf56154eee	Add weighted bot to banker teleport logic and config (#1615) ... * add weighted bot to banker teleport logic and config * moved banker location lookup tables to top of file	2025-09-06 16:10:56 +02:00
NoxMax	02343edc46	Merge branch 'master' into login-range	2025-08-26 22:50:29 -06:00
kadeshar	bc737ecc68	- Changed standalone config on cheat (#1585) ... - Changed drink condition	2025-08-26 18:28:42 +02:00
NoxMax	0c3a799aae	Merge branch 'liyunfan1223:master' into login-range	2025-08-18 03:48:11 -06:00
Your Name	3900237ffd	Filter bot logins by level range	2025-08-03 17:36:02 -06:00
ThePenguinMan96	8545225923	Merge branch 'master' into Tame-Chat-Action-/-Pet-Chat-Action-(stances/commands)	2025-08-01 23:30:23 -07:00
brighton-chi	e950f65a83	Add config to disable hunters from generating specified pet families (#1485) ... * Add config to disable hunters from generating specified pet families * Fixed unrelated typo in config	2025-08-01 19:29:51 +02:00
ThePenguinMan96	aa6f8153a1	Tame Chat Action / Pet Chat Action (stances/commands) ... Hello everyone, I am on a quest to make bot's pets completely functional, focuses on solving issues #1351 , #1230 , and #1137 . This PR achieves the following: 1. Changes the current "pet" chat command to "tame", which is more intuitive that only hunters can use it. The modes are "tame name (name)", "tame id (id)", "tame family (family)", "tame rename (new name)", and "tame abandon". Tame abandon is new - it simply abandons the current pet. Also, now, if you type in "tame family" by itself, it will list the available families. See pictures below for examples. 2. Added new "pet" chat command, with the following modes: "pet passive", "pet aggressive", "pet defensive", "pet stance" (shows current pet stance), "pet attack", "pet follow", and "pet stay". Previously, the pet's stance was not changeable, and there were some less than desired effects from summonable pets - see the issues above. 3. New config option: AiPlayerbot.DefaultPetStance, which changes the stance that all bot's pets are summoned as. This makes sure when feral spirits or treants are summoned by shamans and druids, they are immediately set to this configured stance. Set as 1 as default, which is defensive. (0 = Passive, 1 = Defensive, 2 = Aggressive) 4. New config option: AiPlayerbot.PetChatCommandDebug, which enables debug messages for the "pet" chat command. By default it is set to 0, which is disabled, but if you would like to see when pet's stances are changed, or when you tell the pet to attack/follow/stay, and when pet spells are auto-toggled, this is an option. I made this for myself mainly to test the command - if anyone notices any wierd pet behavior, this will be an option to help them report it as well. 5. Modified FollowActions to not constantly execute the petfollow action, overriding any stay or attack commands issued. 6. Modified GenericActions to have TogglePetSpellAutoCastAction optionally log when spells are toggled based on AiPlayerbot.PetChatCommandDebug. 7. Modified PetAttackAction to not attack if the pet is set to passive, and not override the pet's stance to passive every time it was executed. 8. Modified CombatStrategy.cpp to not constantly issue the petattack command, respecting the "pet stay" and "pet follow" commands. Pets will still automatically attack the enemy if set to aggressive or defensive. 9. Warlocks, Priests, Hunters, Shamans, Mages, Druids, and DKs (all classes that have summons): Added a "new pet" trigger that executes the "set pet stance" action. The "new pet" trigger happens only once, upon summoning a pet. It sets the pet's stance from AiPlayerbot.DefaultPetStance's value.	2025-08-01 01:18:16 -07:00
kadeshar	f76435b4c4	Merge pull request #1473 from Tierisch/master ... Add option to remove 'healer dps' strategy based on specified map.	2025-07-31 16:50:06 +02:00
kadeshar	eef2e8c1ef	Merge pull request #1456 from brighton-chi/worldbuff ... Make world buff strategy conditions configurable	2025-07-27 12:32:26 +02:00
Spargel	66b326d79e	Merge branch 'master' into master	2025-07-27 02:57:03 -05:00
Spargel	64b09fd3ca	First pass for adding 'healer dps' check based on map ID.	2025-07-27 01:20:57 -05:00
kadeshar	1e33b28abe	- Added raid cheat to configuration to add posibility to turn off (#1465) ... - Added General Vezax strategy	2025-07-27 13:51:45 +08:00
crow	564bb198fb	Merge remote-tracking branch 'upstream/master' into worldbuff	2025-07-24 00:48:57 -05:00
Yunfan Li	4a00c954ed	RPG update travel flight status (#1445)	2025-07-23 23:37:41 +08:00
crow	0b03b277c2	Make world buff strategy conditions configurable	2025-07-20 21:37:54 -05:00
Yunfan Li	f0c6aaff0b	Random bots gear related enhancements	2025-07-05 20:29:34 +08:00
kadeshar	c0aa55416b	Added configuration on excluded prefixes for trade action (#1401) ... * - Added configuration on excluded prefixes for trade action * - LoadListString usage reference specified * - Code refactoring	2025-07-04 23:13:19 +08:00
Noscopezz	e739f7820b	ICC Refactor, All bosses improved NM/HC (#1370) ... * ICC PP WIP WIP * added mutated plague for PP * BPC added (kinetic and boss targeting need to be done by player) OT collects dark nucles, bots spread on vortex and other stuff they do ok on their own. Tested only on 10NM, should work on 25NM * Tank pos. correction * BQL, ranged spread, link, flame, bite, tanking tested 10NM to do (better fire spread, hc tacti, melee spread when in air) * LDW improved improved shadow logic, ranged spread for easier shadow handling * dbs update, fixed teleporting Bots should only go and teleport to the mage that is actually below zero now * DBS ranged fix Ranged should spread more quickly and freak out less * Festergut && DBS fixed ranged spread (both) fixed spore logic (fester) * Rotface fix Improved big ooze tanking (static pos, todo kiting) ooze explosion spread mechanic fix ooze pool fix Player needs to mark rotface with skull icon, oterwise bots try to attack oozes * BQL fixed for 25nm todo: better melee logic in air phase, better melee flame spread * VDW, Sister Svalna, Sindy update Sister Svalna, bots can pickup spears and throw at svalna when she has shield up VDW added healer strats to use portal and heal boss (atm druids are for raid healing only, so use druide + any other healer, ideally player should be healer) todo (focus on supressers, add healer rotations, atm they use quickest spell they can) Sindragosa Added tank boss manipulation (boss orientation and position) bots detect (buffet, unchained magic and chilled to the bone and act accordingly) bots detect frost beacon move to safe spot and los frost bombs around them, while dpsing tombs (todo stop dps if only one tomb is left, if we have frost bombs around, not a big deal atm since in nm they dont one shot) Last phase bots los behind tomb to loose buffet, tanks swap when they have hi buffet count. Player should tell bots with skull rti if they should kill tomb or focus boss. todo (dynamic tomb los in last phase so that healers can see tank but also hide behind tomb to break los from boss) Removed some debug messages, improved LM spike action (nearest bots also try to help kill it) Improved Lady Deathwshiper shade action (only targeted bots will run away instead of every bot that is near it) dbs improved tank switch I recommend to use 3 healers (just to be safe) and 2 paladin tanks (warr seems to struggle with agro) in 10 man 25 man 6-7 healers (just to be safe) Since most of the bosses are about survival and not dps * LK Update (doable) LK added Improved tank switching for all bosses Fixed PP gas cloud kiting Malleable goo todo (dont know how to detect it since its not object or npc) just summon ranged bots to safe position to bypass BPC fixed OT sometimes not tanking kele kinectic bombs todo (for now player should take care of them) Sindragosa fixed rare case when she is in air phase but tombs went to last phase position LK Bots can handle necrotic Bots can handle adds Bots should focus valkyre that actually grabbed someone (if unlucky and player just use attack command and summon bots to you if they are far away from you) if they grab bots you can either summon to make them useless or let bots cc them and do it legit way. Defile should be watched by player and once it was cast just summon bots to you Vile spirits for some reason go to the ground and get nuked by bots aoe spells so there is not much to be done **Player needs to be alive the whole LK fight since you will have to watch out for frost spehers (sometimes bots ignore them), summon bots when defile is up and summon ranged bots if they get stuck near shambling or raging spirits since their aoe will wipe you) all in all LK is doable both 10 and 25nm, player needs to have knowledge of lk fight and needs to know how to use multibot addon and make macros for eg summoning or commanding groups of bots or individual bots) Dont forget frost/shadow/nature resist auras in whole ICC since it will help alot I have done whole icc 10 and 25 with 2 pala tanks, 2/5 heals and rest dps, if you use +1 or +2 heals it should be easier (since I was testing I did close to 0 dmg in fights same with heals) * fixed changes made by mistake fix * Malleable fix (simple spread mechanic) Malleable mechanic added (simple spread for now) Gas cloud fixed (Bots sometimes got stuck between puddle and kite location) * Defile Update Bots detect and avoid defile (they struggle to find a way back to the boss around it tho, use summon to help them) Melee bots should be able to stand behind/to the flank of shambling/spirits * GS fixed bots not returning to their ship for A and H Bots will return back to ship after killing mage * PP gas cloud kiting improved PP gas cloud kiting improved * BPC targeting fixed Bots will mark valid prince with skull RTI now * BQL added melee spread in air pahse BQL added melee spread * VDW healing rotation improved Healers will now use strong heals and hots * Fixed Necrotic Plague Fixed issue with Necrotic where it would get dispelled too soon, or would not get dispelled at all * LK Update Refined defile logic Added 3 points for ranged and melee in winter phase (east, west, south when facing throne) fixed frost spheres targeting (hunter will focus them) Atm bots will reset z axis if they fall underground or if they get teleported by lk Better positioning in 1st phase * 10HC update until PP LK defile improved for 10nm (bots sometimes stood 2 close to defile until it grew few times) Improved rotface for HC PP remade for 10HC. Gas cloud is now properly kited Fixed a rare case of server crash when there were ooze and gas cloud alive at same time. Bots will move around puddles according to its size now. Bots that get unboud plague will simply move away from raid and die thus loosing it from raid. Volatile ooze improved stacking. Fixed ranged sometimes glitching thru walls when spreading out from other members. 10HC PP is now doable but its hard without summoning (summoning break gascloud and ooze targets so its easier to do). You need to watch boss so you dont phase 2 soon otherwise you will get 2x ooze and cloud which is almoust always a wipe. If abo is not played near perfection bots will struggle with oozes and gas clouds if they are not slowed on time. Always save energy to slow gas cloud since it will wipe the group if it reach its target. Bots will sometimes stand in puddle, just command them to move and they will figure out what to do. todo (proper malleable handling) * Up until Sindy 10HC BPC added shadow prison handling, bots stop moving if more than 12 stack, tanks more than 18 Improved spreading logic VDW fixed issue where bots in portal wold move at half speed compared to real player * fixed accidental change * LK 10HC update Added Shadow trap logic (if they stand in it, not a big deal since bots wont get yeeted only players will) When harvest soul, only player will be in another dimension (you must survive) **Sindy and LK can be done, but I must dissapoint purist, at my skill level I could not achieve to do HC without using summon or other "cheat" bot functions. Other bosses are all doable now in 10hc * ICC fixes GS, PP; BQL, SINDY Minor fixes, bite action improved * ICC improve Sindy Bots will now choose non beacon position based on difficulty, 10/25 * ICC fixed missing A/H buff Fixed missing ICC buff for A and H Buff will only be present when logged on and in ICC, once any bot or player leave ICC the buff is gone to prevent abuse. This will make ICC easier now and with recent DPS update and movement improvement bots will now actully do decent dps and even greater healing. Ally buff https://www.wowhead.com/wotlk/spell=73828/strength-of-wrynn Horde buff https://www.wowhead.com/wotlk/spell=73822/hellscreams-warsong * revert last change revert buff * ICC improve Rotface Bots will now mark Rotface with skull icon, which will make them focus boss instead of oozes automatically * ICC Festergut 10 Man fix There was a rare case in 10 Man when 2 tanks would get spores which made them both stack at melee spot. Now the code will check if any of the spored player is main tank, if it is, it will stay at melee and other spores will go at ranged spot since off tank doesn't really need to stand near main tank all the time. * ICC BPC major update, fix and improve Fixed main tank sometimes not tanking both bosses (vala and talda) Improved marking of current prince Empowered vortex: bots will now spread out when it is being cast, instead of always spreading(ranged). This will make melee also spread better now since bots will calculate and move to optimal positions. Added Kinetic bomb handling. Hunters will take care of bombs, if no hunter is present then any ranged dps will take care of kinetic bombs. * ICC BQL/VDW major update + minor fixes/improvements LDW improved spreading for ranged, tanks will move boss in the middle of the room now when shield is depleted which will make bots bug less around pillars GS Assist tank will not teleport to enemy ship and will keep tanking adds on our ship now DBS ranged spread improved (they will calcualte spot for each bot and stick with it reducing movment to minimum), fixed bug where in 25 man ranged bots would go behind walls, making them unable to dps boss, improved rune of blood tanking Festergut ranged spread improved (they will calcualte spot for each bot and stick with it reducing movment to minimum) BQL Melee spread improved, bite logic improved, added swarming shadows logic (not perfect but at least it wont be all over the room anymore), Tanks will properly handle blood mirror now VDW boss and raid healers will be automatically assinged depening by number of healers(if more than 3 healers in group, 2 will focus on raid and others will heal boss, otherwise one healer will heal raid). Druid will be assigned to raid healing if no druid present then some other random heal class. Added rotations for druid healers if they end up healing the boss. Raid healers will not use portals anymore. Healers will come to the ground now after using portals (they were stuck in air) * ICC LK minor update PP Removed pre stacking for ranged when volatile ooze spawn (they will kill it much faster now and only stack if someone actually gets targeted by ooze) LK Hunters will use trnaq shot to remove enrage from shamblings Improved valkyr cc Minimized ping-ponging during winter phase * ICC minor Sindy improve Reduced position tolerances and forced movement for beacon and non beacon positions which will make bots move to spot that they actually need to be at instead of randomly running to sindragosa or beaconed players. * ICC minor update GS Bots will mark mage with skull rti Rotface Fixed bots glitching thru walls and floors (added check if position is valid before moving) PP Bots will mark volatile ooze with skull rti now which will help them focus it and kill asap (usefull for heroic when both volatile ooze and gas cloud are present at the same time) VDW Added default group position in the middle if the room so that bots don't spread out too much which will force them to focus supressers more Fixed Boss healers not keeping themself alive when low on HP * ICC LK minor update Commented out z axis bypass since it was fixed with recent core updates. Bots no longer fall thru buggy platforms so its no longer needed which in return makes valkyrs works as they should. * ICC LM & LDW Improved LM Removed Attack Action since it was buggy and replaced it with RTI. (Improved DPS) Simplified trigger for spike action, since attack logic is handled by skull RTI now. Bots (tanks) will mark spikes with skull RTI, which will make bots instantly switch to Spike targets. If no spike is present, the boss will be marked. Added logic that will make non-tank bots move away from LM to a fixed position behind LM if they happened to be in front of LM (No more insta kills with cleave). If LM is casting Bone Storm, bots will ignore the above logic and do max dps. LDW Removed Attack Action since it was buggy and replaced it with RTI. (Improved DPS) Bots (tanks) will mark adds with skull RTI, which will make bots instantly switch to adds targets. If no spike is present, the boss will be marked, which will help with keeping allies alive when they get mind controlled by LDW. Moved 2nd phase position deeper into the room and reduced boss hp trigger to 95%, which will keep tanks where they should be during 1st phase (sometimes the boss dropped below 98% and tanks would ping pong around the room). Ranged bots will now spread closer to each other now and will ignore spreading if they are 2 far or 2 close to the boss so they can properly reposition. These changes should also fix recent bugs with bots not casting/standing still on LM and LDW. * ICC DBS Improve Replaced attack action with RTI. (Improved DPS) Ranged bots will move away from blood beast if targeted by it now. * ICC Sindragosa and LK Improve Sindragosa Improved tomb los for frost bombs. Bots will now mark tomb with moon rti to avoid killing it too soon. (If they still attack the tomb, simply reset and after bombs are over, simply attack the tomb to kill or mark with a skull.) Main Tank will reset mystic buffet stacks now to avoid tank swapping since it's really unreliable which will make sindy less frustrating to kill (other bots will need to do mechanics properly by hiding behind ice tombs). LK Necrotic plague action Bots will now check before moving to the Shambling if they are in front of the Shambling to avoid getting one shoted by shockwave. Improved multiplier, which will now properly handle dispelling of necrotic plague. Winter phase action Bots will properly move behind adds to avoid getting one shoted by shamblings or raging spirits. If there is a hunter in the grouphunter will focus on spheres; if not, any ranged DPS will focus spheres. Adds action Bots will now be in proper positions during the 1st phase, and when the off tank is done collecting shamblings, it will move away from the group. Bots (non-tanks) will move behind the shambling if they are in front of it to avoid getting one shoted in the 1st phase. Restored action for checking if bots are at ground level, since they were still sometimes glitching through the floor (valkrys will be able to carry bots and drop them off the edge if not killed in time). Improved defile calculations for 10 man and 25 man raids since defile was growing differently for 10 and 25, which would make bots in 25 man move very far away from somewhat small defile puddle. Bots will now properly CC any valkyr that wasn't CC'd, and they won't freak out anymore if multiple valkyrs are present. (They can't tell which valkyr is holding bots/ players, so we should command an attack on valkyrs that are holding someone.) Bots will now run away from Vile Spirits if they are targeted by them during the last phase. * ICC 25HC ldw shades fix Fixed bots could not detect shade if there were multiple present * ICC trigger optimization Optimized trigger and action for: KineticBomb OozePuddle * ICC LK Improve Improved Shadow Trap, Winter phase and 1st phase. Bots will now have fixed positions for 1st phase if no shadow trap is present. Tanks will now take care of taunting adds during winter phase. (Assist tank will collect adds and bring them to main tank, main tank will take over the adds so we have minimal chance of adds rotating towards the raid) Fixed shadow trap detection. * ToC dungeon update Added TOC dungeon strategies for 1st encounter. Other encounters are pretty easy and straightforward so they do not require strategies. They can be all done with follow, reset, summon, attack, skull icon etc... Bots (A/H) will automatically check if they have lance equiped or in inventory. If they don't have lance they will pick it up from nearest lance stand and equip it. Bots will mount nearest mount if they have lance equipped. Once mounted they will keep Defend aura at 3 stacks (top priority). In fight they will cast charge if more than 5f away, they will cast shield break if target has Defended aura active and they will use Thrust if they cant use anything else. In short they will melt any target and enemies wont stand a chance keeping their defend aura up. Once champions are defeated bot will automatically equip best weapon they have in inventory (weapon that was swapped with lance) * ICC minor update LM Bots will now move in smaller increments to get behind boss They will still move towards fixed position, but as soon they are not in front of boss, they will stop moving and do other actions. GS Fixed cannon trigger, now will return true if cannon is 100f from bots. It used to return true all the time. * ToC added Eadric strat bots will look away during radiance cast * ICC LK minor fix fixed crash in icclichkingsaddsaction * ICC GS fix While encountering edge case when playing horde, the logic was to detect mages, there are usually 2 around, but the longer the fight last the bigger the chance that cannons would kill all the mages thus once we kill the mage that was casting deep freeze bots could not execute action that would return them back to the ship, so the boss had the time to nuke them one by one. Even tanks have hard time surviving the boss. I have changed it now (both A/H) so that we keep track of the enemy boss (which is hard if not impossible to kill as main trigger) and we are keeping track of the mage that is actually casting deep freeze, we mark it with skull, and now as soon the mage is dead, bots will remove the mark so there is 0 confusion about what to do next on their side, and they will come back asap. * FoS Improved and fixed, ICC LM, LDW and PP updates FoS Improved/fixed triggers, Improved/fixed actions. Bronjahm Tank will properly kite soul fragment around the room Replaced attack action with skull rti to focus soul fragments Non-tank bots will only try to stay within 10f of boss only once we enter last phase, tank will be in the middle of the room if it is not kiting soul fragment Devourer of Souls DPS bots will stop dps if boss is casting mirrored soul Laser can be easily avoided with follow/summon ICC LM Tank will only move to tank position if it actually have the agro, it used to move there without agro and few of the bots would get killed since tank was unable to reach bot LDW Fixed edge case where tank would be target of shade and it would be unable to move away it from it due to tank position restrictions, now if Tank is targeted by shade it will be able to move and run away from it (in hc this could cause wipes since explosion is aoe + tons of dmg) PP When oozes spawn, tank will move towards green ooze spawn to keep raid near green ooze (faster kill) and far away from gas cloud (better chance to kill if abo didn't manage to slow it) * PoS Strategies Ick and Krick All boss mechanics implemented Forgemaster Garfrost Easily doable with follow/stay/summon Scourgelord Tyrannus Ranged bots will spread so that they all don't get frozen by dragon They avoid everything else on their own * ICC Refactor, All bosses improved NM and HC Major Update * Update playerbots.conf.dist	2025-06-11 23:27:44 +02:00
bash	6fbaf6510b	Revert "Fixed opening trade window while using DBM or Questie addon (#1363)" (#1367) ... This reverts commit dfa87faf5e6eaddaa440197b4b980115bd440a14.	2025-06-09 01:53:17 +02:00