mirror of
https://github.com/liyunfan1223/mod-playerbots.git
synced 2026-06-20 15:39:25 +02:00
a76f2ca268
<!--
Thank you for contributing to mod-playerbots, please make sure that
you...
1. Submit your PR to the test-staging branch, not master.
2. Read the guidelines below before submitting.
3. Don't delete parts of this template.
DESIGN PHILOSOPHY: We prioritize STABILITY, PERFORMANCE, AND
PREDICTABILITY over behavioral realism.
Every action and decision executes PER BOT AND PER TRIGGER. Small
increases in logic complexity scale
poorly across thousands of bots and negatively affect all. We prioritize
a stable system over a smarter
one. Bots don't need to behave perfectly; believable behavior is the
goal, not human simulation.
Default behavior must be cheap in processing; expensive behavior must be
opt-in.
Before submitting, make sure your changes aligns with these principles.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
This is a PR to follow-up on a discussion with @kadeshar during the
recent mage armor PR. Main changes:
- Add new PlayerbotAI::HasSpell() overload that accepts a string for the
spell name as an argument, in order to replace repeated
bot->HasSpell(spellId) checks for places where multiple ranks of a spell
are checked, and to replace a few calls to AI_VALUE(uint32, "spell id",
...) where it existed only to check for the spell being known.
- Removed PlayerbotAI::HasAura() overload that takes a spell Id as an
argument. It is rarely used, and the few instances of its usage are
easily replaced with AC's Unit::HasAura(), which is the predominant
usage for spell Id aura checks already anyway.
- When modifying DruidPullStrategy to use the new HasSpell() method, I
went ahead and also simplified the file overall to pare down duplication
(for example, the first check in CanCastSpell is for the spell Id so we
don't need to separately check it before calling CanCastSpell()). I then
did the same for other pull strategies so they can be consistent.
- Changed many magic numbers for spell Ids to be defined as compile-time
constants. I didn't do this throughout the code, but I did in the files
where I was making changes anyway due to the HasSpell() and/or HasAura()
changes.
## 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.
- Minimum logic is described above.
- Processing cost shouldn't change much. See Impact Assessment below.
## 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**)
- Passing a string for the spell to check for it being known or the aura
being present is more taxing than looking up a spell Id, although the
usefulness of the string-based overload is for situations with spells
that have multiple ranks.
- Does this change modify default bot behavior?
- - [x] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [x] No
- - [ ] Yes (**explain below**)
- I think these changes should simplify maintenance complexity.
## 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 AI make many of the changes and then review since they were
pretty mundane (for example, I'd tell it to just take all the magic
numbers from a file and define them in an anonymous namespace, then
replace the magic numbers with the spell constants). There isn't
anything complicated in this PR; it was mostly busywork.
<!--
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.
-->