Open
Conversation
Summary of ChangesHello @Celandriel, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a complete and intelligent strategy for player bots to navigate and effectively participate in the Ahn'Qiraj 40-man raid. It provides the necessary framework for bots to understand and react to the unique mechanics of various boss encounters, from managing resistance buffs and positioning to prioritizing targets and executing specific actions, significantly enhancing their raid performance and utility. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds AI strategies for the AQ40 raid, along with several other raids. While the core logic for the new strategies is a good starting point, there are several critical issues that need to be addressed, including memory leaks, potential crashes from incorrect return values, and improper class inheritance. I've also pointed out some areas for improvement in code style and maintainability, such as removing duplicate code, replacing magic numbers with constants, and using safer type casting and object initialization.
src/Ai/Raid/Aq40/RaidAq40Actions.h
Outdated
| Aq40AttackTargetByNameAction(PlayerbotAI* botAI, std::string const name) : AttackAction(botAI, name) {} | ||
| bool Execute(Event event) override; | ||
|
|
||
| virtual std::string const WhichEmperor() { return NULL; } |
There was a problem hiding this comment.
Returning NULL from a function that returns a std::string const will likely cause a crash due to constructing a string from a null pointer. This function should return an empty string "" or std::string() instead.
Suggested change
| virtual std::string const WhichEmperor() { return NULL; } | |
| virtual std::string const WhichEmperor() { return ""; } |
src/Ai/Raid/Aq40/RaidAq40Actions.h
Outdated
Comment on lines
+85
to
+94
| class Aq40MoveTowardsEmperorVekLorAction : Aq40MoveTowardsEmperorAction | ||
| { | ||
| public: | ||
| Aq40MoveTowardsEmperorVekLorAction(PlayerbotAI* botAI) | ||
| : Aq40MoveTowardsEmperorAction(botAI, "aq40 move towards emperor vek'lor") {} | ||
|
|
||
| std::string const WhichEmperor() override { return "emperor vek'lor"; } | ||
| }; | ||
|
|
||
| class Aq40MoveTowardsEmperorVekNilashAction : Aq40MoveTowardsEmperorAction |
There was a problem hiding this comment.
The classes Aq40MoveTowardsEmperorVekLorAction and Aq40MoveTowardsEmperorVekNilashAction are missing the public access specifier for their inheritance. In C++, class inheritance is private by default, which prevents polymorphic behavior (like upcasting to the base class Action*). This is likely not the intended behavior and will cause issues. Please add public.
class Aq40MoveTowardsEmperorVekLorAction : public Aq40MoveTowardsEmperorAction
{
public:
Aq40MoveTowardsEmperorVekLorAction(PlayerbotAI* botAI)
: Aq40MoveTowardsEmperorAction(botAI, "aq40 move towards emperor vek'lor") {}
std::string const WhichEmperor() override { return "emperor vek'lor"; }
};
class Aq40MoveTowardsEmperorVekNilashAction : public Aq40MoveTowardsEmperorAction
src/Ai/Raid/Aq40/RaidAq40Actions.h
Outdated
Comment on lines
+25
to
+26
| const Position* torch_left = new Position(-8894.3, 1285.5, -112.25); | ||
| const Position* torch_right = new Position(-9029.1, 1261.8, -112.25); |
There was a problem hiding this comment.
These members are initialized with new, but there is no corresponding delete in a destructor. This will cause a memory leak. Since these positions are constant, consider making them static const Position objects instead of pointers to avoid dynamic allocation.
Comment on lines
+128
to
+167
| for (int n = 0; n < outerpointscount; n++) | ||
| { | ||
| Position* what = new Position(-8579.0F, 1987.0F, 101.0F); | ||
| // 45.0: outside of 25 yard range, inside of 30 yard range | ||
| what->RelocatePolarOffset(n * M_PI * 2.0 / outerpointscount, 43.0); | ||
| outerpoints[n] = what; | ||
| //printf("build outerpoint %d: x=%f y=%f z=%f\n",n,what->GetPositionX(),what->GetPositionY(),what->GetPositionZ()); | ||
| } | ||
|
|
||
| for (int n = 0; n < innerpointscount; n++) | ||
| { | ||
| Position* what = new Position(-8579.0F, 1987.0F, 101.0F); | ||
| // 45.0: outside of 25 yard range, inside of 30 yard range | ||
| what->RelocatePolarOffset(n * M_PI * 2.0 / outerpointscount, 31.0); | ||
| innerpoints[n] = what; | ||
| //printf("build innerpoint %d: x=%f y=%f z=%f\n",n,what->GetPositionX(),what->GetPositionY(),what->GetPositionZ()); | ||
| } | ||
| } | ||
| bool Execute(Event event) override; | ||
|
|
||
| protected: | ||
| static int wrappingdistancebetween(int src, int dst, int scope); | ||
| int getnearestpoint(int excludeouter = -1, bool doinner = true); | ||
|
|
||
| static const int outerpointscount = 23; | ||
| static const int innerpointscount = 17; | ||
|
|
||
| Position* outerpoints[outerpointscount]; | ||
| Position* innerpoints[innerpointscount]; | ||
| }; | ||
|
|
||
| class Aq40Cthun2PositionAction : public Aq40Cthun1PositionAction | ||
| { | ||
| public: | ||
| Aq40Cthun2PositionAction(PlayerbotAI* botAI, std::string const name = "aq40 cthun2 get positioned") | ||
| : Aq40Cthun1PositionAction(botAI, name) | ||
| { | ||
| // oldworld trigger 87646 entry 15384 | ||
| getout = new Position(-8546.2, 1987.2, -96.52); | ||
| insideattack = new Position(-8550.7, 2000.4, -97.495); |
There was a problem hiding this comment.
The constructors for Aq40Cthun1PositionAction and Aq40Cthun2PositionAction allocate memory using new Position(...) but never free it, leading to memory leaks. A destructor should be added to deallocate this memory, or preferably, use smart pointers (std::unique_ptr) or store the Position objects directly in a std::vector<Position> to manage memory automatically.
src/strategy/AiObjectContext.cpp
Outdated
Comment on lines
+30
to
+50
| #include "raids/RaidStrategyContext.h" | ||
| #include "raids/blackwinglair/RaidBwlActionContext.h" | ||
| #include "raids/blackwinglair/RaidBwlTriggerContext.h" | ||
| #include "raids/naxxramas/RaidNaxxActionContext.h" | ||
| #include "raids/naxxramas/RaidNaxxTriggerContext.h" | ||
| #include "raids/icecrown/RaidIccActionContext.h" | ||
| #include "raids/icecrown/RaidIccTriggerContext.h" | ||
| #include "raids/obsidiansanctum/RaidOsActionContext.h" | ||
| #include "raids/obsidiansanctum/RaidOsTriggerContext.h" | ||
| #include "raids/eyeofeternity/RaidEoEActionContext.h" | ||
| #include "raids/vaultofarchavon/RaidVoATriggerContext.h" | ||
| #include "raids/onyxia/RaidOnyxiaActionContext.h" | ||
| #include "raids/onyxia/RaidOnyxiaTriggerContext.h" | ||
| #include "raids/vaultofarchavon/RaidVoAActionContext.h" | ||
| #include "raids/eyeofeternity/RaidEoETriggerContext.h" | ||
| #include "raids/moltencore/RaidMcActionContext.h" | ||
| #include "raids/moltencore/RaidMcTriggerContext.h" | ||
| #include "raids/aq20/RaidAq20ActionContext.h" | ||
| #include "raids/aq20/RaidAq20TriggerContext.h" | ||
| #include "raids/aq40/RaidAq40ActionContext.h" | ||
| #include "raids/aq40/RaidAq40TriggerContext.h" |
There was a problem hiding this comment.
This large block of new #include directives is unsorted. Sorting them alphabetically would improve readability and make it easier to spot duplicates or missing headers in the future.
|
|
||
| if (moveAwayFrom != NULL) | ||
| { | ||
| long distToTravel = radius - bot->GetDistance(moveAwayFrom); |
There was a problem hiding this comment.
The result of bot->GetDistance(), which is a float, is being assigned to a long variable. This can lead to a loss of precision. Please use a float or double for distToTravel.
float distToTravel = radius - bot->GetDistance(moveAwayFrom);| { | ||
| Unit* current = AI_VALUE(Unit*, "current target"); | ||
|
|
||
| if (current && (current->GetName() == "qiraji scarab" || current->GetName() == "qiraji scorpion")) |
There was a problem hiding this comment.
Comparing units by name is not robust, as names can be localized or may not be unique. It's better to compare them by their entry ID using GetEntry().
Comment on lines
+341
to
+484
| Spell* spell = boss->GetCurrentSpell(CURRENT_GENERIC_SPELL); | ||
|
|
||
| if (spell and spell->m_spellInfo->Id == SPELL_GREEN_BEAM) | ||
| { | ||
| Unit* bosstarget = botAI->GetUnit(bosstargetguid); | ||
| float bdist = bot->GetDistance(bosstarget); | ||
|
|
||
| if (bdist < 20.0) | ||
| { | ||
| if (bdist <= 10.0) | ||
| { | ||
| bot->AttackStop(); | ||
| //printf("%s: still %f away from %s\n",bot->GetName().c_str(),bdist,bosstarget->GetName().c_str()); | ||
| } | ||
|
|
||
| return MoveAway(bosstarget, 20.0); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| if (!point) | ||
| { | ||
| Group* group = bot->GetGroup(); | ||
| if (bot->GetDistance(boss) < 60.0F && group) | ||
| { | ||
| Player* closest = NULL; | ||
| float closestdist = 0.0F; | ||
|
|
||
| for (GroupReference* itr = group->GetFirstMember(); itr != nullptr; itr = itr->next()) | ||
| { | ||
| Player* member = itr->GetSource(); | ||
|
|
||
| if (member->GetGUID() != botguid && member->IsAlive()) | ||
| { | ||
| float dist = bot->GetDistance(member); | ||
|
|
||
| if (dist < 10.0 && (closest == NULL || closestdist < dist)) | ||
| { | ||
| closest = member; | ||
| closestdist = dist; | ||
| } | ||
| } | ||
| } | ||
|
|
||
| if (closest) | ||
| { | ||
| return MoveAway(closest, 10.0); | ||
| } | ||
| } | ||
|
|
||
| int nearest = getnearestpoint(); | ||
|
|
||
| if (nearest >= outerpointscount) | ||
| { | ||
| point = innerpoints[nearest - outerpointscount]; | ||
| } | ||
| else | ||
| { | ||
| point = outerpoints[nearest]; | ||
| } | ||
|
|
||
| if (bot->GetDistance(*point) < 0.5) | ||
| { | ||
| return false; | ||
| } | ||
| } | ||
|
|
||
| if (point) | ||
| { | ||
| return MoveTo(bot->GetMapId(), point->GetPositionX(), point->GetPositionY(), point->GetPositionZ(), | ||
| false, false, false, true, MovementPriority::MOVEMENT_COMBAT); | ||
| } | ||
| } | ||
|
|
||
| return false; | ||
| } | ||
|
|
||
| bool Aq40Cthun2PositionAction::Execute(Event event) | ||
| { | ||
| // boss_cthun.cpp | ||
| const int NPC_TRIGGER = 15384; | ||
| const int NPC_EXIT_TRIGGER = 15800; | ||
|
|
||
| const int SPELL_DIGESTIVE_ACID = 26476; | ||
|
|
||
| // Areatriggers | ||
| const int SPELL_SPIT_OUT = 25383; | ||
| const int SPELL_EXIT_STOMACH = 26221; | ||
| const int SPELL_RUBBLE_ROCKY = 26271; | ||
|
|
||
| const int SPELL_CARAPACE_CTHUN = 26156; // Server-side | ||
|
|
||
|
|
||
| // temple_of_ahn_quiraj.h | ||
| const int NPC_CLAW_TENTACLE = 15725; | ||
| const int NPC_EYE_TENTACLE = 15726; | ||
| const int NPC_GIANT_CLAW_TENTACLE = 15728; | ||
| const int NPC_GIANT_EYE_TENTACLE = 15334; | ||
| const int NPC_FLESH_TENTACLE = 15802; |
There was a problem hiding this comment.
This file contains many hardcoded "magic numbers" for spell IDs, NPC IDs, and coordinates. This makes the code harder to read and maintain. Please define these as named constants at the top of the file or in a relevant header to improve clarity and ease of future updates.
| const int NPC_VEKNILASH = 15275; | ||
|
|
||
| ObjectGuid botguid = bot->GetGUID(); | ||
| ObjectGuid petguid = (ObjectGuid)0UL; |
There was a problem hiding this comment.
Using a C-style cast (ObjectGuid)0UL to create an empty ObjectGuid is not type-safe. It's better to use the default constructor ObjectGuid() or the static member ObjectGuid::Empty for clarity and safety.
ObjectGuid petguid;
Comment on lines
+322
to
+355
| std::ostringstream out; | ||
| out << "attack vek'lor"; | ||
| botAI->TellError(out.str()); | ||
|
|
||
| return true; | ||
| } | ||
|
|
||
| return false; | ||
| } | ||
| } | ||
|
|
||
| for (int n = 0; n < boss2assignedindex; n++) | ||
| { | ||
| if (boss2assigned[n] == self) | ||
| { | ||
| if (IsVekNilash()) | ||
| { | ||
| std::ostringstream out; | ||
| out << "attack vek'nilash"; | ||
| botAI->TellError(out.str()); | ||
|
|
||
| return true; | ||
| } | ||
|
|
||
| return false; | ||
| } | ||
| } | ||
|
|
||
| if (IsPestControl()) | ||
| { | ||
| std::ostringstream out; | ||
| out << "attack pests"; | ||
| botAI->TellError(out.str()); | ||
|
|
There was a problem hiding this comment.
The calls to botAI->TellError() seem to be for debugging purposes. These should be removed from production code or wrapped in a conditional compilation block (e.g., #ifdef _DEBUG) to avoid spamming chat or logs.
…k) (mod-playerbots#2082) # Pull Request - Applies the clean and corrected singletons, Meyer pattern. (cherry picked from @SmashingQuasar ) Testing by just playing the game in various ways. Been tested by myself @Celandriel and @SmashingQuasar --- ## Complexity & Impact - Does this change add new decision branches? - [x] No - [ ] Yes (**explain below**) - Does this change increase per-bot or per-tick processing? - [x] No - [ ] Yes (**describe and justify impact**) - Could this logic scale poorly under load? - [x] No - [ ] Yes (**explain why**) --- ## Defaults & Configuration - Does this change modify default bot behavior? - [x] No - [ ] Yes (**explain why**) --- ## AI Assistance - Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - [x] No - [ ] Yes (**explain below**) --- ## Final Checklist - [x] Stability is not compromised - [x] Performance impact is understood, tested, and acceptable - [x] Added logic complexity is justified and explained - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Nicolas Lebacq <nicolas.cordier@outlook.com> Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
# Pull Request
Incorrect comparison fix.
---
## How to Test the Changes
- Alliance Bots should now be able to find the correct flightmaster and
use 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**)
---
## 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
Updates are only to the config. This PR should be simple. Tl;dr is destro pve spec is using the wrong glyphs. Longer explanation--right now, PreMadeSpecGlyph in the config provides for destro pve spec to use the following Major Glyphs at levels 15, 30, and 80, respectively: Life Tap, Quick Decay, Conflagrate. Quick Decay is useless for destro because destro does not cast Corruption except as a filler instant cast when on the move. Meanwhile, the spec is almost unplayable without Glyph of Conflagrate, so that should not be withheld until level 80. After Conflagrate, there are several viable glyphs, including Life Tap, Incinerate, Immolate, and Imp. I understand Glyph of Life Tap gets worse over time to the point that you don't want to use that glyph in ICC, but that's quite late, and it is useful for the vast majority of the game as a glyph that would actually be available at level 15. I also understand that Glyph of Immolate does not excel until high gear levels. Therefore, I decided to use Incinerate as the default level 80 glyph. The new order for default glyphs for destro pve for levels 15, 30, and 80 is Life Tap, Conflagrate, and Incinerate, respectively. I also made a couple of other very minor fixes in the config. No impact on performance or AI, obviously. Sidenote: Glyph of Conflagrate is not available at level 30--it requires level 40, so from 30 to 40, InitGlyphs() will plug in a random glyph for the second Major slot. This issue applies to many specs, and it's not avoidable unless InitGlyphs() is broken up into level brackets, which I think is not worthwhile. I think the better approach for glyphs is to ensure the right ones are applied at high levels, but with an attempt to make them usable at lower levels too where possible.
Hotfix for an issue arising from mod-playerbots#2082 OnBotLoginOperation() is calling OnBotLogin() twice for altbots. I don't know the full implication, but RandomPlayerbotMgr::OnBotLoginInternal() is being called on altbots, and the server will crash if you attempt to then log out the altbot. This fix works for me right now. Discussed with @Celandriel , going to push this hotfix for now until the rest of the maintainers can take a look.
Quick fix for a very annoying error identified by SmashingQuasar. In WSG, bots will camp the opposing graveyard if up 2-0. This is supposed to exclude the flag carrier, but a logical error has resulted in the flag carrier being excluded for Alliance camping only, meaning the Horde flag carrier will camp the GY with the rest of the team if up 2-0 and thus refuse to end the game.
# Pull Request Some logic was changed but differs from the original code, certain edge cases so not result in same behavior. This returns the original code with only the singleton chances. @Wishmaster117 Reviewed the hotfix and noticed the different code paths. ps: reverted an removed placeholder since its ongoing issue/research.
…eport its current Arena Points, Honor Points, and Arena Teams (mod-playerbots#2071) # Pull Request This PR adds a new whisper command "pvp stats" that allows players to ask a bot to report its current Arena Points, Honor Points, and Arena Teams (name and team rating). Reason: Due to a client limitation in WoW 3.3.5a, the inspection window does not display another player's Arena or Honor points , only team data. This command provides an easy in-game way to check a bot’s PvP currencies without modifying the client or core packets. --- ## Design Philosophy Uses existing core getters (GetArenaPoints, GetHonorPoints, GetArenaTeamId, etc.). Fully integrated into the chat command system (ChatTriggerContext, ChatActionContext). Safe, no gameplay changes, purely informational. No harcoded texts, use database local instead --- ## How to Test the Changes /w BotName pvp stats Bot reply: [PVP] Arena Points: 302 | Honor Points: 11855 [PVP] 2v2: <The Fighters> (rating 2000) [PVP] 3v3: <The Trio> (rating 573) ## 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 - [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 --- Multibot already ready Here is a sample of multibot when merged: <img width="706" height="737" alt="image" src="https://github.com/user-attachments/assets/5bcdd9f8-e2fc-4c29-a497-9fffba5dfd4e" /> --- ## 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>
Convert PlayerBots tables to InnoDB (disable strict mode during
conversion)
# Pull Request
### This change converts the PlayerBots-related tables from MyISAM to
InnoDB.
**Why this is beneficial (even without fixing a specific bug):**
- Crash safety & data integrity: InnoDB is transactional and uses redo
logs; it provides automatic crash recovery, unlike MyISAM which can
require manual repairs after unclean shutdowns.
- Row-level locking: InnoDB reduces write contention and improves
concurrency under bot-heavy workloads compared to MyISAM’s table-level
locks.
- Consistent reads: InnoDB supports MVCC, enabling stable reads while
writes are happening—useful for mixed read/write access patterns.
- Operational robustness: Better behavior under backup/restore and
replication scenarios; fewer “table marked as crashed” style issues.
Strict mode handling:
The migration toggles innodb_strict_mode off only for the session to
prevent the conversion from failing on edge-case legacy definitions,
then re-enables it immediately after.
---
## How to Test the Changes
- Step-by-step instructions to test the change
Run the SQL script in the Playerbot database.
- Any required setup (e.g. multiple players, bots, specific
configuration)
No
- Expected behavior and how to verify it
All tables should now have been converted from InnoDB to MyISAM.
This script should return nothing:
```
SELECT
t.TABLE_SCHEMA AS db_name,
t.TABLE_NAME AS table_name,
t.ENGINE AS storage_engine
FROM information_schema.TABLES t
WHERE t.TABLE_SCHEMA = DATABASE()
-- With phpMyAdmin, use the following and insert your database name, e.g., “acore_playerbots.”
-- WHERE t.TABLE_SCHEMA = 'YOUR_PLAYERBOT_DB'
AND t.TABLE_TYPE = 'BASE TABLE'
AND t.ENGINE = 'MyISAM'
ORDER BY t.TABLE_NAME;
```
## 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
- [ ] Documentation updated if needed
- [x] I tested this script on a server with 2000 bots for 6 days
(running 24/h) and had no issues with it.
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
# Pull Request Describe what this change does and why it is needed... --- ## 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? ``` [ ] No [ ] Yes (**explain below**) ``` Does this change increase per-bot or per-tick processing? ``` [ ] No [ ] Yes (**describe and justify impact**) ``` Could this logic scale poorly under load? ``` [ ] No [ ] Yes (**explain why**) ``` --- ## Defaults & Configuration Does this change modify default bot behavior? ``` [ ] No [ ] Yes (**explain why**) ``` If this introduces more advanced or AI-heavy logic: ``` [ ] Lightweight mode remains the default [ ] More complex behavior is optional and thereby configurable ``` --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? ``` [ ] No [ ] 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 - [ ] 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.
…ots#2109) Simple fix to config--zone ID 10 is Duskwood, not Deadwind Pass, as pointed out by @privatecore
# Pull Request Describe what this change does and why it is needed... --- ## 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? - - [ ] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [ ] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [ ] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - - [ ] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [ ] No - - [ ] 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 - - [ ] 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: Crow <pengchengw@me.com>
# Pull Request The purposes of this PR are to (1) establish a general raid helper framework for the benefit of future raid strategies and (2) make some improvements to problematic areas of the raid strategy code. List of changes: 1. Added new RaidBossHelpers.cpp and RaidBossHelpers.h files in the Raid folder. 3. Moved reused helpers from Karazhan, Gruul, and Magtheridon strategies to the new helper files. 4. Modified the prior function that assigned a DPS bot to store and erase timers and trackers in associative containers--the function now includes parameters for mapId (so a bot that is not in the instance will not be assigned) and for the ability to exclude a bot (useful for excluding particular important roles, such as a Warlock tank, so they are not bogged down by these extra tasks at critical moments). I also renamed it from IsInstanceTimerManager to IsMechanicTrackerBot. 5. Moved all helper files in raid strategies to Util folders (was needed for ICC, MC, and Ulduar). 6. Renamed and reordered includes of Ulduar files in AiObjectContext.cpp to match other raid strategies. a. This initially caused compile errors which made me realize that the existing code had several problems with missing includes and was compiling only due to the prior ordering in AiObjectContext.cpp. Therefore, I added the missing includes to Molten Core, Ulduar, and Vault of Archavon strategies. b. Ulduar and Old Kingdom were also using the same constant name for a spell--the reordering caused a compile error here as well, which just highlighted an existing problem that was being hidden. I renamed the constant for Ulduar to fix this, but I think the better approach going forward would be to use a namespace or enum class. But that is for another time and probably another person. 7. Several changes with respect to Ulduar files: a. The position constants and enums for spells and NPCs and such were in the trigger header file. I did not think that made sense so moved them to existing helper files. b. Since the strategy does not use multipliers, I removed all files and references to multipliers in it. c. I removed some unneeded includes. I did not do a detailed review to determine what else could be removed--I just took some out that I could tell right away were not needed. d. I renamed the ingame strategy name from "uld" to "ulduar," which I think is clearer and is still plenty short. 8. Partial refactor of Gruul and Magtheridon strategies: a. I did not due a full refactoring but made some quick changes to things I did previously that were rather stupid like repeating calculations, having useless logic like pointless IsAlive() checks for creatures already on the hostile references list, and not using the existing Position class for coordinates. b. There were a few substantive changes, such as allowing players to pick Maulgar mage and moonkin tanks with the assistant flag, but a greater refactoring of the strategies themselves is beyond this PR. c. I was clearing some containers used for Gruul and Magtheridon strategies; the methods are now fixed to erase only the applicable keys so that in the unlikely event that one server has multiple groups running Gruul or Magtheridon at the same time, there won't be timer or position tracker conflicts. ## How to Test the Changes 1. Enter any raid instance that has any code impacted by this PR 2. Engage bosses and observe if any strategies are now broken I personally tested Maulgar, Gruul, and Magtheridon and confirmed that they still work as intended. ## Complexity & Impact I do not expect this PR to have any relevant changes to in-game performance, but I will defer to those more knowledgeable than I if there are concerns in this area. As I've mentioned before, you can consider me to be like a person who has taken half an intro C++ course at best. ## AI Assistance None beyond autocomplete of repetitive changes. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
# Pull Request Added Chilton wand to excluded to equipment items for bots and unified 2 exclusion lists to single one. Resolves: mod-playerbots#2093 --- ## How to Test the Changes Couldnt reproduce Chilton wand bug then testing sound impossible. Someone can try getting this items on shaman. ## Complexity & Impact Does this change add new decision branches? - - [x] No - - [ ] Yes Does this change increase per-bot or per-tick processing? - - [x] No - - [ ] Yes Could this logic scale poorly under load? - - [x] No - - [ ] Yes --- ## Defaults & Configuration Does this change modify default bot behavior? - - [x] No - - [ ] Yes 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 --- ## 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 ---
### Summary Extend AiPlayerbot.SummonWhenGroup to apply when bots are auto-added to a group (e.g., addclass bots or raidus style auto invites). ### Motivation Bots added automatically to a group never accept a normal invite, so they do not trigger the summon-on-accept path. When SummonWhenGroup is enabled, these bots should also be teleported next to the master to match expected behavior. ### Implementation details Hook the summon behavior right after automatic group addition.
CI/CD PR --------- Co-authored-by: Crow <pengchengw@me.com>
Edited: Below description of methods were brought up to date as of the PR coming off of draft. ### General I've starting leveraging, to the extent possible, an out-of-combat method to erase map keys. This is mostly useful for timers that need to start upon the pull because I dislike having to rely on a check for a boss to be at 100% HP (or 99.9% or whatever) because it can be unreliable sometimes. ### Trash Underbog Colossi: Some Colossi leave behind a lake of toxin when they die that quickly kills any player that is standing in it. The pool is a dynamic-object-generated AoE, and bots will not avoid it on their own (I think because the AoE is out of combat, plus the radius is much larger than the default avoidance radius in the config). The method does not require bots to be in combat, and simply gets bots to run out of the toxin. You will probably still get a couple of idiots who drink in the middle of it, but in my experience, the vast majority of the raid gets out, and healers that escape can easily keep up a couple of fools until they've drank to full. Greyheart Tidecallers: Bots will mark and destroy Water Elemental Totems immediately. ### Hydross the Unstable The strategy uses 2 tanks, with the main tank assigned to the frost phase and the 1st assistant tank assigned to the nature phase. - The main tank will tank the frost phase, and the first assistant tank will tank the nature phase. They each have designated spots and will wait at their spots twiddling their thumbs while Hydross is in the other phase. - Hunters will misdirect to the applicable tank upon the pull and after each phase change. - The phase change process begins 1 second after Hydross reaches 100% Marks. The current tank will begin moving to the next phase tank's spot for the next tank to take over as soon as Hydross transitions. - DPS is ordered to stop after Hydross reaches 100% Marks until 5 seconds after he transitions. - Bots will prioritize the elementals adds after every phase change, unless Hydross is under 10% HP, in which case they should ignore the adds and burn the boss. - Ranged bots should spread during the frost phase to mitigate the impact of Water Tombs. ### The Lurker Below - There is a designated spot for the main tank. - Ranged DPS will fan out over a 120-degree arc that is centered directly across from the tank spot (to try to spread to reduce Geyser damage while also keeping them behind Lurker). - When Spout begins, all bots will run around behind Lurker. The intent is to keep a distance with a radius of 20 or 21 yards and within 45 degrees (either side) of directly behind him. Movement is specifically tangential along an arc so bots don't run in front of Lurker. - Spout's duration is tracked by a timer. The mechanics of the spell itself are rather unique and don't involve a continuous cast or aura to track easily so I settled for the timer. - If you have 3 (or more) tanks, each of the first 3 tanks will be assigned to one of the 3 Coilfang Guardians during the submerge phase. ### Leotheras the Blind The fight is designed for a Warlock tank. You can choose the Warlock tank by giving a Warlock the Assistant flag. If you don't do that, your highest HP Warlock will be picked. Do NOT switch the Warlock tank to a co +tank strategy--the designated Warlock is hardcoded to spam Searing Pain on Demon Leo and otherwise will engage in normal DPS strategies. If you don't have a Warlock at all, the strategy has some methods built in to try to make things work as best as possible with a melee tank. - The Spellbinders get marked with skulls and killed in order. - There is no designated spot or designated tank for the human phase. Your tanks will fight for aggro. Ranged bots will attempt to keep some distance, and when Whirlwind starts, everybody will run away from Leotheras. - During the demon phase, your melee tanks should take a backseat to your Warlock tank, who will receive help in the form of Misdirection. Bots will get the hell away from the Warlock tank so the Warlock tank should be taking every Chaos Blast alone. - During the final phase, your regular tanks will tank Leotheras, and the Warlock tank will tank his Shadow. The melee tanks will attempt to separate Leotheras from his Shadow so bots can focus down Leotheras without getting hit with Chaos Blasts. - Bots will wait 5 seconds to DPS after every transition into human phase, 12 seconds to DPS after every transition into demon phase, and 8 seconds to DPS after the transition into the final phase. There is no waiting on DPS after Whirlwinds, even though it would be ideal. It's not a big deal to live without, and for various reasons, it would have been a pain in the ass to deal with. - Bots will save Bloodlust/Heroism until after Spellbinders are down. - To deal with the Inner Demons, I disabled DPS assist for bots who are targeted and force them to focus only on their Inner Demons. This is sufficient in my experience for all DPS bots and Protection Warriors and Paladins to kill their Inner Demons, even at 50% damage. Feral Tank Druids and Healers still need help, so the strategy hardcodes their actions while fighting Inner Demons. For example, Resto Druids are coded to shift out of Tree Form, cast Barkskin on themselves, and just spam Wrath until the Inner Demon is dead. There are no bot strategy changes used for this method. ### Fathom-Lord Karathress You will need 4 tanks. Your main tank will tank Karathress, and an assistant tank will tank each Fathom Guard. If you have fewer than 4 tanks, then the priority order for tank assignment will be Karathress, Caribdis, Sharkkis, and then Tidalvess. - Roughly, the tank spots are (1) for Karathress, near where he starts but closer to the ledge for LoS reasons, (2) for Sharkkis, North from his starting location on the other side of the ramp, (3) for Tidalvess, Northwest from his starting location near the pillar, and (4) for Caribdis, far to the West of her starting position, near the corner. - Note that the tanks will probably clip through the terrain a bit when going to their positions. This is due to me implementing a forced MoveTo to the tank position coordinates. There is something weird about the maps in Karathress's room, and the tanks will take some really screwed up paths without making them go directly to the exact coordinates. So this looks stupid but is necessary. - One healer will be assigned to heal the Caribdis tank. Because AC Playerbots does not yet have a focus heal strategy, this just means that such healer has a designated location near the Caribdis tank's location. This healer can be selected with the Assistant flag. - Hunters will misdirect the Fathom Guards onto their applicable tanks. If you don't have three Hunters, the priority is Caribdis, Tidalvess, then Sharkkis. - DPS will wait 12 seconds to begin attacking. After that, they will prioritize targets as follows: - (1): Melee will always prioritize Spitfire Totems as soon as they spawn. This will continue through the duration of the fight. - (2): All bots will kill Tidalvess first. - (3): Melee bots will move to Sharkkis, and ranged bots will move to Caribdis. I understand this is not the standard kill order for players, which would have the entire raid kill Sharkkis next. The reasons I have done this differently are because melee DPS is much stronger with 3.3.5 talents vs. in retail TBC, and because bots get really thrown off by Cyclones and therefore they struggle to kill Caribdis quickly. You do not want Karathress below 75% HP before all Fathom-Guards are dead or he gets a huge damage buff. - (4) If Caribdis dies first, ranged bots will help with Sharkkis. - (5) Everybody kills Sharkkis's pet. - (6) Everybody kills Karathress. ### Morogrim Tidewalker - The main tank will pull the boss to the Northeast pillar, with the tank's back against the pillar. - A hunter will misdirect the boss onto the main tank upon the pull. - When the boss gets to 26% HP, the main tank will begin moving the boss to the Northeast corner of the room in preparation for Phase 2 (which begins at 25%). The tank will move in two steps to get around the pillar. - When the boss gets to 25% HP, ranged will follow the main tank to the corner and stack up right behind the boss. They will also move in two steps. - There is no method for melee since they will just naturally follow the boss anyway. ### Lady Vashj **Phase 1**: - The main tank will tank Vashj in the center of the arena. - If a Shaman is in the main tank's group, that Shaman will attempt to keep a Grounding Totem down in range of the main tank to absorb Shock Blast. This should continue in Phase 3. - Ranged bots will spread out in a semicircle around the center of the arena. - If any bot other than the main tank gets Static Charge, it will run away from other bots. If the main tank gets Static Charge, other bots will run away from the main tank. This method should continue in Phase 3. - If any bot is Entangled and has Static Charge, the bot will attempt to use Cloak of Shadows if it is a Rogue, and Paladins will attempt to use Hand of Freedom. This method should continue in Phase 3 (with some modifications). - Bots will not use Bloodlust or Heroism (saved for Phase 3). Bots will not use any other major cooldowns, either, such as Metamorphosis (saved for Phase 2 and 3). **Phase 2**: There are two central mechanics to this phase, both of which were challenging to get bots to execute properly. First is the system of prioritizing adds. The large playing field and multiple types of adds coming from random directions make this phase not doable with realistic DPS under the standard Playerbots target selection system. Therefore, I took inspiration from liyunfan's Naxx strategy for Phase 1 of Kel'Thuzad to disable dps assist and create a custom target selection system. First, a cheat with respect to the Coilfang Striders: - Tanks will permanently have the Fear Ward aura applied to them if you have raid cheats enabled. This allows them to tank the Coilfang Striders. The standard strategy was to have an Elemental Shaman kite the Strider around the perimeter of the arena, with ranged players (including healers) spamming DoTs on the Strider. If you can make bots do this, then great, but it's far beyond my capabilities. Therefore, with the cheat, the first assistant tank is responsible for tanking Striders and keeping them away from Core passers (described below) and Vashj. Evidently it was (and is, in TBC Classic) possible to tank (and melee DPS) Striders by wearing a Dire Maul Ogre Suit, which would give you enough reach to stay out of the Strider's fear. I actually tried that, and it does not work, either because AC's radiuses are not the same or just because bots do not maintain the same level of precise positioning. But anyway, the point is that technically the Striders are tankable by real players, so maybe that will make you feel better about using this cheat (it's fine enough rationalizing for me). I found this fight to be unmanageable without this cheat (i.e., using a method that would only have bots try to run away from Striders) because each Strider was guaranteed to wipe out a couple of bots, and you really cannot afford to lose anyone. YMMV though. - If cheats are enabled for Striders, Hunters will attempt to Misdirect the Striders to the first assist tank. - If cheats are not enabled, bots will attempt to use slows/roots to stop the Striders. I have some logic for them to use Netherweave Nets, but I suspect it does not actually work so I may remove it instead of trying to get it to function properly. Target priority is as follows: - Hunters and Mages: Enchanted Elementals, Coilfang Striders, Coilfang Elites. - Other Ranged Bots: Elites, Striders, Elementals. - Melee DPS: Elementals, Elites. - Tanks: Elites, Elementals (except if cheats are enabled, the first assistant tank will instead prioritize Striders and then Elementals) - Everybody else (basically means healers): Elementals, Elites, Striders - If there is more than one of the same target, bots will prioritize the one that is closer to Vashj. - In all cases, the valid attack ranged is limited so that bots should not leave the central platform. - If somehow a bot ends up too far from the center of the room and is not actively attacking anything, there is logic to make them run back. Handling Tainted Elementals and the Tainted Core: I will make another post about this later. It is easily the most complicated strategy I've ever worked on (far beyond anything on Kael'thas even) so will necessitate a long explanation. The tl;dr is that there is a chain of two-to-four bots that receive/pass the Tainted Core before using it on a Shield Generator, and if you are playing by yourself, you probably need to turn raid cheats on, in which case there will also be a bot that teleports to, kills, and loots the Tainted Elementals (i.e., the bots will then handle the entire sequence of shutting down Shield Generators). **Phase 3**: - The main tank will pick up Vashj immediately and try to keep her away from Enchanted Elementals. - DPS will burn down residual adds from Phase 2 in the order of (1) elementals, (2) strider for ranged only (if you have more than one up, you're dead), and (3) elites (hopefully you have only one up, but two with one almost dead is possible). - Hunters will kill Toxic Sporebats. This works quite well, but they (and anybody else if ordered to target Sporebats) have a tendency to levitate up into the pipes at the top of the room when killing the Sporebats. To counteract this, a method forcibly teleports bots to the ground if they get more than 2 yards above the ground. - The Phase 1 Cloak of Shadows/Hand of Freedom method is now expanded to include bots Entangled in the Sporebat poison pools (with Hand of Freedom usage prioritized on the main tank). - There is a specific method to avoid the Sporebat poison pools. The Vashj tank will move backwards when avoiding poison. --------- Co-authored-by: kadeshar <kadeshar@gmail.com>
#PR Description The root cause of issue mod-playerbots#1987 was the AI Value item usage becoming a very expensive call when bots gained professions accidentally. My original approach was to eliminate it entirely, but after inputs and testing I decided to introduce a more focused Ai value "Item upgrade" that only checks equipment and ammo inheriting directly from item usage, so the logic is unified between them. Upgrades are now only assessed when receiving an item that can be equipped. Additionally, I noticed that winning loot rolls did not trigger the upgrade action, so I added a new package handler for that. Performance needs to be re-evaluated, but I expect a reduction in calls and in the cost of each call. I tested with bots and selfbot in deadmines and ahadowfang keep. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
…ots#2068) ## Summary Fixes `AiPlayerbot.LootRollLevel = 1` to actually behave as "greed" mode per the config documentation. ## Problem The config documentation states: ```conf # Bots' loot roll level (0 = pass, 1 = greed, 2 = need) # Default: 1 (greed) AiPlayerbot.LootRollLevel = 1 ``` However, level 1 was converting **all GREED votes to PASS**, causing bots to pass on almost everything: | Item Type | AI Decision | Level 1 Behavior (Before) | Expected | |-----------|-------------|---------------------------|----------| | Gear upgrade | NEED | GREED ✓ | GREED | | Usable gear (not upgrade) | GREED | **PASS** ✗ | GREED | | Crafting materials | GREED | **PASS** ✗ | GREED | | Recipes, consumables | GREED | **PASS** ✗ | GREED | The only items bots would greed on were direct gear upgrades (originally NEED, downgraded to GREED). ## Root Cause In `LootRollAction.cpp`, lines 104-107 were converting GREED to PASS: ```cpp else if (vote == GREED) { vote = PASS; // This breaks "greed" mode } ``` ## Fix Remove the GREED→PASS conversion. Level 1 now only downgrades NEED to GREED (as intended), preserving GREED votes for useful items. ## Behavior After Fix | Level | Description | Behavior | |-------|-------------|----------| | 0 | Pass | Always pass on all items | | 1 | Greed | Greed on useful items, never need | | 2 | Need | Full AI logic (need/greed/pass) | ## Test Plan - [ ] Set `AiPlayerbot.LootRollLevel = 1` - [ ] Kill mobs that drop crafting materials, recipes, or non-upgrade gear - [ ] Verify bots greed on useful items instead of passing - [ ] Verify bots still pass on junk items - [ ] Verify bots never roll need (only greed) Co-authored-by: Hokken <Hokken@users.noreply.github.com>
Oculus drake mounting fix
# Pull Request
Adds actions and triggers for Warlock class to cast Unending Breath when
swimming, following the existing implementation for Shaman Water
Breathing.
---
## Feature Evaluation
Add triggers for Warlock noncombat strategy for Unending Breath on self
and party.
Triggers should only be active while swimming.
Minimal runtime cost on Warlock bots trigger processing.
---
## How to Test the Changes
- Bring a Warlock bot into water
- It should cast Unending Breath on itself and anyone in the party
## Complexity & Impact
- Does this change add new decision branches?
- [ ] No
- [x] Yes (**explain below**)
It adds triggers to Warlock to decide when to cast Unending Breath on
self or party members.
- Does this change increase per-bot or per-tick processing?
- [ ] No
- [x] Yes (**describe and justify impact**)
Minimal additional processing for Warlock triggers, same as already
existing triggers for Shaman.
- Could this logic scale poorly under load?
- [x] No
- [ ] Yes (**explain why**)
---
## Defaults & Configuration
- Does this change modify default bot behavior?
- [x] No
- [ ] Yes (**explain why**)
If this introduces more advanced or AI-heavy logic:
- [ ] Lightweight mode remains the default
- [ ] More complex behavior is optional and thereby configurable
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [ ] No
- [x] Yes (**explain below**)
Claude was used to explore the codebase to find similar implementations
that already existed.
---
## 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>
…ds instead (mod-playerbots#2105) # Pull Request https://en.cppreference.com/w/cpp/algorithm/equal_range.html > second is an iterator to the first element of the range [first, last) ordered after value (or last if no such element is found). The original code uses `return bounds.second->second`, which causes the wrong creature/gameobject to be returned. Instead, both methods (`GetCreature` and `GetGameObject`) now utilize ObjectAccessor's methods to retrieve the correct entities. These built-in methods offer a safer way to access objects. Additionally, `GetUnit` no longer includes redundant creature processing before checks and now has the same logic as the `ObjectAccessor::GetUnit` method. Furthermore, `GuidPosition::isDead` method has been renamed to `GuidPosition::IsCreatureOrGOAccessible` and updated, as it is used only for creatures (NOT units) and gameobjects. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## How to Test the Changes The behavior has not changed after all. ## 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. --------- Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
# Pull Request
As I began modifying the newrpginfo to change the types of data it
stored, or add new data I found myself with the issue of ending up
either with garbage memory if the information wasnt properly stored on
status change, or needing complicated destructor patterns for non
trivial data sets.
---
## Design Philosophy
Make rpginfo able to handle more complicated information in a strongly
---
## Feature Evaluation
No Feature changes
---
## How to Test the Changes
- Server should be stable for an extended period of time.
- Bots should be able to complete quests, fly, etc as they did before.
## Complexity & Impact
- Does this change add new decision branches?
- [X ] No
- [ ] Yes (**explain below**)
- Does this change increase per-bot or per-tick processing?
- [ ] No
- [ X] Yes (**describe and justify impact**)
Potentially as there can be more memory involved in the object.
- Could this logic scale poorly under load?
- [X ] No
- [ ] Yes (**explain why**)
---
## Defaults & Configuration
- Does this change modify default bot behavior?
- [ X] No
- [ ] Yes (**explain why**)
If this introduces more advanced or AI-heavy logic:
- [ ] Lightweight mode remains the default
- [ ] More complex behavior is optional and thereby configurable
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [ ] No
- [ X] Yes (**explain below**)
If yes, please specify:
- Gemini suggested the use of std::variant as an alternative data
structure. I found additinal external references that correlated with
the same suggestion of moving away from a union.
- Implementation was performed manually with Co-pilot auto-complete
---
## Final Checklist
In progress.
- [ ] Stability is not compromised
- [ ] Performance impact is understood, tested, and acceptable
- [ ] Added logic complexity is justified and explained
- [ ] Documentation updated if needed
---
## Notes for Reviewers
Im not 100% sure if this is a good design choice. There are some things
I didnt quite like by the end of this, specifically having to double
check whenever accessing data whether exists or not even though an
action has already been triggered. But I have a PR in the works where I
want to store a full flight path vector, and the union was giving me
issues. (It appears that state changes may be occuring in the same tick
between RPG status update and the stated action, leading to incorrect
data gathering.
I ended up solving it by first checking a pointer to the object, and
then getting the reference.
```c++
auto* dataPtr = std::get_if<NewRpgInfo::DoQuest>(&info.data);
if (!dataPtr)
return false;
auto& data = *dataPtr;
```
---------
Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
) # 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>
Github action modification
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>
# 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 Minor sign change to make check work properly. --- ## 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.
…rrect config patterns (mod-playerbots#2140) # Pull Request Feat: A common problem I have with follower bots is that if I quickly run up to a flightmaster and select a destination, as I go on my way, the bots can't get on a damn bird and say "Cannot find any flightmaster to talk". Guy was 8 yards away and they're completely blind to him. This is because when you select a destination, at that moment the bot would check `GetNPCIfCanInteractWith` from core, which uses `INTERACTION_DISTANCE`, which is defined as 5.5 yards. So the bot has to have caught up with you to be within 5.5 yards of the flightmaster. This PR expands that distance to use our own `sPlayerbotAIConfig.farDistance`, which is by default set to 20 yards. So just as long as bots have caught up to be within 20 yards from the flightmaster, they will follow you. Fix: While I was doing this, I noticed that the timings for bot flight staggering (introduced in mod-playerbots#1281) are defined in TaxiAction and PlayerbotAIConfig. So I removed their definitions from TaxiAction, made proper calls to the configs, and renamed them to similar format that other configs use. --- ## Design Philosophy We prioritize **stability, performance, and predictability** over behavioral realism. Complex player-mimicking logic is intentionally limited due to its negative impact on scalability, maintainability, and long-term robustness. Excessive processing overhead can lead to server hiccups, increased CPU usage, and degraded performance for all participants. Because every action and decision tree is executed **per bot and per trigger**, even small increases in logic complexity can scale poorly and negatively affect both players and world (random) bots. Bots are not expected to behave perfectly, and perfect simulation of human decision-making is not a project goal. Increased behavioral realism often introduces disproportionate cost, reduced predictability, and significantly higher maintenance overhead. Every additional branch of logic increases long-term responsibility. All decision paths must be tested, validated, and maintained continuously as the system evolves. If advanced or AI-intensive behavior is introduced, the **default configuration must remain the lightweight decision model**. More complex behavior should only be available as an **explicit opt-in option**, clearly documented as having a measurable performance cost. Principles: - **Stability before intelligence** A stable system is always preferred over a smarter one. - **Performance is a shared resource** Any increase in bot cost affects all players and all bots. - **Simple logic scales better than smart logic** Predictable behavior under load is more valuable than perfect decisions. - **Complexity must justify itself** If a feature cannot clearly explain its cost, it should not exist. - **Defaults must be cheap** Expensive behavior must always be optional and clearly communicated. - **Bots should look reasonable, not perfect** The goal is believable behavior, not human simulation. Before submitting, confirm that this change aligns with those principles. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? Changes here use a minimal amount of code to accomplish the objective, including using pre-defined distance values rather than creating new ones. Changes have no effect on processing. --- ## How to Test the Changes For expanding flightmaster search distance: You will be using the `stay` command. A bot commanded to `stay` will still take a flight with you, if it is near a flightmaster. So you can use the command to position the bot exactly where you want it to be 1. Place your follower bot immediately next to the flightmaster 2. Take a flight and the bot should follow. Nothing new here 3. Place the bot about 12 yards away from flightmaster. 4. Take a flight and the bot should follow. Same as before. 5. Repeat again, but this time place the bot 22 yards away. It should not follow you and instead say "Cannot find any flightmaster to talk" 6. The change should work correctly with `InstantFlightPaths = 0` in worldserver.conf, or if it's set to 1/2 and bots can instantly fly. For the config of staggering: 1. Make sure `InstantFlightPaths = 0` in worldserver.conf. 2. Change the timings in playerbots.conf under the `# FLIGHTPATH` section. 3. Changes should be correctly reflected in world. ## Complexity & Impact Does this change add new decision branches? - - [x] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [x] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [x] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [x] No - - [ ] Yes (**explain why**) Follower bots search a slightly bigger distance for nearby flightmasters. If this introduces more advanced or AI-heavy logic: - - [x] Lightweight mode remains the default - - [x] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [x] No - - [ ] Yes (**explain below**) If yes, please specify: - AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.) - Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation) - Which parts of the change were influenced or generated - Whether the result was manually reviewed and adapted AI assistance is allowed, but all submitted code must be fully understood, reviewed, and owned by the contributor. Any AI-influenced changes must be verified against existing CORE and PB logic. We expect contributors to be honest about what they do and do not understand. --- ## Final Checklist - - [x] Stability is not compromised - - [x] Performance impact is understood, tested, and acceptable - - [x] Added logic complexity is justified and explained - - [x] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging.
# Pull Request Translation cleanup for better track changes in translations. --- ## How to Test the Changes - Run server and check that script apply to database ## 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: --- ## 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 ---
…rbots#2177) # Pull Request This PR separates the image currently in the readme (currently named `icon.png`) into two, one that is an exact copy (`banner.png`) and one that only includes the image component (`icon.png`). This is to make the module more approachable when scrolling through the [AzerothCore catalogue](https://www.azerothcore.org/catalogue.html) as [it uses the `icon.png` image](https://github.com/user-attachments/assets/4c820f22-2a52-42b9-b360-f0e4d1496060). --- ## Feature Evaluation Please answer the following: - This has no changes to code, and has no impact on it. --- ## How to Test the Changes - This PR requires no testing. ## Complexity & Impact Does this change add new decision branches? - - [X] No Does this change increase per-bot or per-tick processing? - - [X] No Could this logic scale poorly under load? - - [X] No --- ## Defaults & Configuration Does this change modify default bot behavior? - - [X] No If this introduces more advanced or AI-heavy logic: - - [X] Lightweight mode remains the default --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) 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 - - [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.
# Pull Request Moving hardcoded values to config ## How to Test the Changes - use maintenance command - unequip and destroy item get from this command - turn off server - add item to config - turn on server - use maintenace command - check that different item was provided ## Complexity & Impact Does this change add new decision branches? - - [X] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [X] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [X] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [X] No - - [ ] Yes (**explain why**) --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [X] No - - [ ] Yes (**explain below**) --- ## Final Checklist - - [X] Stability is not compromised - - [X] Performance impact is understood, tested, and acceptable - - [X] Added logic complexity is justified and explained - - [X] Documentation updated if needed --- ## Notes for Reviewers
### Summary This PR restores the Naxxramas raid strategies that were removed in commit 686fe51 . 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>
# Pull Request I've made a few simple changes to the Karazhan strategies that should result in notable improvements in game. - **Attumen**: I was using a GetExactDist2d() check for phase 2 when bots stack behind him. That resulted in ranged bots being too close to attack. It's now switched to the correct GetDistance2d() check to account for the hitbox. - **Maiden of Virtue**: The tank continuously ran side-to-side when trying to tank her because it was trying to turn the boss with TankFaceAction but not being able to due to being required to be within a short distance of a set waypoint. I didn't understand the cause when I was originally working on Karazhan. To fix this, a new multiplier disables CombatFormationMoveAction (the "co+ disperse" strategy) and its inherited classes, except for SetBehindTargetAction. The only other class that inherits from CombatFormationMoveAction is TankFaceAction. I disabled the parent class also because the ranged bots have a coded positioning strategy and should not observe the co+ disperse strategy. - **The Curator**: Same deal as Maiden with a new multiplier. - **Nightbane**: Same deal as Maiden with a new multiplier. - **Malchezaar**: Infernal avoidance for non-enfeebled bots had movement priority set to MOVEMENT_FORCED. This was not good because it made bots refuse to cross Hellfire so if you got unlucky, they could be stuck on the other side of an Infernal from the boss and completely out of the fight. MOVEMENT_FORCED needs to be reserved for situations in which the bot absolutely cannot step in the AoE at all, and that's not the case for non-Enfeebled bots here. Priority is now changed to MOVEMENT_COMBAT. --- ## Feature Evaluation Please answer the following: - Describe the **minimum logic** required to achieve the intended behavior? - Describe the **cheapest implementation** that produces an acceptable result? - Describe the **runtime cost** when this logic executes across many bots? No additional complication in logic from these changes, and additional performance impact is exceedingly small (just a few more multipliers with inexpensive checks that would apply only in Karazhan). --- ## How to Test the Changes - Step-by-step instructions to test the change - Any required setup (e.g. multiple players, bots, specific configuration) - Expected behavior and how to verify it Should be straightforward. Engage the above-mentioned bosses in Karazhan and observe the mechanics. I did test all of them. ## Complexity & Impact Does this change add new decision branches? - - [X] No - - [ ] Yes (**explain below**) Does this change increase per-bot or per-tick processing? - - [ ] No - - [X] Yes (**describe and justify impact**) Barely due to the additional multipliers. Could this logic scale poorly under load? - - [X] No - - [ ] Yes (**explain why**) --- ## Defaults & Configuration Does this change modify default bot behavior? - - [X] No - - [ ] Yes (**explain why**) If this introduces more advanced or AI-heavy logic: - - [X] Lightweight mode remains the default - - [ ] More complex behavior is optional and thereby configurable --- ## AI Assistance Was AI assistance (e.g. ChatGPT or similar tools) used while working on this change? - - [X] No - - [ ] Yes (**explain below**) --- ## Final Checklist - - [X] Stability is not compromised - - [X] Performance impact is understood, tested, and acceptable - - [X] Added logic complexity is justified and explained - - [X] Documentation updated if needed --- ## Notes for Reviewers Anything that significantly improves realism at the cost of stability or performance should be carefully discussed before merging. --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: Revision <tkn963@gmail.com>
# Pull Request Added all TBC attunement quests to conf --- ## 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 Run maintenance on bots - Any required setup (e.g. multiple players, bots, specific configuration) This only applies to Individual Progression mod, since attunements aren't required in base AC - Expected behavior and how to verify it Bots should be able to enter: - The Eye (Tempest Keep) - Mount Hyjal - Black Temple ## 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**) All attunements for TBC are now added on 'maintenance' command 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.
Maintenance PR unrelated with module itself Modified action trigger to cover branch change
…rbots#2185) Added a check to prevent division by zero for orphaned raid groups. # Pull Request If a bots somehow ends up alone in a raid group, this can divide by zero and freeze the server. --- ## 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 is the simplest and cheapest way to implement this fix. --- ## 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 fix is a self-evident defensive measure. ## 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**) Core dump logs analysis to find this problem. 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.
## 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>
# 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>
# Pull Request needed changes for azerothcore/azerothcore-wotlk@515aeca --- ## 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. --------- 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>
Correction of a spelling mistake in the German chatter-texts. # Pull Request There is an error in the German translation of the chatter text. This will be fixed 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? --- ## 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.
…ots#2170) <!-- 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 --> The addition of a PR template last month was a great idea. We had nothing before and just let people type whatever they thought was relevant. Some wrote a whole article with too many details, and some just wrote the title and didn't explain any of the important details. So the addition of the PR template makes sure contributors know what's most important to this project. However, several people thought the template was... a lot. A lot of the information it showed, while useful to the contributor, made it a bit confusing to reviewer to know what the contributor wrote, and what is part of the PR template, so a lot of these guidelines have now been put behind `<!-- -->`. Moreover, even what has been hidden, has been truncated. The main message of the guidelines is stability is our top priority. It is a critical message, but it was repeated several more times than it should've been. Less is more here, and if an important message is repeated in a verbose manner, people would gloss over it like scrolling down long terms and conditions. The questions were also made more concise and explicit. We don't want contributors to question the questions themselves and how do they even apply to their code. The process of PR submission itself should not feel like submitting a long bureaucratic form. Think of it like a scientific paper abstract: It gives a reasonably short summary explaining the work, as clearly as possible. ## 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. These are the core questions that are important to know, but even then, not always relevant. So a note was added to the contributor that they can obviously skip these if their PR is something like a comment edit or whatever else that clearly doesn't add processing. ## 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. --> You are already testing whether or not this template is effective by looking at it. 1. See the"[Preview](https://github.com/NoxMax/mod-playerbots/blob/PR-template-proposal/PULL_REQUEST_TEMPLATE.md)" of the file just so it's clear what the template is like without any of the comments I made here. 2. See the "[Code](https://github.com/NoxMax/mod-playerbots/blob/PR-template-proposal/PULL_REQUEST_TEMPLATE.md?plain=1)" section of the template to see how it would actually look to a contributor. The only difference is the alignment of the translation table; it looks weird in the .md file, but it would look properly aligned to the contributor when submitting. ## 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**) Broke down processing impact into minimal and moderate. It is not uncommon that we have changes that add some minimal processing, and yes, collectively they can become an issue, but we also need to distinguish them from the rare changes that have a moderate impact, and how critical those changes are. - 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**) This question merges two previous one, because it's really asking the same thing: Will your change be a headache to maintain down the line? ## 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 | | --------------- | ------------------ | | | | | | | This is a new section, based on an idea that was discuss to not have everyone add their SQL translation files to their PR, and figure out file date name based on merge order, and coordinate who's using which message key. No. The hidden instruction instead tell the contributor to prerp the code to be translatable, by looking up GetBotTextOrDefault in the codebase for examples, and leave it that. When merged it would just use the default English fallback, then a monthly PR can be made containing translations for all the recently merged commits that have bot messages. The code would then automatically pickup the translated lines for that. This section of the template would remain if there's a consensus that this is how the translation workflow should be. ## 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 (Code comments, Conf comments, Commands in the Wiki). Final checklist remains the same, only clarifies to the contributors what sort of documentations that need updating. ## Notes for Reviewers <!-- Anything else that's helpful to review or test your pull request. --> This is a literal draft of of what the template should be, in that I look forward to your ideas to any ways that can further improve this.
# 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
…#2196) # Pull Request Workaround for crashes related with uninitialized new script introduced in azerothcore/azerothcore-wotlk@e74adf5 --- ## Feature Evaluation --- ## How to Test the Changes - run server with default bots amount without changes and should crashed - run server with default bots amount with changes and should run normally ## 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 - - [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 Copilot Cli to find crash reason. --- ## 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 ---
…-playerbots#1830) Summary This PR improves Follow related behaviour when the master is on a transport (zeppelin/boat). It makes follow actions safer and less disruptive by: Detecting when the master is on a transport and handling boarding correctly Avoiding teleport-under-floor issues by using a small positional offset when teleporting the bot near the master Preventing movement conflicts between MoveSpline/MotionMaster and the transport driver by forcing a MotionMaster cleanup and MoveIdle after boarding Clearing movement flags (forward / walking) after boarding so the bot does not remain in a walking/march state Next-check delay after boarding to allow the server to update transport/position state Before this change, bots get stuck when attempting to board Fight the server-side transport movement because local MoveSpline/MotionMaster was still active Repeatedly attempt movement on every follow tick while already a passenger, causing jitter and CPU/noise This PR reduces stuck/jitter cases, avoids conflicting movement commands, and makes boarding more robust. **Key changes** Check master->GetTransport() and handle three main cases: If bot already passenger of same transport: stabilize (StopMoving, Clear(true), MoveIdle, StopMovingOnCurrentPos) and set a longer next-check delay; return false (no new movement in theory). If bot passenger of another transport: do nothing (avoid conflicting behaviour). If bot not a passenger of master transport: teleport bot near master (with offsets) and call Transport::AddPassenger(bot, true), then force: bot->StopMoving() bot->GetMotionMaster()->Clear(true) bot->GetMotionMaster()->MoveIdle() Remove movement flags MOVEMENTFLAG_FORWARD and MOVEMENTFLAG_WALKING SetNextCheckDelay to random 1000–2500 ms Log boarding with bot name, transport GUID and coordinates Preserve earlier follow logic when master is not on a transport Tests performed Manual tests on a local server: Master on boat/zeppelin -> bot teleports to a safe offset position and becomes a passenger without getting stuck Bot already passenger on same transport -> bot no longer issues movement commands and stabilizes Bot on a different transport -> no boarding attempt for master's transport (no interference) Movement flags cleared after boarding; bot stops local movement and does not fight server transport movement Now the bots follow their masters in the zeppelins and boats, although sometimes they move around a bit inside when the zeppelin starts (they must have smoked something bad). --------- Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com> Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
# Pull Request Most of the changes are not functional but are to modify style based on comments received to the TK PR (e.g., eliminate nesting of if statements) and leverage general boss helpers. There is some reordering of returns and other changes to try to consolidate or clean-up the code (such as removing unnecessary parameters). The strategies themselves have only minor changes. - Main tank no longer uses tangential movement for Lurker Spout, unlike other bots. The MT will just call moves directly to a position behind Lurker. This is because I found tangential movement was taking too long for the MT to get in place since it starts right in front of Lurker. - Vashj MT group Shaman will now use Grounding Totem without actually switching to the Grounding Totem strategy. I have now eliminated all strategy swaps, which I dislike because they persist after the encounter, and it's better not to mess with player strategies since presumably people are generally using Windfury or Wrath of Air for the Air Totem. - I made a ton of changes to Vashj core passing as I noticed the existing logic is nonfunctional in several ways. It generally works fine ingame, but the changes should make things much smoother. For example, the storing of the nearest trigger NPC for generators in the existing strategy is useless because it relies on insert_or_assign for an unordered map that will continue to run during the course of the core passing logic, and a similar issue exists with respect to the map to store the last time a bot held a core. The result is that there is slight movement of bots when the core is flying through the air and not held by any bot because the trigger for core passing does not fire during that period. In practice, the time is brief enough that the sequence works OK, but it looks stupid because the bots should not be moving at all. So that should be fixed. There is a known issue re: core passing that would take extreme effort to fix and I am not going to do it because it is a fringe situation. There are a couple of spots where the Tainted Elemental can rarely spawn that can result in a straight-line passing sequence to the nearest generator that is blocked by LoS. Fixing this would be extremely difficult and niche, so what you will need to do if this happens is to just command your bots to destroy the core and try again with the next spawn. --- ## 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 streamline methods and even remove some. The strategy is admittedly somewhat performance heavy due to the need for function calls such as iterating over inventory items. However, the new version should be less performance intensive than the merged strategy--for example, there were places where all members of the raid would have their inventory checked, but I've now limited the check to only the 5 core handler bots. I've run the instance with pmon on, and there are no methods that stand out as particularly resource intensive when not in a boss encounter, and I view that as the most important thing (though I make effort to reduce performance impact during encounters also). Expensive checks that are unavoidable for the strategy to work such as grid searches are gated behind cheaper checks. --- ## 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 Enter SSC with a raid group and run the instance, including all bosses. Every boss should be killable, and every major mechanic should be addressed by bots. I will work with Dreathean to get the Wiki up soon so that should be a reference for testing strategies. ## Complexity & Impact Does this change add new decision branches? - - [ ] No - - [x] Yes (**explain below**) Only within the context of strategies, which are basically all new decision branches, and there are some tweaks here to what is currently merged. Does this change increase per-bot or per-tick processing? - - [x] No - - [ ] Yes (**describe and justify impact**) Could this logic scale poorly under load? - - [ ] No - - [x] Yes (**explain why**) I'm sure if you have a large server, with multiple raid groups running the instance at the same time, the performance impact could be significant. But I have done my best to limit it, and I think some notable performance impact is unavoidable with the current framework for raid strategies. --- ## Defaults & Configuration Does this change modify default bot behavior? - - [ ] No - - [x] Yes (**explain why**) Only for strategies in the instance. If this introduces more advanced or AI-heavy logic: - - [ ] Lightweight mode remains the default - - [x] More complex behavior is optional and thereby configurable There should be no impact if co +ssc and nc +ssc are not added to bots. Because raid strategies are currently not removed after leaving an instance, players should manually remove them (or reset botAI). This is a general issue that needs to be addressed with the module. --- ## 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. GPT-4 because I don't like to use up my premium requests in CoPilot and I generally like it better than GPT-5 =P I use LLMs to draft code snippets but do review everything and have become less-and-less reliant over time. I don't use agent mode, only ask. For this PR, I had it do the updated version of AnyRecentCoreInInventory(), which is more complicated than before and uses indexing for each bot to consider status of only prior bots in the passing chain. Everything else either I wrote or could have written but had the AI help and just edited afterward to save time. --- ## 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>
# 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.
# Pull Request Small fixes to naxxramas strategy --- ## 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: Copilot CLI to code review --- ## 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
Core PR update. mod-playerbots/azerothcore-wotlk#178 Core set packet as const, and so had to recast.
Maintenance PR to remove tasklist visible on github
<!-- 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 --> Update based on @Takenbacon feedback. Thank you for the correction to the PR. ## 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? - [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: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.