## Pull Request Description
Undead and Draenei bots get stuck in an idle/rest loop in their starting
zones because the default NPC scan range (150f) and quest giver filter
(80f) are too small and not enough. NPCs fall within range for
`WANDER_NPC` to activate (requires >= 3).
This adds a configurable area-based override that increases both ranges
to 200f only in affected areas. All other zones remain at default
values.
## Feature Evaluation
- **Minimum logic**: One `std::set::count()` lookup per `Calculate()`
call to check if the bot's current area is in the override list. If yes,
scan range is 200f instead of 150f.
- **Processing cost**: `GetAreaId()` is a cached uint32 read (~1ns).
`std::set::count()` on a 2-element set is O(log n) ≈ 1 comparison.
Negligible compared to the grid scan itself (~33,000-53,000ns).
## How to Test the Changes
1. Create Undead or Draenei bots (level 1)
2. Observe that they pick up quests and start moving in Deathknell/Ammen
Vale
3. Without this fix, they sit in REST status indefinitely
4. Optionally add/remove area IDs via
`AiPlayerbot.RpgScanRangeOverrideAreaIds` in playerbots.conf
## Impact Assessment
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- [x] Minimal impact
- pmon data (500 bots, extended run):
- Default 150f: 0.033ms avg
- Global 200f: 0.053ms avg
- Area check (this PR): 0.042ms avg
- The 0.009ms increase over default is caused by bots currently in
starting zones scanning at 200f. Bots outside override areas are
unaffected.
- Does this change modify default bot behavior?
- [x] No
- Does this change add new decision branches or increase maintenance
complexity?
- [x] No
- Uses the existing `LoadSet`/`std::set` config pattern already used
throughout the codebase.
## AI Assistance
- [x] Yes
- Used AI to speed up understanding the codebase, locate relevant
functions, and compare with the cmangos playerbots implementation. All
code was reviewed and tested manually.
## 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
The root cause is that `WANDER_NPC` requires `possibleTargets.size() >=
3`, but sparse starting zones have fewer than 3 NPC-flagged units within
150f. Increasing the scan range to 200f brings enough NPCs into range
for the status check to pass. The override is configurable via
`AiPlayerbot.RpgScanRangeOverrideAreaIds` so server admins can add more
areas without code changes.
# 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>
# 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>
# Pull Request
- Applies the clean and corrected singletons, Meyer pattern. (cherry
picked from @SmashingQuasar )
Testing by just playing the game in various ways. Been tested by myself
@Celandriel and @SmashingQuasar
---
## Complexity & Impact
- Does this change add new decision branches?
- [x] No
- [ ] Yes (**explain below**)
- Does this change increase per-bot or per-tick processing?
- [x] No
- [ ] Yes (**describe and justify impact**)
- Could this logic scale poorly under load?
- [x] No
- [ ] Yes (**explain why**)
---
## Defaults & Configuration
- Does this change modify default bot behavior?
- [x] No
- [ ] Yes (**explain why**)
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [x] No
- [ ] Yes (**explain below**)
---
## Final Checklist
- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [x] Added logic complexity is justified and explained
- [x] Documentation updated if needed
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
---------
Co-authored-by: Nicolas Lebacq <nicolas.cordier@outlook.com>
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Needs second pair of eyes, they appear in crash logs here and there. Its
merely a patch on a open wound.
----
As in aslong there multithreads in mapupdate, which we need for decent
performance and core calls are not done correctly due various reasons.
These type of issues remain.
Although i am planning to experiment a little with threadsafe execution
of our strategies vs performance.
The most effective thing we could do is check every single action and
check its stateless and where it does effect the state or read the state
of a core object its done in the safest way. flags, worldthread where
possible and/ot simply taking into account the state might be invalid.
