<!--
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 -->
Just a quick update to SQL IDs after seeing that #2131 and #2211 (which
are only in test-staging as of right now) use the same IDs.
## Feature Evaluation
<!--
If your PR is very minimal (comment typo, wrong ID reference, etc), and
it is very obvious it will not have
any impact on performance, you may skip these question. If necessary, a
maintainer may ask you for them later.
-->
<!-- Please answer the following: -->
- Describe the **minimum logic** required to achieve the intended
behavior.
- Describe the **processing cost** when this logic executes across many
bots.
## How to Test the Changes
<!--
- Step-by-step instructions to test the change.
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
- Expected behavior and how to verify it.
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [ ] Minimal impact (**explain below**)
- - [ ] Moderate impact (**explain below**)
- Does this change modify default bot behavior?
- - [ ] No
- - [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- - [ ] No
- - [ ] Yes (**explain below**)
## 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
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
- Was AI assistance used while working on this change?
- - [ ] No
- - [ ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
## Final Checklist
- - [ ] Stability is not compromised.
- - [ ] Performance impact is understood, tested, and acceptable.
- - [ ] Added logic complexity is justified and explained.
- - [ ] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
## Pull Request Description
Migration of "wait for attack" strategy from cmangos playerbots.
Resolves: https://github.com/mod-playerbots/mod-playerbots/issues/990
## Feature Evaluation
Optional strategy for bots which are in party with real player.
## How to Test the Changes
- add strategy to bot "nc +wait for attack" and "co +wait for attack"
- set time via command "wait for attack time x" where x is time which
they wait in seconds (you should get response from bot)
- attack any target (for example dummy in main city)(bot should wait
with attack)
## Impact Assessment
- [ ] No, not at all
- [x] Minimal impact (**explain below**)
- [ ] Moderate impact (**explain below**)
Performance wise only bots having this optinal strategy have additional
cost in multiplier which check every attack action that should be
execute.
- Does this change modify default bot behavior?
- [x] No
- [ ] Yes (**explain why**)
- Does this change add new decision branches or increase maintenance
complexity?
- [x] No
- [ ] Yes (**explain below**)
## Messages to Translate
Does this change add bot messages to translate?
- [ ] No
- [x] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
1740 | Please provide a time to set (in seconds)
1741 | Please provide valid time to set (in seconds) between 0 and 99
1742 | Wait for attack time set to %new_time seconds
## AI Assistance
Was AI assistance used while working on this change?
- [ ] No
- [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Copilot CLI - help with migration
## 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.
-->
# Pull Request
* Improper crash fix by 297f11d3e59f52a29f68188245e6b786c9fa838e. That
fix worked not because setting `logout = true` stops the server from
crashing, but because it stopped the following `if (!logout)` block from
executing at all. In that block `delete target;` was the actual cause of
the crashing and this was recreated in testing.
`botWorldSessionPtr->LogoutPlayer(true);` already deleted target
internally, then comes `delete target;` to delete already freed memory
and the whole thing crashes.
* Players had the ability to logout anyone's alt/addClass bots. Now
there's a check to make sure command is from master.
* When commanded to logout, RNDbots in player's party used to reply with
"I'm logging out!", but they don't, because they shouldn't, because they
are not alt/adClass bots. Now they say "You can't command me to logout!"
* Added early exits for the "logout cancel" block, then I remembered
bots were made to always instantly logout because of past issues with
timed logout. Need to review whether or not we should re-implement timed
logout, or if it's not worth it and its dead code removed with instant
logout remaining the only option.
---
## Design Philosophy
We prioritize **stability, performance, and predictability** over
behavioral realism.
Complex player-mimicking logic is intentionally limited due to its
negative impact on scalability, maintainability, and
long-term robustness.
Excessive processing overhead can lead to server hiccups, increased CPU
usage, and degraded performance for all
participants. Because every action and
decision tree is executed **per bot and per trigger**, even small
increases in logic complexity can scale poorly and
negatively affect both players and
world (random) bots. Bots are not expected to behave perfectly, and
perfect simulation of human decision-making is not a
project goal. Increased behavioral
realism often introduces disproportionate cost, reduced predictability,
and significantly higher maintenance overhead.
Every additional branch of logic increases long-term responsibility. All
decision paths must be tested, validated, and
maintained continuously as the system evolves.
If advanced or AI-intensive behavior is introduced, the **default
configuration must remain the lightweight decision
model**. More complex behavior should only be
available as an **explicit opt-in option**, clearly documented as having
a measurable performance cost.
Principles:
- **Stability before intelligence**
A stable system is always preferred over a smarter one.
- **Performance is a shared resource**
Any increase in bot cost affects all players and all bots.
- **Simple logic scales better than smart logic**
Predictable behavior under load is more valuable than perfect decisions.
- **Complexity must justify itself**
If a feature cannot clearly explain its cost, it should not exist.
- **Defaults must be cheap**
Expensive behavior must always be optional and clearly communicated.
- **Bots should look reasonable, not perfect**
The goal is believable behavior, not human simulation.
Before submitting, confirm that this change aligns with those
principles.
---
## Feature Evaluation
Please answer the following:
- Describe the **minimum logic** required to achieve the intended
behavior?
- Describe the **cheapest implementation** that produces an acceptable
result?
- Describe the **runtime cost** when this logic executes across many
bots?
This PR removes more code than it adds, and makes sure that exits happen
as early as possible. It has no effect on processing power and makes the
code slightly more maintainable.
---
## How to Test the Changes
1. Whisper `logout` to any bot whose master is not you. The bot can be
RND/alt/addClass. The bot may have someone else as a master or may not
have a master at all. The bot may be part of a party or not. Regardless,
you are not its master. It should tell you "You are not my master!". Two
players or two instances of the client from two different accounts are
needed for this test, in order for Player A to command a bot to logout,
when the bot's master is Player B.
2. Invite an RND bot to your party. As along as it's in your party, you
are it's master, but RND bots cannot be logged out through chat
commands. If you whisper `logout` to it, it should say "You can't
command me to logout!", and not logout.
3. Whisper to an alt/addClass bot `logout`. The bot can be in your party
or could've been uninvited. All that matters is that you are its master.
It should reply "I'm logging out!"
## Complexity & Impact
Does this change add new decision branches?
- - [x] No
- - [ ] Yes (**explain below**)
Does this change increase per-bot or per-tick processing?
- - [x] No
- - [ ] Yes (**describe and justify impact**)
Could this logic scale poorly under load?
- - [x] No
- - [ ] Yes (**explain why**)
---
## Defaults & Configuration
Does this change modify default bot behavior?
- - [ ] No
- - [x] Yes (**explain why**)
In that it fixes wrong behavior.
If this introduces more advanced or AI-heavy logic:
- - [x] Lightweight mode remains the default
- - [x] More complex behavior is optional and thereby configurable
---
## AI Assistance
Was AI assistance (e.g. ChatGPT or similar tools) used while working on
this change?
- - [ ] No
- - [x] Yes (**explain below**)
Used Claude for code review, and translations.
If yes, please specify:
- AI tool or model used (e.g. ChatGPT, GPT-4, Claude, etc.)
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation)
- Which parts of the change were influenced or generated
- Whether the result was manually reviewed and adapted
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
Any AI-influenced changes must be verified against existing CORE and PB
logic. We expect contributors to be honest
about what they do and do not understand.
---
## Lines to Translate
These are keys and defaults of lines that were added/edited, and to be
translated at a later SQL update.
| Key | Default line |
| --- | --- |
| bot_not_your_master | You are not my master! |
| bot_rndbot_no_logout | You can't command me to logout! |
---
## Final Checklist
- - [x] Stability is not compromised
- - [x] Performance impact is understood, tested, and acceptable
- - [x] Added logic complexity is justified and explained
- - [x] Documentation updated if needed
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
# 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
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.
# 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
---
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
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>
### Update :Thank you to @notOrrytrout from prompting me to work on
this. Its been a huge learning experience.
With @notOrrytrout I started working on enabling bot fishing with
master, but also on their own.
The first commit didnt crash, showing that it was possible to have a bot
cast when master does. Currently it compiles but crashes when you try to
fish with a bot in the group, whether the bot has fishing or not. It
makes me think that the check in FishingValues is broken somehow, but I
cant figure out how.
---------
Co-authored-by: bash <31279994+hermensbas@users.noreply.github.com>
Stripped down version of #1818. No new features. Refactors
IsPossibleTarget in AttackersValue.cpp to a better style and makes sure
pets don't attack in prohibited zones.
Testing:
Confirmed that aggro pets no longer attack in PVP prohibited areas, but
still do outside them. Zim'Torga in Zul'Drak is a good example to test
this (ID 4323). Lookout for death knights with a Risen Ally
(uncontrolled and naturally aggro) now they respect PVP prohibition like
their master.
Note: If you manually teleport a bot that is in mid combat to a PVP
prohibited area, its aggro pet might still attack, because its master is
still in combat strategy. Otherwise the pet will not attack if its
master has switched to non-combat.
* Paladin buff logic: Sanctuary+Kings synergy, role-aware targeting, safer Greater buffs
* Update PaladinActions.cpp
* Update PaladinActions.cpp
* All configs should be implement into PlayerbotAIConfig and sPlayerbotAIConfig used in code
* added: prayer of fortitude
* Magic number removed
* Update PaladinActions.cpp
* Update PaladinActions.cpp
* Update PaladinActions.cpp
* Update PaladinActions.cpp
* Update PaladinActions.cpp
* Add patch for solo paladin in group
* Correction review
* Update PaladinActions.cpp
* Add harcoded text to DB
* Fixed a typo in filename and renamed table for consistency
* Added update file to rename the tables
* Drop old tables if they exist and create new ones if they don't exist already
* Add table to store the security keys for accounts.
* Add table to store relationships between accounts.
* Add a new configuration option to enable or disable trusted account bots.
* add checks for linked accounts
* Handle account linking and chat commands
* fix uppercase typo
* change query & fix chatcommandtable
* add missing functions to header
* move account linking to updates dir
* moved table creation to correct updates folder
* use playerbots db instead of character db
* fix db
* fix install?
* remove duplicated logic and add hashing to stored securityKey
* add object before call
* change chat variable
* rename SQL file for correct execution order
* add header include for ubuntu compatibility
* remove old sql
This commit adds a missing composite index on the `playerbots_random_bots` table
(`owner`, `bot`, `event`) to improve database performance during high playerbot
activity.
Adding this index significantly reduces the occurrence of deadlocks when multiple
threads access the random bots table simultaneously.
The change is 100% backward-compatible and does not affect existing data or
functionality.
Update will allow any adequately leveled bot to queue for all random and specific TBC dungeons. Normal and Heroic modes that require attunement or keys will be accessible by bots.
InitReputation: Level 70+ Bots will receive Honored rank for all the required factions needed for Heroic keys to function. I've placed the calls to InitRep before InitMounts, I feel we can do something with that in the future. Randomised rep values might allow bots to obtain other mounts?
InitKeyring: All bots receive all non-rep required keys (Shattered Halls Key, Shadow Labyrinth Key, Key to the Arcatraz), and bots with the required rep (Honored) get the other keys.
InitAttunementQuests: Level 60+ bots complete the Caverns of Time and Magister's Terrace attunement quests.
Updated acore_playerbots SQL; playerbots_dungeon_suggestion_definition; max_level increased to 73 (from 70) for all TBC Heroics and Magister's Terrace nomal. Allows more level appropriate bots to join.
* German full translation
With the power of ChatGPT i translated all chatter texts into German locale.
Insterted the German texts into text_loc3.
Everything else should stay unchenged.
I've updated ai_playerbot_texts.sql and added over 900+ new lines for the bots to use in-game, including a mix of humorous and standard lines, along with a nod to the classic Barrens chat. This update is designed to make the game feel more immersive by providing the Playerbots Module with more dialogue options as you play.
