PR template proposal, using the proposed template itself (#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_TEMPLATE.md

@@ -1,124 +1,103 @@
-# Pull Request
+<!--
+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.
 
-Describe what this change does and why it is needed...
+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.
 
-## Design Philosophy
+Before submitting, make sure your changes aligns with these principles.
+-->
 
-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.
+## Pull Request Description
+<!-- Describe what this change does and why it is needed -->
 
-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
+<!--
+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:
+<!-- 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.
 
-- 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, number of bots, specific configuration).
+- Expected behavior and how to verify it.
+-->
 
-- 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**)
+## Impact Assessment
+<!-- As a generic test, before and after measure of pmon (playerbot pmon tick) can help you here. -->
+- Does this change increase per-bot/per-tick processing or risk scaling poorly with thousands of bots?
+    - [ ] No, not at all
+    - [ ] Minimal impact (**explain below**)
+    - [ ] Moderate impact (**explain below**)
 
-Does this change 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**)
 
-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
----
+
+- Does this change add new decision branches or increase maintenance complexity?
+    - [ ] 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?
+- [ ] No
+- [ ] Yes (**list messages in the table**)
+
+| Message key  | Default message |
+| --------------- | ------------------ |
+|			 |			      |
+|			 |			      |
 
 ## 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.
+We expect contributors to be honest about what they do and do not understand.
+-->
+Was AI assistance used while working on this change?
+- [ ] No
+- [ ] Yes (**explain below**)
+<!--
+If yes, please specify:
+- Purpose of usage (e.g. brainstorming, refactoring, documentation, code generation).
+- Which parts of the change were influenced or generated, and whether it was thoroughly reviewed.
+-->
+
 
----
 
 ## Final Checklist
 
-- - [ ] Stability is not compromised
-- - [ ] Performance impact is understood, tested, and acceptable
-- - [ ] Added logic complexity is justified and explained
-- - [ ] Documentation updated if needed
-
----
+- [ ] Stability is not compromised.
+- [ ] Performance impact is understood, tested, and acceptable.
+- [ ] Added logic complexity is justified and explained.
+- [ ] Documentation updated if needed (Conf comments, WiKi commands).
 
 ## Notes for Reviewers
-
-Anything that significantly improves realism at the cost of stability or performance should be carefully discussed
-before merging.
+<!-- Anything else that's helpful to review or test your pull request. -->

data/sql/playerbots/updates/2026_02_13_00_ai_playerbot_texts.sql

@@ -0,0 +1 @@
+UPDATE `ai_playerbot_texts` SET `text_loc3`='%s, du hörst den triefenden Sarkasmus in meinem text nicht' WHERE `id`=1353;

src/Bot/Cmd/ChatHelper.cpp

@@ -598,9 +598,9 @@ uint32 ChatHelper::parseSlot(std::string const text)
     return EQUIPMENT_SLOT_END;
 }
 
-bool ChatHelper::parseable(std::string const text)
+bool ChatHelper::parseableItem(std::string const text)
 {
-    return text.find("|H") != std::string::npos || text == "questitem" || text == "ammo" ||
+    return text.find("|Hitem:") != std::string::npos || text == "questitem" || text == "ammo" ||
            substrContainsInMap<uint32>(text, consumableSubClasses) ||
            substrContainsInMap<uint32>(text, tradeSubClasses) || substrContainsInMap<uint32>(text, itemQualities) ||
            substrContainsInMap<uint32>(text, slots) || substrContainsInMap<ChatMsg>(text, chats) ||

src/Bot/Cmd/ChatHelper.h

@@ -66,7 +66,7 @@ public:
     static uint32 parseSlot(std::string const text);
     uint32 parseSkill(std::string const text);
 
-    static bool parseable(std::string const text);
+    static bool parseableItem(std::string const text);
 
     void eraseAllSubStr(std::string& mainStr, std::string const toErase);
 

src/Bot/Engine/ExternalEventHelper.cpp

@@ -30,7 +30,7 @@ bool ExternalEventHelper::ParseChatCommand(std::string const command, Player* ow
             return true;
     }
 
-    if (!ChatHelper::parseable(command))
+    if (!ChatHelper::parseableItem(command))
         return false;
 
     HandleCommand("c", command, owner);

src/Bot/Factory/RandomPlayerbotFactory.cpp

@@ -9,6 +9,7 @@
 #include "ArenaTeamMgr.h"
 #include "DatabaseEnv.h"
 #include "PlayerbotAI.h"
+#include "RaceMgr.h"
 #include "ScriptMgr.h"
 #include "SharedDefines.h"
 #include "SocialMgr.h"
@@ -60,7 +61,7 @@ Player* RandomPlayerbotFactory::CreateRandomBot(WorldSession* session, uint8 cls
     const bool alliance = static_cast<bool>(urand(0, 1));
 
     std::vector<uint8> raceOptions;
-    for (uint8 race = RACE_HUMAN; race < MAX_RACES; ++race)
+    for (uint8 race = RACE_HUMAN; race < sRaceMgr->GetMaxRaces(); ++race)
     {
         // skip disabled with config races
         if ((1 << (race - 1)) & sWorld->getIntConfig(CONFIG_CHARACTER_CREATING_DISABLED_RACEMASK))

src/Bot/PlayerbotAI.cpp

@@ -1532,6 +1532,21 @@ std::vector<std::string> PlayerbotAI::GetStrategies(BotState type)
 
 void PlayerbotAI::ApplyInstanceStrategies(uint32 mapId, bool tellMaster)
 {
+    static const std::vector<std::string> allInstanceStrategies =
+    {
+        "aq20", "bwl", "karazhan", "gruulslair", "icc", "magtheridon", "moltencore",
+        "naxx", "onyxia", "ssc", "tempestkeep", "ulduar", "voa", "wotlk-an", "wotlk-cos",
+        "wotlk-dtk", "wotlk-eoe", "wotlk-fos", "wotlk-gd", "wotlk-hol", "wotlk-hor",
+        "wotlk-hos", "wotlk-nex", "wotlk-occ", "wotlk-ok", "wotlk-os", "wotlk-pos",
+        "wotlk-toc", "wotlk-uk", "wotlk-up", "wotlk-vh"
+    };
+
+    for (const std::string& strat : allInstanceStrategies)
+    {
+        engines[BOT_STATE_COMBAT]->removeStrategy(strat);
+        engines[BOT_STATE_NON_COMBAT]->removeStrategy(strat);
+    }
+
     std::string strategyName;
     switch (mapId)
     {
@@ -1631,10 +1646,13 @@ void PlayerbotAI::ApplyInstanceStrategies(uint32 mapId, bool tellMaster)
         default:
             break;
     }
+
     if (strategyName.empty())
         return;
+
     engines[BOT_STATE_COMBAT]->addStrategy(strategyName);
     engines[BOT_STATE_NON_COMBAT]->addStrategy(strategyName);
+
     if (tellMaster && !strategyName.empty())
     {
         std::ostringstream out;

src/Bot/RandomPlayerbotMgr.cpp

@@ -37,6 +37,7 @@
 #include "PlayerbotFactory.h"
 #include "Playerbots.h"
 #include "Position.h"
+#include "RaceMgr.h"
 #include "Random.h"
 #include "RandomPlayerbotFactory.h"
 #include "ServerFacade.h"
@@ -1995,7 +1996,7 @@ void RandomPlayerbotMgr::PrepareTeleportCache()
         }
 
         // add all initial position
-        for (uint32 i = 1; i < MAX_RACES; i++)
+        for (uint32 i = 1; i < sRaceMgr->GetMaxRaces(); i++)
         {
             for (uint32 j = 1; j < MAX_CLASSES; j++)
             {
@@ -2008,7 +2009,7 @@ void RandomPlayerbotMgr::PrepareTeleportCache()
 
                 for (int32 l = 1; l <= 5; l++)
                 {
-                    if ((1 << (i - 1)) & RACEMASK_ALLIANCE)
+                    if ((1 << (i - 1)) & sRaceMgr->GetAllianceRaceMask())
                         allianceStarterPerLevelCache[(uint8)l].push_back(pos);
                     else
                         hordeStarterPerLevelCache[(uint8)l].push_back(pos);
@@ -3126,7 +3127,7 @@ void RandomPlayerbotMgr::PrintStats()
 
     std::map<uint8, uint32> lvlPerRace;
     std::map<uint8, uint32> lvlPerClass;
-    for (uint8 race = RACE_HUMAN; race < MAX_RACES; ++race)
+    for (uint8 race = RACE_HUMAN; race < sRaceMgr->GetMaxRaces(); ++race)
     {
         perRace[race] = 0;
         lvlPerRace[race] = 0;
@@ -3273,7 +3274,7 @@ void RandomPlayerbotMgr::PrintStats()
     }
 
     LOG_INFO("playerbots", "Bots race:");
-    for (uint8 race = RACE_HUMAN; race < MAX_RACES; ++race)
+    for (uint8 race = RACE_HUMAN; race < sRaceMgr->GetMaxRaces(); ++race)
     {
         if (perRace[race])
         {

src/Mgr/Travel/TravelMgr.cpp

@@ -14,6 +14,7 @@
 #include "MapMgr.h"
 #include "PathGenerator.h"
 #include "Playerbots.h"
+#include "RaceMgr.h"
 #include "TransportMgr.h"
 #include "VMapFactory.h"
 #include "VMapMgr2.h"
@@ -3335,7 +3336,7 @@ void TravelMgr::LoadQuestTravelTable()
 
             std::ostringstream out;
 
-            for (uint8 race = RACE_HUMAN; race < MAX_RACES; race++)
+            for (uint8 race = RACE_HUMAN; race < sRaceMgr->GetMaxRaces(); race++)
             {
                 for (uint8 cls = CLASS_WARRIOR; cls < MAX_CLASSES; ++cls)
                 {

src/Mgr/Travel/TravelNode.cpp

@@ -11,6 +11,7 @@
 #include "BudgetValues.h"
 #include "PathGenerator.h"
 #include "Playerbots.h"
+#include "RaceMgr.h"
 #include "ServerFacade.h"
 #include "TransportMgr.h"
 
@@ -1660,7 +1661,7 @@ void TravelNodeMap::generateStartNodes()
     startNames[RACE_GNOME] = "Dwarf and Gnome";
     startNames[RACE_TROLL] = "Orc and Troll";
 
-    for (uint32 i = 0; i < MAX_RACES; i++)
+    for (uint32 i = 0; i < sRaceMgr->GetMaxRaces(); i++)
     {
         for (uint32 j = 0; j < MAX_CLASSES; j++)
         {