mirror of
https://github.com/liyunfan1223/mod-playerbots.git
synced 2026-06-20 23:49:25 +02:00
69 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Crow
|
05e8f4d82c
|
Implement Black Temple Strategies (#2381)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This PR implements strategies for all bosses in the Black Temple. As
always, I’ve written these with the intent that all bosses be
completable with appropriate gear and 50/50 IP nerfs and boss HP
returned to TBC levels. Illidan is difficult at those parameters, but he
is certainly doable. You just won’t be able to roll a bunch of meme
specs or shitty compositions. Probably.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
My goal with raid strategies is the same—I’m not just trying to make
encounters doable but am trying to allow people to experience them in a
way that feels like they are part of a coordinated raid of real players.
To me, being able to achieve that is the minimum, and that requires
getting bots to respond to all major mechanics, even if they can
technically just be powered through.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
Run the Black Temple raid and see if my descriptions of strategies in
the next post check out.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [x] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
The performance impact exists only when the “blacktemple” strategy is
on. I’ve tested with pmon and done my best to properly gate checks to
limit the performance impact even during the instance and boss
encounters.
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
The triggers and multipliers will be evaluated as long as the
"blacktemple" strategy is active, and it will be applied automatically
in the instance (and removed automatically when changing maps outside
the instance).
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
GPT-5.4, mainly for calculations and things that are more intermediate
concepts that I’m not proficient with like lambdas.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
NoxMax
|
66d41e1d79
|
Feat: Selective reset to default of combat or non-combat strategies (#2365)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Adds the commands `co !` and `nc !`, which would reset either the combat or non-combat strategies of a follower bot, without affecting the other strategies or any other values. Also ChangeStrategyAction.cpp was refactored for duplicate code by introducing the helper function `HandleStrategyCommon`, that gets called by `ChangeCombatStrategyAction` and `ChangeNonCombatStrategyAction` ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. `reset botAI` already resets strategies back to default, but it resets ALL strategies and wipes values such as formations, stances, and everything else under the `value` key in playerbots_db_store>value. The new commands don't run across many bots, only on the bot the command is run on. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Run either `co ?` and `nc ?` to see current list of combat and non-combat strategies the bot has. 2. Add and remove strategies to both `co` and `nc`. 3. Confirm your changes with `co ?` and `nc ?`. 4. Run `co !` only. 5. Run `co ?` to confirm combat strategies have been reset to default, and `nc ?` to confirm it has not been affected. Then run `nc !` to reset it as well. 6. Do another test [inside an instance](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#raid-specific-strategies). Remove a bunch of `nc` strategies, including the strategy for the raid itself. 7. Run `nc !` and check that the defaults have been reset, but that the instance strategy has been re-added as well. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Technically it adds a new case to ChangeCombatStrategyAction, but it's straightforward. ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> Review only in case I was missing something, and then to easily refactor duplicate code with HandleStrategyCommon. <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> [Commands wiki](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#strategies) need to be modified to read: --- You can query the bot to report what strategies are currently being used: ``` co ? nc ? ``` You can reset either of the bot's strategies back to defaults: ``` co ! nc ! ``` --- Tangentially I also recommend [this section](https://github.com/mod-playerbots/mod-playerbots/wiki/Playerbot-Commands#non-combat-strategies) to be edit to this for more accuracy: --- General strategy | description :---|:--- ``food`` | enable bot's ability to eat/drink ``pvp`` | enable bot's ability to engage in PVP combat. Note: PVP mode wouldn't appear active until the bot starts combat ``loot`` | enable bot's ability to loot. Note: adding or removing that strategy for randombots requires GM level |
||
|
Keleborn
|
b8ff5996f8
|
Flying mount fixes and self-bot (#2351)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This PR does a few things.
1. Enable Selfbots to mount up. Because they have masters, but are their
own masters, they would never mount up because their master never
mounted.
2. Fix flag state handling after processing the aura change.
3. Add in the Dismount packet handler. This is intended to implement
fall animations and have bots touch the ground when dismounting instead
of floating off the ground. (It was cleared anyway after the first move,
but this should make it more seamless.)
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
self bot should mount up, and select area appropriate mounts.
Bots in your team should mount up, and on your dismount properly snap to
the ground.
should test at low Z (<1.0 off the ground) and higher z (> 1.0 off the
ground)
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [x] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
The processing of a fall path has some impact, but I dont think itll be
too much.
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
Add natural falling when dismounting. May incurr fall damange....
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Comparison of code bases, searching for flags, adding diagnostic
logging, and processing of said logging.
iterating and brainstorming.
Code was also written, but fully reviewed by me, and fixed where
appropriate.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Ivan Novokhatski
|
7af675e712
|
Respect worldserver's PreventAFKLogout value (#2328)
## Pull Request Description
This adds checks to prevent bots from logging out when the master isn't
actually logging out, respecting the `PreventAFKLogout` setting in
`worldserver.conf`. Otherwise, returning to the game after a long pause
means your bots are offline and you have to re-add them, which is
annoying.
## Feature Evaluation
N/A
## How to Test the Changes
1. Set `PreventAFKLogout` to 1 or 2 in `worldserver.conf`.
2. Start the server, log in, add some bots to your party.
3. Go to a sanctuary if you set `PreventAFKLogout` to 1 or just start
idling anywhere otherwise.
4. Both you and the bots will stay in-game no matter how much time has
passed.
## Impact Assessment
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
Researching the issue and determining what checks need to be
implemented.
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
N/A
|
||
|
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 |
||
|
Crow
|
5d9761c9e8
|
Implement Battle for Mount Hyjal Strategies (#2258)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ### Contingent on https://github.com/mod-playerbots/mod-playerbots/pull/2295/ ## Pull Request Description <!-- Describe what this change does and why it is needed --> This PR implements raid strategies for all bosses in everybody's favorite TBC instance, the Battle for Mount Hyjal. As before, I have designed these all to work with IP with 50% damage and healing. I also did not merge the 1.88x buff to Vanilla & TBC healing items that IP recently implemented. The next post will outline all implemented strategies. Note: Set to draft for now as I may tweak Archimonde some more, but I generally consider Hyjal complete, subject to comments. ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. As with previous strategies, I've worked within the existing context of actions/multipliers/triggers. This strategy does implement new spell hooks, but I don't think that is problematic for performance, and I'll explain why they are necessary in the next post. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [x] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) There are many new triggers, multipliers, and actions, but they will be evaluated only if the "hyjal" strategy is added. Additionally, I've attempted to order and implement checks in a manner to limit performance impact and have tested with .pmon active. In general, I consider performance to be highly important so am always working on ways to limit the impact (e.g., trying to use the most targeted grid searches available when needed). - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Only in the Hyjal instance, for obvious reasons. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) New decision branches apply only in the new Hyjal instance, for obvious reasons. Maintenance complexity should not be increased as code outside of the new Hyjal files is not impacted, except to the extent needed to register and implement the strategy in the same manner as all existing strategies. Exception: As noted, I did add new spell hooks, but if they become problematic, they can easily be removed. ## Messages to Translate <!-- Bot messages have to be translatable, but you don't need to do the translations here. You only need to make sure the message is in a translatable format, and list in the table the message_key and the default English message. Search for GetBotTextOrDefault in the codebase for examples. --> - Does this change add bot messages to translate? - - [x] No - - [ ] Yes (**list messages in the table**) | Message key | Default message | | --------------- | ------------------ | | | | | | | ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> - Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> Claude Sonnet 4.6 was used for more complex implementation and occasionally GPT-5 mini was used for simple questions. I do not use AI for brainstorming or developing strategies, only for implementation and review of code. Most of this was written by me directly, but most notably I needed AI support to implement the spell hooks and triggers/actions that relied on them. Everything was reviewed and tested many times. ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. Caveat: The full impact of implementing the spell hooks on a broad scale is beyond my knowledge to evaluate. - - [x] Added logic complexity is justified and explained. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com> |
||
|
Keleborn
|
38caa1daa7
|
Randombots respect realm PVP setting (#2342)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Fix an issue where bots would eventually have pvp set by reset. THis
ensures bot pvp states are consistent with realm type.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
Corrects behavior to match server intent.
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
searching code, writing it.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
Keleborn
|
ccce14238e
|
Core Update, change to DeserterCheck and signature (#2354)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Required change for https://github.com/azerothcore/azerothcore-wotlk/pull/24641 ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [ ] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [ ] Yes (**explain below**) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [ ] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [ ] Stability is not compromised. - - [ ] Performance impact is understood, tested, and acceptable. - - [ ] Added logic complexity is justified and explained. - - [ ] Any new bot dialogue lines are translated. - - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> |
||
|
Crow
|
104a1b9ee1
|
Clean up unnecessary includes in raid strategy and trigger-context headers (#2347)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This PR trims redundant includes from raid Strategy.h and
TriggerContext.h headers. I noticed a consistent pattern of including
Multiplier.h when it was not needed in Strategy.h and including
AiObjectContext.h in TriggerContext.h when only the narrower
NamedObjectContext.h is needed (both of which I was guilty of also).
Since we make new raid strategies based on existing raid strategies, I
figure let's go for the low-hanging fruit and just fix this so we stop
doing it wrong going forward.
While I was at it, I removed other unnecessary includes but in those two
files only (across dungeon and raid strategies).
Edit: Made a couple of other minor code cleanups I'd been intending to
do. Notably, we shouldn't be including a .cpp in PlayerbotAI.cpp.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
I had GPT-5.4 do the actual work because doing it myself file-by-file
would've been such a snoozefest.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
kadeshar
|
ed5791eabf
|
Pull target overlap fix (#2335)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Fixed "pull target" value which was overlap with new pull strategy. Related with #2334 ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Invite tank bot to party 2. Use `nc +debug` 3. Use command `do attack my target` 4. In debug shouldnt be `reach pull` or similar ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> To analyze problem with value <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> |
||
|
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> |
||
|
Keleborn
|
eb268c7507
|
Init guilds on login. (#2325)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Guild solution to #2148 ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [ ] No, not at all - - [x] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) Minimal cost on bot login. - Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> |
||
|
Keleborn
|
866a73dfbf
|
Clean up unused variables (#2268)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Clean up a bunch of additional unused variable warnings.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
- Does this change add bot messages to translate?
- - [x] No
- - [ ] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
| | |
| | |
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
- Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Claude reviewed the warnings log from a build and suggested a series of
changes. I focused just on these warnings for now. Every line was
reviewed. Some sections need to be reviewed by author for intent.
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
Keleborn
|
a4b37c9fbc
|
Revert "Feat: Reintroduce timed logouts" (#2329)
Reverts mod-playerbots/mod-playerbots#2289 |
||
|
kadeshar
|
19249e90a0
|
Pull strategy migration (#2310)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Pull strategy migration from cmangos for tank specializations
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
1. Invite bot tank
2. Use `reset boAI` or `nc +pull,+pull back` + `co +pull,+pull back`
3. Order bot to pull using command `pull my target` or `pull rti target`
4. Bot should run to mob, use ranged skill and back to point where he
started pull
Without `pull back` strategy bot run to mob, use ranged skill and wait
on mob until he come to bot
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Help with migration and solving some problems
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [ ] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
Stability test after randomize new bots
<img width="465" height="172" alt="obraz"
src="https://github.com/user-attachments/assets/6e39a8c0-f23b-47cc-852a-71fa98044a31"
/>
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
|
||
|
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>
|
||
|
NoxMax
|
6c517eb9d1
|
Feat: Reintroduce timed logouts (#2289)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Timed logouts was enabled in the past, but was disabled due to a misdiagnosis on an issue that caused crashes. That issue was better understood and resolved in #2131. Now timed logouts are reintroduced for alt-bots and addclass-bots. As before, random-bots do not and should not accept logout commands. Note that if the bot's master has instant logout privileges according to `InstantLogout` in worldserver.conf, so would the bot. If not, neither would the bot. ## Feature Evaluation <!-- If your PR is very minimal (comment typo, wrong ID reference, etc), and it is very obvious it will not have any impact on performance, you may skip these question. If necessary, a maintainer may ask you for them later. --> <!-- Please answer the following: --> - Describe the **minimum logic** required to achieve the intended behavior. - Describe the **processing cost** when this logic executes across many bots. Feature at minimum logic needed to implement. No measurable processing cost. ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Have your account gmlevel set to 2 in acore_auth>account_access just to test how it works with security parameters. 2. Set `InstantLogout = 3` in worldserver.conf. 3. Invite an addclass or alt-bot. 4. Bot should logout if whispered "logout" to or if you logout. 5. If not in a resting place, neither you nor the bot should be able to instant logout according to the security setting. 6. After the bot logout, log it back in and whisper "logout" again, but right after whisper "cancel logout" or "logout cancel". That should cancel the logout. 7. Have your account gmlevel set to 3 in acore_auth>account_access. (when you change your gmlevel, you need to log out of your account for the change to take effect) 8. You are now at admin gmlevel, and with `InstantLogout = 3`, you and any bot under your command should be able to logout instantly. ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Bots now trigger instant or timed logout under the same circumstances that would apply to their master. - Does this change add new decision branches or increase maintenance complexity? - - [ ] No - - [x] Yes (**explain below**) Checks if bot is eligible for instant logout or not. If not, timed logout applies to them. ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> While testing this I was having some odd issues with the command `account set gmlevel`. Not sure what's going on there, but for purposes of testing this and changing your account security level, doing it directly in the DB at "acore_auth>account_access" is going to be most reliable. |
||
|
Crow
|
a34681bd7e
|
Modify UpdateAI to Allow Future Methods to Interrupt Bot Spells (#2295)
Note: Resubmitted because the prior PR had master for the source
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This PR adds to PlayerbotAI::UpdateAI a boolean variable,
pendingCastInterrupt, and a public function, RequestCastInterrupt(),
that toggles the variable and would then call InterruptSpells in
UpdateAI. This lets an external script hook into UpdateAI to interrupt a
spell that is in the process of being cast. This should allow
raid/dungeon strategies to actually interrupt spells, such as for
avoiding hazards, as you cannot do so by calling InterruptSpells() or
Reset() or anything else with a raid/dungeon action method.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
There is no processing cost from this PR itself since it just adds a
simple boolean check that will always return false unless other methods
are implemented to call RequestCastInterrupt().
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
This PR doesn't do anything by itself, but confirmation of no
performance impact can be tested by just playing with the PR merged. I
tested this by introducing scripts that called RequestCastInterrupt()
for Archimonde (included in the Hyjal PR now) and for Auchenai Crypts
(built on the strategy from flashtate's PR just for test purposes), and
spells were interrupted as intended.
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [ ] No
- - [x] Yes (**explain below**)
I'm not sure if it counts as "yes" here, but this PR opens up the
ability for scripts to be added that would add real checks to UpdateAI.
The impact of such scripts will depend on how they are implemented,
however. It is possible (and intended) for the external calls to be
highly limited in scope (e.g., only bots in a particular circumstance in
a particular boss fight).
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Claude Sonnet 4.6 was used to brainstorm different possibilities to
allow external scripts to interrupt spells. I considered different
options before settling on this one due to it not requiring core
changes, being easily usable in boss strategies, and not having any
performance impact on its own.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
|
||
|
Hokken
|
ce1adebc78
|
fix(Core): scope AddPlayerBot loading count to master account (#2307)
## Problem
`AddPlayerBot()` falsely rejects player bot additions with *"You have
added too many bots (more than 40)"* even when the player has zero
personal bots.
This happens because the `MaxAddedBots` check at `PlayerbotMgr.cpp:124`
adds `botLoading.size()` to the player's personal bot count:
```cpp
uint32 count = mgr->GetPlayerbotsCount() + botLoading.size();
```
`botLoading` is a `static std::unordered_set<ObjectGuid>` on
`PlayerbotHolder` — shared by both `PlayerbotMgr` (per-player) and
`RandomPlayerbotMgr` (singleton). When `RandomPlayerbotMgr` loads random
bots at startup (up to 60 per interval via `RandomBotsPerInterval`),
their GUIDs go into the same global set. During the startup loading
window, `botLoading.size()` can easily reach 100–300, far exceeding the
default `MaxAddedBots = 40` limit.
The result: any player who logs in during the random bot loading window
and tries `.playerbot add <name>` gets blocked, even though the limit is
intended to be per-player.
### How to reproduce
1. Set `AiPlayerbot.RandomBotAutologin = 1` (default) with 500 random
bots
2. Start the server
3. Log in immediately while random bots are still loading
4. Run `.playerbot add <character_name>` for an offline character on
your account
5. Get *"You have added too many bots (more than 40)"* despite having 0
personal bots
6. Wait 1–2 minutes for random bot loading to finish, try again — works
### Root cause
- `PlayerbotHolder::botLoading` is declared `static` at
`PlayerbotMgr.h:60`, so both `PlayerbotMgr` and `RandomPlayerbotMgr`
share the same set
- `AddPlayerBot()` inserts into `botLoading` at line 147 for ALL callers
— both player-initiated adds (`masterAccountId > 0`) and random bot
spawns (`masterAccountId = 0`)
- The count check at line 124 uses `botLoading.size()` (the entire
global set) instead of filtering to bots being loaded for the requesting
player
- The config comment confirms the intended scope: *"The maximum number
of bots that a player can control simultaneously"*
## Fix
Change `botLoading` from `unordered_set<ObjectGuid>` to
`unordered_map<ObjectGuid, uint32>` where the value is the
`masterAccountId` passed to `AddPlayerBot()`. Random bots are loaded
with `masterAccountId = 0`.
The count check now iterates the map and only counts entries matching
the current player's `masterAccountId`:
```cpp
uint32 loadingForMaster = 0;
for (auto const& [guid, acctId] : botLoading)
{
if (acctId == masterAccountId)
++loadingForMaster;
}
uint32 count = mgr->GetPlayerbotsCount() + loadingForMaster;
```
### Callsite compatibility
All 10 existing `botLoading` callsites were audited:
| Callsite | Operation | Compatible |
|----------|-----------|-----------|
| `PlayerbotMgr.cpp:85` | `find()` by key | Yes |
| `PlayerbotMgr.cpp:153` | `emplace()` (was `insert()`) | Changed |
| `PlayerbotMgr.cpp:174` | `erase()` by key | Yes |
| `PlayerbotMgr.cpp:209` | `erase()` by key | Yes |
| `PlayerbotMgr.cpp:229` | `erase()` by key | Yes |
| `PlayerbotMgr.cpp:1163` | `find()` by key | Yes |
| `RandomPlayerbotMgr.cpp:429` | `empty()` | Yes |
The six unchanged callsites use `find()`, `erase()`, and `empty()` which
operate on keys identically for both `unordered_set` and
`unordered_map`.
## Files changed
| File | Change |
|------|--------|
| `src/Bot/PlayerbotMgr.h` | `botLoading` type:
`unordered_set<ObjectGuid>` → `unordered_map<ObjectGuid, uint32>` |
| `src/Bot/PlayerbotMgr.cpp` | Definition type updated, `insert` →
`emplace` with `masterAccountId`, count check filters by
`masterAccountId` |
## What is NOT changed
- `MaxAddedBots` config key and default value (40) — unchanged
- Random bot loading behavior — unchanged
- The `botLoading.empty()` throttle in `RandomPlayerbotMgr` — unchanged
- In-game group invite flow — unaffected (does not go through
`AddPlayerBot`)
- No new config keys, no schema changes, no API changes
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
Co-authored-by: Hokken <Hokken@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
||
|
Flashtate98
|
8f7d352f7e
|
Implement Auchenai Crypts Strategies and TBC Dungeon Contexts (#2229)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This PR aims to add bot strategies to the Auchenai Crypts dungeon,
specifically for the boss Shirrak the Dead Watcher, as his focus fire
mechanic is really annoying to deal with.
Additionally I have added TbcDungeonActionContext.h and
TbcDungeonTriggerContext.h for future reference as I add more strategies
to TBC dungeons that need it.
A HUGE thank you to @brighton-chi for all his help. This has been a fun
learning experience!
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
Trigger: A 20 yard radius grid search is performed to locate the focus
fire trigger NPC
Action: Bots will flee from the trigger NPC using MoveAway with a 5 yard
safety buffer
Multiplier: A for loop that prevents bots from running back into the
focus fire mechanic while its active.
Tanking: Tanks have a set coordinate to drag the boss to for the
duration of the fight.
- Describe the **processing cost** when this logic executes across many
bots.
Minimal, these scripts only execute when Shirrak has been engaged.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
Go into Auchenai Crypts (Normal or Heroic) and engage Shirrak the Dead
Watcher
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [X] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
This logic is only applied to Auchenai Crypts and activates during
Shirrak's encounter.
- Does this change modify default bot behavior?
- - [ ] No
- - [X] Yes (**explain why**)
Behavior only applies when in the instance and when engaged with
Shirrak.
- Does this change add new decision branches or increase maintenance
complexity?
- - [ ] No
- - [X] Yes (**explain below**)
New dungeon contexts were added (TbcDungeonActionContext and
TbcDungeonTriggerContext) to provide a clean and dedicated structure for
future TBC dungeon strategies that will be developed. This was done to
be in alignment with the existing WOTLK contexts that already exist.
## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
Does this change add bot messages to translate?
- - [X] No
- - [ ] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
| | |
| | |
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [X] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Gemini was used to help me understand existing code in the module I was
referencing and reusing to develop this strategy as I am not a
programmer and hardly know anything about C++.
## Final Checklist
- - [X] Stability is not compromised.
- - [ ] Performance impact is understood, tested, and acceptable.
- - [ ] Added logic complexity is justified and explained.
- - [ ] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
If there are any better alternatives that could be used to help improve
the strategy in any way, please suggest it. I am very new to this and
want to learn and improve.
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
|
||
|
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> |
||
|
kadeshar
|
e13aa7d2f6
|
IsTank fix for Death Knight (#2296)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description <!-- Describe what this change does and why it is needed --> Death Knights with Frost Presents are recognized by bots as tank Related with: #2290 ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> 1. Create Death Knight and apply Frost Presence 2. Invite Restoration Druid bot to party 3. Bot should apply "Thorns" on you ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Bots now identify Death Knight with Frost Presence as tank - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> Was AI assistance used while working on this change? - - [x] No - - [ ] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> <!-- TRANSLATIONS: Anything new that the bots say in chat must be in a translatable format. This is done using GetBotTextOrDefault, which you can search for in the codebase to find examples. Your code needs to have English as the default fallback, while the full translations need to be in an SQL update file. The languages in the file are the nine language options supported by AzerothCore: English, Korean, French, German, Chinese, Taiwanese, Spanish, Spanish Mexico, and Russian. See data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as an example of a translation SQL update, whose content are called within the codebase at src/strategy/actions/FishingAction.cpp --> ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Any new bot dialogue lines are translated. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> Example of non Blood Death Knight tank build https://forum.warmane.com/showthread.php?325582 |
||
|
bashermens
|
4bcf8fd2c4
|
Performance(Core): Some activity sec to ms init fixes, global activity loop check and some additional minor fixes (#2288)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
1. Corrected the init activity times; Since ive changed (previous) the
calc from seconds to ms to increase more scope for the offset execute
jitter (removed timer(), 0 is correct way todo now with MS) (also broke
self-bot)
2. Global loop checks in activityAllowed instead vs multiple loops, this
function is called very often so we better optimize it.
3 Fixed the broken 'HasManyPlayersNearby' function and then deleted it
:O To fragile due various edge cases and rather expensive call, besides
lets activeAlone deal with this situation which is way more controlled.
4. Some additional small fixes that where unnoticed overtime.
5. Added/Changed inline comments which makes more sense and explains
what it does.
6. Removed dead code freeze bots during init.
7. self-bot fix
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [x] Moderate impact (**explain below**)
When playing with larger amount of real players makes the allowed
activity perform better.
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [x] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
Benjamin Jackson
|
7b04c56956
|
Add default case to mount initialization for bots. (#2276)
## Pull Request Description <!-- Describe what this change does and why it is needed --> This PR adds a default case for the mount initialization function for player bots, allowing custom race additions to not crash when added to an AzerothCore server (such as [`mod-worgoblin`](https://github.com/heyitsbench/mod-worgoblin)). ## Feature Evaluation This feature ideally does not get touched in standard `mod-playerbots` usage, as it only adds a case to a switch statement, and would not be getting taken with Blizzlike data (which the vast majority of users likely use). ## How to Test the Changes 1. Add custom races to your AzerothCore instance (most easily accomplished with the above linked module). 2. Start the server and configure it to create random player bots (that fall under the added custom races). 3. Observe no crash. ## Impact Assessment - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [X] No, not at all - Does this change modify default bot behavior? - - [X] No - Does this change add new decision branches or increase maintenance complexity? - - [X] Yes (**explain below**) This does add another path in a switch statement. It also creates another set of data for that case. This could have been avoided by consolidating the human/orc cases into the default case, but I elected not to do that in case players make their own changes. If preferred, I can definitely consolidate the cases to not have those redundant data points. ## Messages to Translate - Does this change add bot messages to translate? - - [X] No ## AI Assistance - Was AI assistance used while working on this change? - - [X] No ## Final Checklist - - [X] Stability is not compromised. - - [X] Performance impact is understood, tested, and acceptable. - - [X] Added logic complexity is justified and explained. - - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers Pretty please? 🥹 --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> |
||
|
kadeshar
|
4c9b0adb72
|
Fire mage cc (#2281)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Added support for fire mage cc spells like: Dragon's Breath (disorient)
and Blast Wave (knockback)
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
1. Invite fire mage to party
2. Add strategy `nc +duel`
3. Start duel and go near bot
4. Bot should use frost nova/dragon's breath/blast wave depends of
cooldowns
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
Mages cc by default
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
- Does this change add bot messages to translate?
- - [x] No
- - [ ] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
| | |
| | |
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
- Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
OpenCode, for research differences between CcStrategy implementation
between cmangos and ac playerbots
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
Keleborn
|
ca54cff6f5
|
Bug fix. Edge case where bots would get stuck in cities. (#2269)
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
When I refactored flight destinations, I wanted to make where bots go
more intentional. so I made it dependent on the
allianceHubsPerLevelCache and hodeHubsPerLevelCache. This system relied
on there being an innkeeper in each area that the bots would fly to.
However, not every zone has an innkeeper, and so there was an odd
situation where bots had nowhere to fly to. (Most notably at level 53.)
This solves that by hardcoding the flightmasters in those areas into the
cache.
I also put back in the city teleport probability check which was forcing
every bot to teleport to a city on level up.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [x] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
## Messages to Translate
<!--
Bot messages have to be translatable, but you don't need to do the
translations here. You only need to make sure
the message is in a translatable format, and list in the table the
message_key and the default English message.
Search for GetBotTextOrDefault in the codebase for examples.
-->
- Does this change add bot messages to translate?
- - [x] No
- - [ ] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
| | |
| | |
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
- Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Debugging and comments.
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
|
||
|
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>
|
||
|
kadeshar
|
76dd91c4fa
|
Hand of Freedom support (#2233)
<!-- Thank you for contributing to mod-playerbots, please make sure that you... 1. Submit your PR to the test-staging branch, not master. 2. Read the guidelines below before submitting. 3. Don't delete parts of this template. DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND PREDICTABILITY over behavioral realism. Every action and decision executes PER BOT AND PER TRIGGER. Small increases in logic complexity scale poorly across thousands of bots and negatively affect all. We prioritize a stable system over a smarter one. Bots don't need to behave perfectly; believable behavior is the goal, not human simulation. Default behavior must be cheap in processing; expensive behavior must be opt-in. Before submitting, make sure your changes aligns with these principles. --> ## Pull Request Description Added Hand of Freedom action for paladin. Related with: #2002 ## How to Test the Changes <!-- - Step-by-step instructions to test the change. - Any required setup (e.g. multiple players, number of bots, specific configuration). - Expected behavior and how to verify it. --> - invite paladin bot to party - start fight (can use dummy target) - apply some snare effect to bot or yourself (for example `.aura 1715`) - bot should use hand of freedom ## Impact Assessment <!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. --> - Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots? - - [x] No, not at all - - [ ] Minimal impact (**explain below**) - - [ ] Moderate impact (**explain below**) - Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Yes, paladin bots start using Hand of Freedom - Does this change add new decision branches or increase maintenance complexity? - - [x] No - - [ ] Yes (**explain below**) ## Messages to Translate <!-- Bot messages have to be translatable, but you don't need to do the translations here. You only need to make sure the message is in a translatable format, and list in the table the message_key and the default English message. Search for GetBotTextOrDefault in the codebase for examples. --> - Does this change add bot messages to translate? - - [x] No - - [ ] Yes (**list messages in the table**) | Message key | Default message | | --------------- | ------------------ | | | | | | | ## AI Assistance <!-- AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. We expect contributors to be honest about what they do and do not understand. --> - Was AI assistance used while working on this change? - - [ ] No - - [x] Yes (**explain below**) <!-- If yes, please specify: - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation). - Which parts of the change were influenced or generated, and whether it was thoroughly reviewed. --> OpenCode, as helper to create and review code ## Final Checklist - - [x] Stability is not compromised. - - [x] Performance impact is understood, tested, and acceptable. - - [x] Added logic complexity is justified and explained. - - [x] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> <img width="424" height="93" alt="obraz" src="https://github.com/user-attachments/assets/3cac4454-35af-474d-8ea0-67c462973c79" /> |
||
|
Crow
|
79562be2e5
|
Fix Hunter Aspect Switching + Trigger Cleanups (#2203)
# Pull Request Note: When I reference Aspect of the Hawk below, it also means Aspect of the Dragonhawk (the code will use Dragonhawk if the Hunter has it, Hawk if not, they share actions, triggers, and strategies). Hunter Aspects are currently bugged. All Hunters, regardless of spec or strategy, are hardcoded to use Aspect of the Hawk when mana is at 70%+ and Aspect of the Viper when mana drops to "lowMana" from the config (default is 15%), divided by 2. This means the following: - Hawk (bdps) and Viper (bmana) strategies are useless - Pack (bspeed) and Wild (rnature) strategies are applied, but bots will rapidly switch back and forth between Pack/Wild and Hawk/Viper, depending on strategy and mana level. This PR addresses the issues by doing the following: - Global Hawk strategy is removed. Now you need to set bdps for Hunters to use Hawk, but bdps remains the default Aspect strategy for all Hunters. - Dedicated Viper strategy is removed, leaving the global strategy. However, Viper will be used (when lowMana/2) ONLY if the bot is set to bdps. If the bot has the Wild or Pack strategy, they will not switch to Viper at all. I did this because I am assuming if you are using Wild or Pack, you need them for reasons other than to pump DPS. - The threshold to switch back to Hawk is lowered from 70% to 60%. The gap between lowMana/2 and 60% is now filled--if bdps is on, Hunters will switch to Hawk whenever above the Viper threshold, _except_ for when they have the Viper aura, in which case they will not switch to Hawk until 60% mana. This lets the Hunter build back mana before swapping back to Hawk (more like general player behavior) while still letting them swap from other Aspects to Hawk without needing to be all the way at 60% mana. - Gets rid of a weird condition in the Hawk trigger that would make it so that Hunters would switch to Hawk when at exactly 0 mana. I'm not sure what the point of that is. Also, I refactored the triggers a bit because I noticed there was some dead code in there. I didn't do a comprehensive refactor, but there was a lot of stuff that clearly didn't make sense even to my eyes, like back-to-back returns. I think there's more unnecessary code even just in the triggers, but I didn't want to get too into the weeds with this PR. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? I don't expect there to be any impact on costs, and if anything this PR removes some unneeded checks from triggers. --- ## How to Test the Changes - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it The easiest way is to go shoot a dummy with Volley until low on mana and then toggle on selfbot. You can do this with various Aspects active to test. ## Complexity & Impact Does this change add new decision branches? - - [X] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [X] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [X] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [X] Yes (**explain why**) Described above. Default behavior is broken. If this introduces more advanced or AI-heavy logic: - - [X] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [X] Yes (**explain below**) I asked Claude some questions about the triggers to make sure I didn't screw anything up. If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Final Checklist - - [X] Stability is not compromised - - [X] Performance impact is understood, tested, and acceptable - - [X] Added logic complexity is justified and explained - - [X] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com> |
||
|
Crow
|
91eac70ca2
|
Implement Zul'Aman Strategies (#2186)
# Pull Request _Implement strategies for all bosses in Zul'Aman. See next post for overview of implemented strategies._ --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? _I have attempted to order checks while taking into account cost and likelihood and have opted to find lower-cost methods where possible. I have also not gone as in depth as I have with other strategies, partially because it is not necessary to complete encounters but also to try to limit the performance impact. From my observation, including with pmon, none of the methods should be overly taxing._ --- ## How to Test the Changes - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it _Run Zul'Aman. See next post for strategies to test._ ## Complexity & Impact Does this change add new decision branches? - - [ ] No - - [x] Yes (**explain below**) _Only in the context of raid strategies, with new methods to consider and new multipliers to evaluate when bots perform actions with the instance strategy active._ Does this change increase per-bot or per-tick processing? - - [ ] No - - [x] Yes (**describe and justify impact**) _The impact is only with the "zulaman" strategy active, which will be applied only in the instance. There is currently a PR open to also remove instance strategies when leaving the map to get rid of the residual performance impact._ Could this logic scale poorly under load? - - [ ] No - - [x] Yes (**explain why**) _Technically yes, but I think it is unlikely to have an appreciable difference unless there are many groups running the instance at the same time on a large server._ ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) _Only in the instance. It is a necessary trade-off to consider with raid strategies that I always keep in mind (degree of automation vs. player choice)._ If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable _Not exactly sure how to address this question in the context of this PR, but there aren't any techniques or methods for this strategy that I have not tried before (or something very similar)._ ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [x] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted _Gemini and GPT for some questions about the codebase and C++ and assistance with drafting a few things like containers that I find more tedious to do myself._ AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com> |
||
|
NoxMax
|
c7ac849fbe
|
Fix: Logout refactor and RNDbot logout error handling (#2131)
# Pull Request * Improper crash fix by 297f11d3e59f52a29f68188245e6b786c9fa838e. That fix worked not because setting `logout = true` stops the server from crashing, but because it stopped the following `if (!logout)` block from executing at all. In that block `delete target;` was the actual cause of the crashing and this was recreated in testing. `botWorldSessionPtr->LogoutPlayer(true);` already deleted target internally, then comes `delete target;` to delete already freed memory and the whole thing crashes. * Players had the ability to logout anyone's alt/addClass bots. Now there's a check to make sure command is from master. * When commanded to logout, RNDbots in player's party used to reply with "I'm logging out!", but they don't, because they shouldn't, because they are not alt/adClass bots. Now they say "You can't command me to logout!" * Added early exits for the "logout cancel" block, then I remembered bots were made to always instantly logout because of past issues with timed logout. Need to review whether or not we should re-implement timed logout, or if it's not worth it and its dead code removed with instant logout remaining the only option. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? This PR removes more code than it adds, and makes sure that exits happen as early as possible. It has no effect on processing power and makes the code slightly more maintainable. --- ## How to Test the Changes 1. Whisper `logout` to any bot whose master is not you. The bot can be RND/alt/addClass. The bot may have someone else as a master or may not have a master at all. The bot may be part of a party or not. Regardless, you are not its master. It should tell you "You are not my master!". Two players or two instances of the client from two different accounts are needed for this test, in order for Player A to command a bot to logout, when the bot's master is Player B. 2. Invite an RND bot to your party. As along as it's in your party, you are it's master, but RND bots cannot be logged out through chat commands. If you whisper `logout` to it, it should say "You can't command me to logout!", and not logout. 3. Whisper to an alt/addClass bot `logout`. The bot can be in your party or could've been uninvited. All that matters is that you are its master. It should reply "I'm logging out!" ## Complexity & Impact Does this change add new decision branches? - - [x] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [x] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [x] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) In that it fixes wrong behavior. If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [x] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [x] Yes (**explain below**) Used Claude for code review, and translations. If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Lines to Translate These are keys and defaults of lines that were added/edited, and to be translated at a later SQL update. | Key | Default line | | --- | --- | | bot_not_your_master | You are not my master! | | bot_rndbot_no_logout | You can't command me to logout! | --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. |
||
|
oskov
|
f160420d70
|
Fix/talent tree ordered map (#2222)
Fixes #2050 InitTalents builds a map of talentRow → [TalentEntry*] and iterates it to teach talents row by row. WoW's talent system requires each row to be filled before unlocking the next, so iteration must happen in ascending row order. Commit b474dc4 ("Performance optim") changed the container from std::map to std::unordered_map, which has no guaranteed key ordering. As a result, bots would frequently attempt to learn talents in a row whose prerequisites hadn't been met yet, silently skipping them. I belive it's the reason of #2050 issue. The fix is a one-character type change: restoring std::map<uint32, ...>, which guarantees ascending key (row) order. How to Test the Changes 1. Make fresh installation 2. Create new character 3. Observe talents tree of fresh rnd bots Was AI assistance used while working on this change? - [X] Yes — GitHub Copilot CLI was used to identify the root cause (unordered_map introduced in b474dc4 breaking talent row ordering), stage the one-line fix, and draft this PR description. The code change was reviewed and fully understood before submission. Root cause commit: b474dc44bb6323430a84fc17c1ec046f9919a101 ("Performance optim") — changed std::map to std::unordered_map in InitTalents, breaking the row-ordering guarantee that WoW's talent prerequisite system depends on. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
Crow
|
d5762b7e0f
|
Remove Vertical Speed Limit from Knockback Packet (#2223)
<!--
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
This PR removes the break from SMSG_MOVE_KNOCK_BACK for knockbacks with
vertical speed of >35.0f. This break is the reason for many vertical
knockbacks having no effect on bots, including Shade of Aran's Flame
Wreath, High Astromancer Solarian's Wrath of the Astromancer, and
Archimonde's Air Burst. There is a comment that indicates that the limit
was originally added due to bots getting stuck from high-speed vertical
knockbacks. I have not observed this at all and have been playing with
this break removed for several months.
## 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.
I honestly cannot say if there is impact on processing cost because I
have no understanding of packets. I would be surprised if there are any
performance issues since knockback packets are ordinarily getting sent
all the time, it's just a small number of moves that get skipped due to
this break.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
1. .go creature name High Astromancer Solarian
2. Start combat and wait until a bot gets hit with Wrath of the
Astromancer
3. Wait for the aura to expire and watch the bot fly to Mars and fall
back down
## 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**)
I do not know for sure, but as noted above, I would be surprised if
there was any notable performance impact.
- 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.
- [ ] Performance impact is understood, tested, and acceptable. <- I
can't say for sure, but I've not had any issues. I would appreciate
getting thoughts from somebody knowledgeable about packet use, however.
- [x] Added logic complexity is justified and explained.
- [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
Co-authored-by: kadeshar <kadeshar@gmail.com>
|
||
|
Keleborn
|
957eca0263
|
Feat. Enable multi node flying, and refactor into travel manager (#2156)
# Pull Request Feature - Enable multi node flying for bots - Bots currently only do node to node flying. This PR makes it so they can connect multiple noted. -- This is enabled by sending a vector containing the node sequence instead of a single destination node -- To minimize the run-time cost of searching for available nodes and connection, a cache of all possible connections is prepared at start up using a BFS search algorithm. Refactor - Move all world destination logic (cities, banks, inns) to existing Travel manager - Eliminate flightmastercache and integrate to new manager - replace SQLs calls with in-memory data search by core - Add in new map that stores creature areas by template. Clean up - Move other rpg files to related folder. (Next steps) The selection for where bots fly to should be smarter than it is. Instead of trying to determine where a bot can go, it should first decide where it should go, and then identify the correct way to get there. --- ## 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 - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it ## 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**) The call itself is fairly infrequent, and although now there are a greater number of paths available for the bots, I dont think it would be significant. ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [x] Yes (**explain below**) Gemini first suggested the use of a BFS algorithm. This was rewritten by me to actually work as intended. Verification by additional logging not present in final code. Claude code converted the SQL filtering to the atrocious if statements found in PrepareDestinationCache, but after verifying them it works. If there are better ways to do this Im open to it. --- ## 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. |
||
|
Aldori
|
4877dcc573
|
fix: ByteBufferException error (opcode: 149) (#2206)
Fixes #2204 ## Pull Request Description Fixes an opcode 149 ByteBufferException when Questie-335 (or other addons that send addon messages) is used in a party with Playerbots. The issue was caused by addon-language packets reaching parsing logic they should not have reached. This change adjusts the early return for `LANG_ADDON` packets before further handling. ## Feature Evaluation - Describe the **minimum logic** required to achieve the intended behavior. - Moved the early return for `LANG_ADDON` packets in the outgoing packet handler. - Describe the **processing cost** when this logic executes across many bots. - Negligible. It's a simple conditional check with an early return. ## How to Test the Changes 1. Install and enable Questie-335. 2. Invite at least 1 Playerbot to a party. 3. Accept a quest, abandon a quest, or progress a quest objective such as kill credit or looting a quest item. 4. Verify the worldserver no longer logs opcode 149 ByteBufferException errors. ## 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**) ## Messages to Translate Does this change add bot messages to translate? - [x] No - [ ] Yes (**list messages in the table**) | Message key | Default message | | --------------- | ------------------ | | | | | | | ## 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. - [ ] Documentation updated if needed (Conf comments, WiKi commands). ## Notes for Reviewers This is a small fix intended only to prevent addon language packets from reaching incompatible packet parsing logic. --------- 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> |
||
|
Crow
|
35a0282ca6
|
Add Sense Undead for Paladins (#2200)
# Pull Request This PR adds the sense undead ability for Paladins, which they will keep active at all times. This is mildly useful because the associated minor glyph provides a 1% damage increase against undead while the ability is active. Sense undead is also added to InitClassSpells(). I understand that it is a trainer spell so would normally be covered by InitAvailableSpells(), but those playing with mod-individual-progression will not receive the spell through InitAvailableSpells() because it is removed from trainers by the mod (in TBC, a quest was required to obtain the spell). Finally, the minor glyph of sense undead is now added to the config as a default glyph for all PvE specs. It is not added for PvP specs because Forsaken do not count as undead so the glyph is useless in PvP. I also made some other tweaks to Paladin default minor glyphs that are not worth spending any time talking about. Edit: I also did some minor reformatting of code and replaced some numbers with existing constants. --- ## 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? The implementation just checks if a Paladin has the sense undead aura, and if not, the Paladin will activate sense undead. It is simple and cheap. --- ## How to Test the Changes - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it ## 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**) Infinitesimally 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**) Paladin bots will by default have sense undead enabled. There is no disadvantage to this. 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: 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> |
||
|
XYUU
|
473b2ab5c6
|
Fix: WLK shaman totem quest vs relic totems: avoid keeping 4 totem items when relic exists #2119 (#2197)
## Summary * Detects shaman relics (relic type, totem subclass) in bags/equipment. * Skips adding the four classic totem items (5175–5178) when a relic exists. * Cleans up any existing totem items from bags/equipment/bank when a relic exists, while keeping Ankh handling intact. ## Test plan Verified manually (local environment). --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com> Co-authored-by: github-actions <github-actions@users.noreply.github.com> |
||
|
Keleborn
|
5e7613f719
|
Change reinterpret cast to dynamic cast. (#2182)
# Pull Request In a few instances the code used reinterpret cast. This is potentially risky if the object is incorrect. This is a safer approach. --- ## 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 - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it ## 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. |
||
|
kadeshar
|
a8dda550ad
|
Requirement fix to use bigobj parameter to compile (#2176)
# Pull Request Compilation fix which making possible compiling without bigobj parameter --- ## How to Test the Changes - compile using Visual Studio without bigobj parameter ## 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? - - [ ] No - - [x] Yes (**explain below**) Automate file creation --- ## 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 |
||
|
killerzwelch
|
660a5c0543
|
make playerbots compatible with 515aeca (#2181)
# Pull Request
needed changes for
|
||
|
Crow
|
14c77b1e7b
|
Remove instance strategies when leaving map (#2163)
# Pull Request Currently, dungeon and raid strategies, which are automatically added when entering the applicable instance (unless disabled in config), will persist until manually removed or until a different instance strategy is applied. This is pretty bad because then bots will continue to check triggers for the instance when outside of it. This has been discussed for a long time, but after finally considering it today, I think the solution is pretty simple because the existing framework is already there. PlayerbotAI::ApplyInstanceStrategies() is the function for enabling strategies when entering an instance, and it's called whenever a bot changes maps. So all we need to do is to remove all instance strategies first when calling it. I tested these changes, and they worked for me, but obviously others should test too, and especially the code should be examined since that is not my area of expertise. --- ## 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 - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it ## 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? - - [ ] No - - [x] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted 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. I used Gemini to verify that my idea would work and had it put together the actual code for me. --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> Co-authored-by: kadeshar <kadeshar@gmail.com> |
||
|
Hokken
|
788c7b025b
|
Fix quest links triggering trade window (#2155)
## Summary
`ChatHelper::parseable()` matched any hyperlink containing `|H`,
including quest links (`|Hquest:`), achievement links, spell links, etc.
This caused bots to interpret quest links shared in party chat as item
trade requests, opening the trade window instead of ignoring them.
Narrowed the check from `"|H"` to `"|Hitem:"` so only actual item links
trigger the parseable/trade logic.
**One-line change** in `src/Bot/Cmd/ChatHelper.cpp:603`
## Root Cause
The WoW client uses `|H<type>:<id>|h[Name]|h` hyperlinks for many object
types:
- `|Hitem:12345|h[Item Name]|h` — items
- `|Hquest:678|h[Quest Name]|h` — quests
- `|Hspell:890|h[Spell Name]|h` — spells
- `|Hachievement:...|h` — achievements
The old check `text.find("|H")` matched ALL of these, so sharing a quest
link in party chat would cause the bot to enter the item parsing/trade
flow.
## Test Scenarios
| Scenario | Before | After |
|----------|--------|-------|
| Share `[Quest Name]` in party chat | Trade window opens | No reaction
(correct) |
| Share `[Item Name]` in party chat | Trade window opens | Trade window
opens (unchanged) |
| Say "questitem" in chat | Parsed correctly | Parsed correctly
(unchanged) |
| Share `[Spell Name]` in party chat | Trade window opens | No reaction
(correct) |
Tested on AzerothCore 3.3.5a with mod-playerbots, confirmed fix resolves
the issue.
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Hokken <Hokken@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
|
||
|
Alex Dcnh
|
18bd655869
|
Restore Naxx Strategies without core dependencies (#2031)
### Summary This PR restores the Naxxramas raid strategies that were removed in commit 686fe513b25bbb20ccfcc89f08ee8c4b498a263e . The reintroduced logic is core‑friendly (no AzerothCore script headers or internal boss AI/EventMap dependencies), and the Naxxramas actions have been refactored into per‑boss files for better maintainability. ### Motivation The previous removal was meant to avoid core modifications and unblock upstreaming. This PR brings the strategies back while adhering to that requirement, using only observable state and mod‑playerbots helpers. ### What’s included - Re‑enabled the Naxxramas strategies previously removed. - Replaced core script header dependencies with observable checks (auras, casts, unit flags, flight state, etc.). - Split the Naxxramas action logic into per‑boss source files to avoid a “god file” and ease future maintenance. - Minor, non‑intrusive behavior improvements aligned with existing helpers. ### Future work Some strategies may still require refinement or more advanced handling later. This PR focuses on restoring the baseline logic without core dependencies, while keeping changes minimal and safe. **Any contributions are welcome to further improve and fine‑tune the Naxxramas strategies.** ### Testing Tested in some Naxx boxx. No server crash and boss killed :D Note: I'll make another PR with revised scripts when this one are merged --------- 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> |
||
|
Keleborn
|
439293e100
|
Warnings PR 2 clean unused variables (#2107)
# Pull Request
Removed unused variables and fixed styling issues.
## How to Test the Changes
- Step-by-step instructions to test the change
- Any required setup (e.g. multiple players, bots, specific
configuration)
- Expected behavior and how to verify it
## 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:
- [ ] Lightweight mode remains the default
- [ ] More complex behavior is optional and thereby configurable
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [x] No
- [ ] Yes (**explain below**)
---
## Final Checklist
- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [x] Added logic complexity is justified and explained
- [x] Documentation updated if needed
---
## Notes for Reviewers
This was filtered from the code provided by SmashingQuasar. Eliminated
variables were confirmed to be not used, but unclear at times if that is
due to mistakes in writing.
---------
Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
|
||
|
Crow
|
be2cf436ea
|
Implement Tempest Keep: The Eye Strategies (#1943)
Edit: Descriptions of methods are out of date right now. To be updated. This one comes with the same caveats as SSC about requiring ownership from somebody with C++ knowledge, except I think the matter is even more acute here because these strategies incorporate a novel approach proposed by Timberpoes. By redeclaring the entire bossai class for Kael’thas, it was possible to add new member functions to the class in order to access its private member variables. This allows bots to have visibility into boss mechanics beyond what they could do with ordinary techniques and is similar in approach to what was done by the Naxx strategies, except that this approach does not require any modifications to the core. I used it for only one mechanic, which was to detect Kael’thas’s phase. That was very helpful because the fight is divided into 5 phases, and distinguishing between them with traditional techniques requires lookups of a dozen NPCs and comparisons of their various unit states, react states, and auras; by accessing his bossai, this can all be avoided. However, there is far more potential beyond this if the approach is an acceptable one. On with the (shit)show. ### Trash In a perfect world, there would be many strategies for TK trash, which is easily more difficult than two of the bosses. It’s a real pain to do though because to solve the biggest issues properly, each pack would have to be handled a little differently. So the only thing I’ve included is for Mages to cast polymorph on the Crimson Hand Centurions when they are channeling Arcane Flurry. The purpose is not to actually keep them CC’d but to interrupt their channel. ### Al’ar This fight sucked so much to write a strategy for. The only silver lining is that being the post-nerf version, the boss moves between only 4 platform locations (instead of 6), and movement between them is on a fixed rotation (interrupted by Flame Quills) instead of being random. Thus, a strategy can be consistently replicated, and the fight can be done with only 3 tanks (2 on the platforms for the boss and 1 below for adds). **Phase 1:** I’m going to call the platform that Al’ar lands at after the pull “platform 0” because that reflects the indices in the code. In a clockwise direction, the remaining platforms will be referred to as platforms 1, 2, and 3, respectively. The best way to pull is to first put all ranged, as well as tanks other than your main tank and first assistant tank, on nc +stay below platform 0. Then, go up the ramp to platform 0 with your main tank, first assistant tank, and melee dps following you, then hit Al’ar with any ranged attack or spell to start the fight. - Your main tank will start at platform 0, and your first assistant tank will immediately move to platform 1. When Al’ar moves to platform 1, your main tank will move to platform 2. When Al’ar moves to platform 2, your first assistant tank will move to platform 3. When Al’ar moves to platform 3, your main tank will move back to platform 0. This assures a tank is available to receive Al’ar after every platform movement (every 30 seconds). - Melee DPS will follow Al’ar as it moves between platforms. - Each platform is mapped to a corresponding ground location below it. Ranged DPS and healers will follow Al’ar by moving to the corresponding ground location as it flies between platforms. - After each platform move, an Ember of Al’ar will spawn. Your second assistant tank will pick up the Ember and move it to the point that is 25 yards away from the ground position corresponding to Al’ar’s platform (on an invisible line between such ground position and the middle of the room). Ranged DPS will then focus down the Ember before switching back to Al’ar (this positioning is so that ranged are not hit by the Ember Blast explosion that happens whenever an Ember dies). - Each time Al’ar leaves a platform, it has a chance to instead fly up high in the middle of the room to perform Flame Quills, which will one-shot anybody on the upper level or ramps. When Al’ar begins the Flame Quills sequence, all bots on the top level will jump off. FYI, Al’ar’s usage of Flame Quills is not entirely random: there is a 20% chance for it to do so after the first platform move, and the chance increases by another 20% after each subsequent platform move that does not trigger Flame Quills (reset after each Flame Quills sequence). - After Flame Quills, Al’ar will randomly land at either platform 0 or 3. To prepare for this, bots will move to assigned positions during the Flame Quills sequence: - Ranged and the second assistant tank will wait in the middle of the room. - Melee DPS will wait at a point that is between the base of each ramp. - The main tank will wait at the base of the ramp to platform 0. - The first assistant tank will wait at the base of the ramp to platform 3. - Once Al’ar lands, the regular Phase 1 strategies resume. - When Al’ar “dies,” it disappears and moves to the center of the room, where it casts Rebirth and returns to full HP. Bots will wait outside of the radius of the Rebirth explosion for Phase 2 to start. Phase 2: - Your main tank will tank Al’ar initially. When Al’ar casts Melt Armor, your first assistant tank will taunt Al’ar and take over. The tank swaps will continue back and forth every time Melt Armor is cast. - Bots will avoid Flame Patches. FWIW, the standard co +avoid aoe strategy does work for Flame Patches, but avoid aoe provides no buffer distance so as you’ve probably noticed, it doesn’t provide for preemptive avoidance. Also, avoid aoe does not consider multiple hazards together so it can be an issue when movement needs to take into account more than one hazard, plus when a strategy requires particular bot movement, it’s better to account for the hazards within that movement strategy instead of relying on separate methods that can create conflicts. - When Al’ar takes to the sky to perform Dive Bomb, bots will spread out (and continue to avoid Flame Patches). After the Dive Bomb, Al’ar does another Rebirth explosion. I have tried a million different things to properly detect this full sequence (even accessing the bossAI like I did with Kael’thas) and cannot get it to work properly. Ultimately, all I’ve been able to get to work at all with respect to the final explosion is for bots to detect the 2-second cast of the Rebirth and run out. It is not enough time for bots that are too close when the cast happens so some bots may get hit, but if you have adequate gear, they should survive. - After each Dive Bomb, 2 Embers will spawn. Your second assistant tank will tank one Ember, and either the main tank or first assistant tank, whichever one is not tanking Al’ar at the time, will tank the other Ember. They will both move the Embers away from bots, and ranged DPS will focus both Embers down before switching back to Al’ar. - Because the room is so large, it is possible for bots to get too far away from active combat (particularly if they are thrown across the room by Ember Blast) so there is also a method for them to run back toward the center if they get too far away. ### Void Reaver Ironically, what was often considered the easiest boss in 25-player content in TBC is the only boss with an ability (Arcane Orb) that I do not believe can be avoided by bots, even with access to Void Reaver’s boss script. Therefore, every single Arcane Orb is going to hit its target, so the strategy can only try to limit the damage by spreading ranged bots in two rings around Void Reaver (one for healers and one for ranged DPS, to try to ensure sufficient distribution of healers). The tanks will all fight for aggro (necessary due to Knock Away) and try to keep Void Reaver in the middle of the room. Bots that can wipe aggro or otherwise gain invulnerability are directed to use the applicable abilities as soon as they pick up aggro (e.g., Soulshatter). He’s still easy, but if you have IP nerfs, it’s a little bit of a gear check. ### High Astromancer Solarian No boss was hit harder by nerfs in TBC than Solarian, whose encounter went from a totally unique fight that required arcane resistance to a fight that is kind of just an easier Baron Geddon. IMO, she is the easiest boss in TBC 25-player raids. - Ranged bots stack up at a distance from Solarian; this leaves all bots with plenty of space to run away from other bots when they get Wrath of the Astromancer. - When Solarian vanishes, all bots will stack to AoE down the Solarium Agents that spawn. - When Solarian returns with two Solarium Priests, melee will divide into two groups, with one focused on each Solarium Priest. I think this method is not working correctly right now because when one Priest dies, the bots still on the second Priest are leaving it. I’ll need to decide whether I want to figure it out or just get rid of it because this fight is so easy regardless. - Priest bots will cast Fear Ward on the main tank to block the Psychic Scream during the final tank-and-spank Voidwalker phase, and the main tank will pick up Voidwalker Solarian as soon as she transforms. Note that the bots will not be knocked into the air by Wrath of the Astromancer. The issue is due to the presence of a check for knockbacks in Playerbots that causes bots to ignore knockbacks that would launch them at a velocity beyond a hardcoded value. I’ve increased that velocity limit on my own fork, and it does allow Wrath of the Astromancer (and other knockbacks that otherwise don’t work) to work on bots. But that’s obviously a broader issue and not addressed in this PR, and bots don’t take fall damage in any case. ### Kael’thas Sunstrider So this strategy has 23(!) action methods. But like in retail, this is actually an easy fight once it is learned because it is highly scripted. Unlike in other strategies I’ve done, the bots probably cannot do this fight by themselves unless they are way overgeared. This is because there are a few windows during which bots need to position themselves properly based on dynamic factors. But no RTSC is needed—you just need to have bots follow you to the right locations. Also note that the gear check for this strategy is higher than in retail because you have to get all of the legendary weapons down and looted before the advisors aggro in Phase 3, or it’s going to be an absolute shitshow (with human players, you can deal with there still being a couple of weapons up). For a point of reference, when I was first working on this strategy with damage reduced to 50% and bots pretty close to T4 BiS, I had almost no margin of error (I would usually get the weapons down with barely a second to spare). You will need at least 2 tanks, but 3 is better. Your main tank will need to be able to equip the legendary shield so you must use a Warrior or Paladin. However, it is ideal for the first assistant tank to be a Druid because they can equip the legendary staff. **Phase 1:** Fun fact—when you “kill” the advisors in this phase, they don’t actually die but get an aura applied called “Permanent Feign Death” (nice oxymoron). - _Thaladred_: You’re supposed to kite him, and bots can’t really kite, so the method is a poor man’s method of having the bot move away from him in a straight line when fixated. You want him to die in the far Southern part of the room. If he dies in a bad location, you may as well call a wipe and restart. What will work best for you will depend on your DPS since you don’t want to kill him before he gets to the location you want but also don’t want bots to be trapped up against a wall since they can’t properly kite him. The way that works best for me is to have bots stay back while I aggro the boss, and wait until right before Thaladred switches to his second fixate target before attacking. Note that if you do put bots on stay, when you put them back on follow, the bot that is then being fixated will remain on stay (because they need to disregard movement orders other than running away from Thaladred). So after Thaladred dies, make sure to manually type /follow or the bot that was fixated when you took the bots off of stay will not rejoin the fight. - _Sanguinar_: He will be tanked by your main tank, who will be targeted by your Priests for Fear Ward. Bots will wait to engage him; I made it a very generous time (12 seconds) because there is absolutely no rush in Phase 1. There’s no sense in being aggressive. During that time, the main tank will drag Sanguinar to the West wall. - _Capernian_: This is the first make-or-break part of the fight. Phase 1 Capernian was the most frequent cause for wipes for me. - She should be tanked by a Warlock. If you want to pick your Warlock tank, you can do so by the assistant flag, but if you don’t, the strategy will just pick your highest HP Warlock. If you raid without a Warlock, then you’re insane, but at least there’s a guard so your server won’t crash? - You do not need to add the tank strategy to your Warlock. There is a method that will automatically switch your selected tank Warlock between DPS and tank strategies at appropriate times because you need to squeeze out every drop of DPS you can get, particularly for Phase 2, where you’ll need your Warlock to be blowing up weapons with Seed of Corruption instead of spamming Searing Pain. You’ll want your Warlock to start with a DPS strategy as usual (since they should be DPSing Thaladred). - To engage Capernian, start running East right before Sanguinar dies. She will activate quickly, and you want to try to get in front of her (but not too close) before she aggros. - When Capernian aggros, your Warlock tank will immediately switch to the tank strategy and attack. Your main tank will run toward Capernian but not actually attack; their purpose will be to bait her Conflagration to reduce the chance that it hits your Warlock tank. Other melee will not engage Capernian. Ranged DPS will be idle for 12 seconds; during this time, you should run South to make sure they are not in range of Capernian. After 12 seconds, your ranged DPS will activate, move into range and spread out, and attack (it doesn’t seem possible to outrange Conflagrate, so if bots don’t spread, she will annihilate the entire ranged group with a single cast). Ideally, you kill her not too far from her starting position. If she ends up in the middle of the room, you should probably wipe and start over. - _Telonicus_: He is very easy in retail but actually is a big risk for wipes with respect to bots because his bombs will one-shot any non-tank, and bots will stupidly stand in front of him without a proper strategy. You should keep some distance from him before he aggros. Your first assistant tank will pick him up and move him to the West wall near Sanguinar. Again, there is a 12-second delay before DPS starts. Your melee DPS are coded to stay directly behind him and not get too close so they don’t get hit by bombs. **Phase 2:** Kael’thas will summon all weapons immediately after Telonicus is down. Just before Telonicus is down, you should move to the platform where the advisors originally were—you’ll be in better position for the raid to AoE down the weapons. - Your main tank will pick up the axe and move it away from the group. The axe is the biggest threat during this phase and can easily one-shot casters if not pulled away. - One of your Hunters will attempt to get aggro on the bow and move away from the group (as a hacky way of trying to turn the bow away from the group because you can’t really get a bot to do that directly). This method is hit or miss, but it shouldn’t be that big of a deal if your Hunter doesn’t pull it off properly. - Everybody else will prioritize weapons in the following order (but most damage will come from AoE, which is what you want or you will not beat the timer): staff, mace, sword, dagger, axe (ranged only), bow, and shield. - As weapons are defeated, bots will loot and equip them. If you have not disabled bot announcements in your config, you get to see your entire raid go nuts because they looted legendary items. - Here is what weapons bots will loot and equip. I don't know anything about DKs, having never played WotLK, so tell me if anything is wrong for them. - _Healers:_ Mace (if a healer normally uses a staff, it's best if they keep an OH in their bags for this fight) - _Tanks:_ Shield and sword for Paladins and DK, shield and dagger for warriors, staff for Druid - _Offensive_ casters: Staff - _Rogues:_ Sword and dagger if Combat or Subtlety, dagger only if Assassination - _DPS Death Knights, Retribution Paladins, Arms Warriors_: Axe - _Fury Warriors_: Dagger. I understand that due to Titan Grip, they should also have the Axe for best DPS; however, Fury Warriors have awful DPS (we’re talking barely above Prot-level) at this stage. Thus, my view is it is better to give them only the dagger so they will MH it and help break MC in Phase 4, since they will contribute hardly any DPS regardless. - _Cat Druids_: Staff - _Enhancement Shamans_: Dagger - _Hunters:_ Bow and dagger. Note that I do NOT have them loot the sword because they need the dagger in their mainhand to use to break MC in Phase 4; whatever marginal benefit they get from the sword as a stat stick is not worth losing this capability. If your Hunter uses a 2H, it is best to have them carry a 1H in their inventory so they can put something in the OH after they equip the dagger. - After looting weapons, bots with the staff will use it (once) to activate the Mental Protection Field. Hunters will use the bow to generate the legendary arrows and equip those (and will continue to do so during the fight if they use up the arrows). - If you wipe from this point forward, everybody will lose their legendary weapons, and by default, most bots will not automatically reequip their own weapons until a loot event occurs. This was extremely annoying, and therefore there is a noncombat method implemented that causes everybody to equip upgrades when they get within 150 yards of Kael’thas. I considered applying this to the whole instance, but I’m not sure if some people would not like that so I decided to limit things to the Kael’thas encounter. **Phase 3:** I highly recommend you have your Shamans drop Tremor Totems (co +tremor) during this phase. Doing so is not coded because I wanted to leave flexibility, but I think it is very helpful for Sanguinar. After the weapons die, you want to move your bots to a central location between the advisors. If Thaladred died closer to the middle of the room, ideally you position to the side of Thaladred so when he fixates he will not chase bots North into the other advisors. - Shamans will immediately use Heroism/Bloodlust. - Your melee tanks will bring Sanguinar and Telonicus to their tanking positions (same as Phase 1). If your first assistant tank is a Druid, they will be immune to Telonicus’s Remote Toy due to having the legendary staff’s aura activated and will also make your main tank immune. - One healer will stay by the Sanguinar and Telonicus tanking positions to heal the tanks. Once IsHealAssistantOfIndex() is fixed, you will be able to select this healer with the assistant flag. Right now, this will just be the last healer that joined your raid (per standard AC logic). - DPS priority will be Thaladred, Capernian (ranged only), Sanguinar, Telonicus. As with retail, the most chaotic period will be before Thaladred is killed, particularly if he chases bots into other advisors. I don’t have a great solution for this, but Capernian is significantly less dangerous during this phase thanks to the legendary staff. This is the last true breakpoint—if you get Thaladred down with your raid mostly intact, you are very likely to get the kill. **Phase 4:** Kael’thas will aggro immediately after all advisors are dead. - Your main tank will position Kael’thas at his original position. - Bots will move out of Flame Strikes. - Assist tanks will pick up Phoenixes. Since they die over time anyway, bots will not waste time attacking them. When Phoenixes die, they turn into an Egg—at that point, bots will switch to the Egg to destroy it before the Phoenix is reborn. - When Kael’thas puts up Shock Barrier and starts casting Pyroblast on your main tank (a one-shot), all bots will focus DPS on him (even if there is an egg up). You have 4 seconds to break the barrier (80K HP) and interrupt his Pyroblast. It is likely that you will not be able to if you are playing with IP nerfs and are in T4 gear. However, the main tank will use the legendary shield’s ability, which will allow them to absorb one cast, giving you 8 seconds to break the barrier and interrupt Pyroblast. Bots will put top priority on interrupting Pyroblast as soon as the barrier is down. - If a bot (or player) is mind controlled, bots with the legendary dagger (other than tanks) will move to MC’d players and use the following attacks to break MC: Shiv (Rogues), Hamstring (Warriors), Wing Clip (Hunters), and Stormstrike (Shamans). **Phase 5:** At 50% HP, Kael’thas enters a long RP sequence. This is a good time to kill any remaining Phoenixes and/or Eggs. - Kael’thas stops casting Pyroblast and Mind Control. - His main new ability is Gravity Lapse, and it doesn’t work properly on bots... He sucks in the entire raid then knocks everybody back in a different direction. What is supposed to happen is that players will end up floating in midair in different directions and at different heights. However, bots will immediately fall to the ground after getting knocked back. They will not actually hit the ground though and instead remain in a flying state right above the floor. - If you could move in 3D space, Netherbeam would be very easy to deal with. However, because that is not available to bots, they can spread only in 2D space and thus need to move farther to get properly spread, and they waste the first moments falling straight down. As a result, the damage from Netherbeam can be quite high, and the beginning of Gravity Lapse requires a lot of healing. I don’t really have a better way of dealing with this. - FWIW, I don’t think there is any existing method to make bots disperse in 3D anyway. - Kael’thas is supposed to use Nether Void when players are in midair, which creates clouds that reduce your max HP and thus make it more challenging to maneuver, but AC is bugged and he doesn’t use the ability at all (there’s been an open issue about this forever). For fuck's sake, that's all. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com> |
||
|
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. |
||
|
Keleborn
|
441f9f7552
|
Warnings PR 1: Event warnings and headers (#2106)
# Pull Request
This is the first in a series of PRs intended to eliminate warnings in
the module. The design intent is to eliminate the calling event when not
needed in the body of the function. Based off of SmashingQuasars work.
---
## How to Test the Changes
- Step-by-step instructions to test the change
- Any required setup (e.g. multiple players, bots, specific
configuration)
- Expected behavior and how to verify it
## 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:
- [ ] Lightweight mode remains the default
- [ ] More complex behavior is optional and thereby configurable
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [x] No
- [ ] Yes (**explain below**)
---
## Final Checklist
- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [x] Added logic complexity is justified and explained
- [x] Documentation updated if needed
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
---------
Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
|
||
|
Alex Dcnh
|
17b8d7f68b
|
Stage1 refactor world position method names (#2126)
# Pull Request This change replaces the non‑standard WorldPosition::getX/getY/getZ/getO/getMapId wrappers with the core getters (GetPositionX/Y/Z, GetOrientation, GetMapId) and removes the redundant wrappers. Goal: align the module with AzerothCore conventions, reduce local adapters, and improve long‑term maintainability. --- ## Design Philosophy This is a structural cleanup only (coordinate access) and does not alter any AI behavior or decision logic. It follows the stability/performance-first philosophy and does not add branches or extra runtime work. Before submitting: yes, this change aligns with the principles of stability, performance, and predictability. 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: - Minimum logic required: use core getters (GetPositionX/Y/Z, GetMapId, GetOrientation) wherever coordinates are needed. - Cheapest implementation: direct call replacement and removal of redundant wrappers. - Runtime cost: negligible (same data access, no additional logic). --- ## How to Test the Changes - No functional testing required (behavior‑neutral refactor). - Recommended: compile the module and run a normal server startup as validation. ## Complexity & Impact Does this change add new decision branches? - - [x] 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? - - [x] No - - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [x] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [x] Yes (**explain below**) If yes, please specify: - AI tool or model used: Copilot - Purpose of usage: Translate this PR text from french to English --- ## 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 This is a core-friendly cleanup only, with no behavioral change. No additional logic or CPU cost is introduced. |
||
|
privatecore
|
a0a50204ec
|
Fix action validation checks: isUseful -> isPossible + codestyle fixes and corrections (#2125)
# Pull Request Fix the incorrect logic flaw when processing actions from different sources. It should be: `isUseful` -> `isPossible`. The original logic is based on the Mangosbot code and the impl presented inside `Engine::DoNextAction`. This should fix all wrong validation orders for triggers and direct/specific actions. Code style is based on the AzerothCore style guide + clang-format. --- ## 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 - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it ## 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: - - [ ] 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. |
||
|
Keleborn
|
80b3823f12
|
Warnings PR 3, remove std::move when not necessary. (#2108)
# Pull Request
std::move was being used in a few places to return a vector. Its not
necessary. A direct return allows for some optimizations that moving
wouldnt.
## How to Test the Changes
-Bots should initialize correctly
## 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**)
---
## Final Checklist
- [ ] 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
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>
|