<!--
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 -->
Replaced hardcoded bot text with translationable.
Related with: #1295
## 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.
-->
1. Invite bots
2. Check that text after "follow" and "stay" return texts "Following"
and "Staying"
## 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**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Summary hardcoded text and checking that they already exists to reuse.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
## Pull Request Description
<!-- Describe what this change does and why it is needed -->
Big thanks to @kadeshar for providing the bis list for many raids and
ilvls :D
Video demo for ICC 25HC:
https://studio.youtube.com/video/nACyjn817iQ/edit
Video demo for autogear bis chat command:
https://www.youtube.com/watch?v=2YqyVBaSb2g
split main IccActions.cpp into sperate per boss .cpp files
changed style to be more aligned with
https://www.azerothcore.org/wiki/cpp-code-standards (WIP)
added bisicc chat command for bots to gear with ICC bis gear if autogear
and bisicc is enabled in cfg
https://gist.github.com/metal0/0bb094bf65d27e17044308ad0646cae1 bis list
used
LM
Added multiple spike marking and focus for faster spike clearing, each
spike will get its own kill group, tank spike will never get melee bots
(only assist tank and ranged dps)
Added coldflame detection so that melee bots dont go for spikes that are
in flames
During bonestorm assist tank will go far away spot so that once
bonestorm is fixed, LM will bounce back and forth from MT to AT (atm it
targets randomly, it should always pick furthest target)
Coldflame avoidance is handled by avoid AOE, important to keep it on in
cfg
Tested on ALL diffs
LDW
Improved skull marking of adds, add handling by tanks and dps
Changed 1st position for ranged bots for easier adds handling in HC and
NM
Improved tanking logic for tanks, assist tank will focus on collecting
adds and bring them near boss
Real players will also get cyclone aura when mind controlled
Improved ranged position during 2nd phase, they should not get stuck in
corners/walls anymore
Tanks will remove LDW ToI aura in HC (really hard to tank with it since
many things are happening at once)
Added Cheat for LDW fight to help tanks with agro in 2nd phase of heroic
modes
Changed tank position in phase 2 closer to pillars opposed to stairs
(bots love to fall thru floor and run thru walls if near them) this
fixed the issue
Fixed edge case for escaping from shades, it could happen that multiple
shades would target bot, and it was running from 1st one he found, now
it will run form all that are targeting it
Hunters will cast viper sting now, to increase shield draining speed
Tested on ALL diffs
Edit 19.5. :
Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world
cfg ICC buff on max (30%)
In short cleared LDW without ICC cheats with bis gear but unoptimized
enchants, talents, gems. I still recommend using ICC cheats for better
and fun experience.
GS
Changed triggers and actions to enable cross faction play
Assist tank will now actually tank adds on friendly ship
Dps will properly jump to attack mage and go back to their ship, if
stuck on enemy ship /p reset, /p summon or /p follow
fixed trigger for cannons, if cannons are frozen bots wont try to mount
them anymore which prevented them from attacking mage properly
bots will use rocket packs to jump to and from enemy ship instead of
teleporting
Main tank will now jump 1st. tank enemy boss and wait until all bots
have jumped back before he jumps back
All bots will wait for main tank to engage enemy captain before jumping
to enemy ship
Cannons will focus rockets 1st, then other adds now (for when gs gets
scripted)
Rdps will focus nearby adds on enemy ship and mark with star rti icon
when there is no deep freeze
todo: remove tanking bypass when core fixes enemy ship boss threat
reseting
Tested crossfaction on horde with single ally bot, ally bot did
everything right, need to test more.
note horde side is heavily bugged due to threat issue of adds, tanks
cant take threat, on ally its somewhat ok, on horde rip. Horde is
doable, but annoying cus of threat issue.
Tested on ALL diffs
DBS
Remade tank taunt logic, tanks should now properly taunt boss and let
other tank taunt it if they get rune of blood
Tanks will tank adds better now, no loose adds anymore
Tested on ALL diffs
Dogs
Remade tank taunt logic, tanks should now properly taunt boss and let
other tank taunt it if they get 8 mortal wounds stacks
Tanks will tank adds better now, no loose adds anymore
Tested on ALL diffs
Festergut
Hunters sometimes populated row 0 which would make them in melee range
of the boss (bad for dps). They should pick correct rows now
Healers will populate row 0 1st then other rows for optimal healing
position
Ranged bots should properly choose unique spots to avoid stacking when
there is no spore present
Remade tank taunt logic, tanks should now properly taunt boss and let
other tank taunt it if they get 6 gastric bloat stacks
Changed ranged spore position closer to boss
Spore bots should be able to attack/do non movement action when they
have spore and are in position
Solved malleable goo detection via direct boss hooks to detect boss
targets!
Tested on ALL diffs
Rotface
Tanks should not fight over big ooze anymore
Improved big ooze kiting
Improved small ooze stacking logic (when no big ooze present, stack at
small ooze position, when big ooze is present move to it)
Fixed edge cases when main and assist tank get small ooze (they used to
move to big ooze, that was really bad since main tank would start to
tank big ooze and get hit by big ooze, assist tank would stop kiting and
get hit by big ooze)
stopped mutated plague from dispelling instantly (as fight goes on,
rotface cast mutated plague more and more, thus making it impossible to
pass due to sheer numbers of small oozes and big oozes on the map, this
will delay their spawning and give enough time for bots to handle them
properly)
Fixed edge case of multiple small oozes and big oozes being alive at
same time (bots would detect wrong oozes and wipe raid or get stuck)
Improved flood avoidance
Improved ranged positioning in heroic mode, instead of letting them
choose positions (which is a nightmare on dynamic fight as rotface, they
now will choose 1 spot of 22 premade ones and populate them based on
guid and adopt spot based on flood position)
Improved Explosion avoidance by making bots remember their starting
position so that they can return to it after big ooze explode, their
movement is not chaotic anymore, and improved timers, they will wait 2
sec at new position before returning to starting position so that they
can avoid explosion projectiles properly, they should also avoid moving
to other bots starting positions.
These changes ensure minimal movements so that bot can do maximum dps
possible.
Tested on ALL diffs
PP
Fixed many logic conflicts that caused bots to freeze, do bad dps to
ooze/clouds
Fixed triggers and multipliers
Improved Gas Cloud avoidance, bloated bot will now remember its previous
position to avoid backtracking/getting stuck in corners
Added boss hooks to finally detect malleable goo, it is not an npc,
object or creature and PP doesn't target anyone, bots will flee from it
now
Boss stacking now only in last phase
Added cheats for players also (if enabled in cfg) only bots used to get
auras
Fixed tank switching in last phase, atm PP doesn't apply aura, but it
should work, since same logic works for dogs, festergut and dbs
Assist tank will now become abo if there is no abo before first puddle
appears
Abo will during puddles, slow oozes, slash boss & oozes
In last phase assist will return to normal
Tested on ALL diffs
Edit 19.5. :
Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world
cfg ICC buff on max (30%)
Tanks switched in last phase flawlesly and shared stacks as they should
(mutated plague got fixed in core)
In short cleared PP without ICC cheats with bis gear but unoptimized
enchants, talents, gems. I still recommend using ICC cheats for better
and fun experience.
BPC
Added center position to prevent bots from pulling BQL or other adds
when they glitch thru walls/floor and thus resetting raid back to icc
entrance teleporter
Added additional z axis resetting since bots like to "fly" up in the air
when attacking kinetic bombs.
using cheat bypass for ball of inferno flames (atm bugged, doesn't
shrink), bots will simply kill them when they spawn.
Improved tanking for main tanks, improved collection of dark nuclei for
assist tank
Improved kinetics bomb handling
Improved shock vortex spreading
Improved valaran spreading for ranged
Added shock vortex (non empowered) detection to avoid it while moving
into safe positions
Fixed jittery movement
Tested on ALL diffs
BQL
Removed center position block so that bots can spread our easier in 25
mode, not ideal but makes 25hc easier
Replaced repulsion based spreading, now each bot will have its own spot
and move if needed to new spot
Improved air phase spreading
Fixed assist tank taking 1st bite
Tested on ALL diffs
VDW
Due to recent core changes bots got bugged in portals if no real player
entered and changed Z axis, if there was no z axis change bots would
chill under the cloud on the ground and do nothing. I could not figure
out how to fix this (thus breaking immersion) without force teleporting
them to the clouds.
Bots that go into portals will now teleport at the same time to clouds
instead of following leader bot.
Added feature that if players enter the portal, player with lowest guid
will become bot "leader" and they will follow that player so that there
is at least a little bit of immersion left.
Fixed cloud collection for Heroic Mode, bots will now time clouds more
precisely to avoid loosing stack due to not picking them up
Improved RTI marking
Improved group splitting
Improved zombie kiting and avoiding explosion
Tested on ALL diffs
Sindragosa
Bots will mark tomb positions with red smoke bomb in air phase so that
real player know where to go with when beacon on them
in last phase they will mark with blue smoke tomb position
Fixed tank positioning
Fixed wrong tomb choice and positioning
Fixed tomb marking
In last phase healers will stack with melee to allow boss healing
In last phase when waiting for mystic debuff to pass, bots will damage
tomb like in air phase to speed up the kill
todo: tank switch to reset mystic buffet stacks
Tested on ALL diffs
Edit 19.5. :
Tested 25hc with autogear bis gear, playebots cfg ICC cheats off, world
cfg ICC buff on max (30%)
In short cleared LDW without ICC cheats with bis gear but unoptimized
enchants, talents, gems. I still recommend using ICC cheats for better
and fun experience.
LK
Changed add gathering logic for 1st phase and winter phase, instead of
tank moving to shamblings, he will keep taunting until they agro him.
necrotic plague is easy now, ditched complex timing logic for a simple
logic ( move to shambling, wait until dispeled, go back. Healers dont
dispel until defile ally is near shambling )
Fixed winter phase gathering logic, assist tank will now properly move
to raging spirits asap and bring them to main tank, melee dps will no
properly move behind/flank spirits and shamblings to avoid instant
death. Rdps will now properly focus frost orbs and adds, Transition
should also be smoother now, but still needs /p reset if they get stuck.
Other phases are ok, LK fight is now even better than before, but player
still need to know tactics and use multibot addon to help out bots when
needed, especially during defile phase since its random and position
matter for valkyrs and future defiles
Non winter phase AT will collect raging spirits and move them to main
tank, ranged bots will keep distance, melee bots will flank them to
avoid aoe
Defile, ditched complex spreading which was mostly gamble with boss
hooks to detect defile victim. If bot, bot will move away from raid, if
real player main tank will yell Player name move away defile.
bots will stay in center now if safe from defile, raging spirits or vile
spirits
Vile spirits soaking by assist tank. Assist tank will stand between
spirits and raid and chase spirits. healers are allowed to move from
position to heal assist tank. one hunter if alive will be at center
position to place traps to slow down spirits
HC
Real players will also get buffs if cheats are enabled now
Assist tank will now never move towards the raid to gather adds, instead
it will taunt them instead so that they come to it
Assist tank will rotate shamblings at all times away from raid
Assist tank will stun shamblings before transition to avoid shockwave
wipe
Winter phase ice sphere location changed, ranged will focus sphere
faster and better now
Fixed jittery movement and low dps during winter phase
Fixed most of the bots getting stuck during winter phase
Valkyrs will be properly marked now, one by one, in hc bots will now
ignore low hp valkyrs and focus on grabbing valkyrs or boss
After winter raging spirit will have top priority for killing
After winter ranged bots will 1st handle ice spheres then skull targets
Spirit bomb avoidance improved, main tank should not back track into
unsafe positions anymore
Since real player is leader its crucial that player know the tactics,
bots can not handle edge cases during the fight alone,
they need some of reset, follow, summon here and there since its a long
fight and things can go wrong.
Tested on ALL diffs
NOTE: If server crash, bots will sometimes drop ICC strategy even though
they are in ICC, simply re enter or write /p nc +ICC to re enable.
NOTE: addons that mark icons during fight could break bots, since icons
are used for RTI by bots
NOTE: I did not use any raiding addons besides unbot and multibot to
control bots
NOTE: In theory everything should work wihout ICC buff from world cfg,
and ICC cheats from playerbots cfg, didnt test it, didnt try, its too
hard core for hc mode to go raw, but it should be possible good luck :)
NOTE: For normal about 5k gs should be enough to do most bosses. For HC
T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for
fun experience.
NOTE: As player its good to know every strategy for Bosses, so that you
can spot and help out with reset, follow, summon if bots seem stuck or
are doing something strange, a lot of stuff is happening on most fights
so expect some intervention with reset, summon, follow.
10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for
bress (its not set in stone, but most success with this setup)
25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for
bress (its not set in stone, but most success with this setup)
GL & HF, happy raiding :D
Closes#1421#2120Fixes#1219 NOTE: Not all of them, I have updated affected changes in
#1219. Trash, quest, cheats are still nice to haves, but I don't see
working on that in near future.
Before posting bugs check #1219 and write there. As I said, I dont plan
to implement certain things in near future, but I am more than willing
to fix bugs that crash server if they happen ASAP.
<!--
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.
-->
## 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.
Enter ICC
Test Bosses
bis ICC command
type bisicc into party chat or whisper and bots will reply and equip
gear
- Any required setup (e.g. multiple players, number of bots, specific
configuration).
NOTE: If server crash, bots will sometimes drop ICC strategy even though
they are in ICC, simply re enter or write /p nc +ICC to re enable.
NOTE: addons that mark icons during fight could break bots, since icons
are used for RTI by bots
NOTE: I did not use any raiding addons besides unbot and multibot to
control bots
NOTE: In theory everything should work wihout ICC buff from world cfg,
and ICC cheats from playerbots cfg, didnt test it, didnt try, its too
hard core for hc mode to go raw, but it should be possible good luck :)
NOTE: For normal about 5k gs should be enough to do most bosses. For HC
T10 set + ICC 25 nm or HC gear + gems + enchants + buffs from cfg for
fun experience.
NOTE: As player its good to know every strategy for Bosses, so that you
can spot and help out with reset, follow, summon if bots seem stuck or
are doing something strange, a lot of stuff is happening on most fights
so expect some intervention with reset, summon, follow.
10 MAN 2-3 Healers, 2 Tanks, at least 1 hunter, at least one druid for
bress (its not set in stone, but most success with this setup)
25 MAN 6-7 Healers, 2 tanks, at least 1 hunter, at least 3-4 druids for
bress (its not set in stone, but most success with this setup)
- Expected behavior and how to verify it.
If requirements are met, bots should not struggle with killing bosses
Compare to https://www.youtube.com/watch?v=nACyjn817iQ&t=460s
-->
## Impact Assessment
<!-- As a generic test, before and after measure of pmon (playerbot pmon
tick) can help you here. -->
- Does this change increase per-bot/per-tick processing or risk scaling
poorly with thousands of bots?
- - [ ] No, not at all
- - [X ] Minimal impact (**explain below**)
In theory it should not impact, didnt test with hi bot count or large
player count
- - [ ] 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?
- - [ ] No
- - [X ] Yes (**explain below**)
Impacts in raid, new actions, triggers
Impacts with new bisicc cmd that will gear bots
Everything should make it easier for maintenance since each boss is in
seperate file now
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x ] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
AI was used for analyzing code for ac code standard violations, edits
were made by me. It was used for fixing bugs, brainstorming and code
generation (for complex math problems, such as dynamicaly kiting oozes
around, assiging positions during multiple complex situations in rotface
encouter. Everything was checked and tested multiple times until it was
polished (to my abilites and understanding). It helped me to solve
Malleable goo detection, defile, by hooking directly to boss in order to
detect it, since it was detectable only by split second since it was not
npc, spell or object.
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [ x] Stability is not compromised.
- - [x ] Performance impact is understood, tested, and acceptable.
- - [x ] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [x ] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
I have not tested with multiple players, or large servers or with 3k+
bots
---------
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>
<!--
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 -->
Pull strategy migration from cmangos for tank specializations
## 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.
-->
1. Invite bot tank
2. Use `reset boAI` or `nc +pull,+pull back` + `co +pull,+pull back`
3. Order bot to pull using command `pull my target` or `pull rti target`
4. Bot should run to mob, use ranged skill and back to point where he
started pull
Without `pull back` strategy bot run to mob, use ranged skill and wait
on mob until he come to bot
## 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**)
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
Help with migration and solving some problems
<!--
TRANSLATIONS:
Anything new that the bots say in chat must be in a translatable format.
This is done using GetBotTextOrDefault,
which you can search for in the codebase to find examples. Your code
needs to have English as the default fallback,
while the full translations need to be in an SQL update file. The
languages in the file are the nine language
options supported by AzerothCore: English, Korean, French, German,
Chinese, Taiwanese, Spanish, Spanish Mexico, and
Russian. See
data/sql/playerbots/updates/2025_12_27_ai_playerbot_fishing_text.sql as
an example of a translation SQL
update, whose content are called within the codebase at
src/strategy/actions/FishingAction.cpp
-->
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] Added logic complexity is justified and explained.
- - [x] Any new bot dialogue lines are translated.
- - [ ] Documentation updated if needed (Conf comments, WiKi commands).
## Notes for Reviewers
<!-- Anything else that's helpful to review or test your pull request.
-->
Stability test after randomize new bots
<img width="465" height="172" alt="obraz"
src="https://github.com/user-attachments/assets/6e39a8c0-f23b-47cc-852a-71fa98044a31"
/>
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
<!--
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 -->
Migration for "focus heal targets" strategy which order healer to focus
only on specified targets
Commands:
`nc +focus heal targets`
`co +focus heal targets`
`focus heal +botName`
`focus heal -botName`
`focus heal ?`
## 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.
-->
- create bots party with at least one healer
- apply to healer strategy
- order healer focus on single bot
- start fight (for example with dummy)
- use `.damage 10000` to bots a watch which are healed directly and
which one only via aoe healing
## 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?
- - [ ] No
- - [x] Yes (**list messages in the table**)
| Message key | Default message |
| --------------- | ------------------ |
focus_heal_not_healer | I''m not a healer or offhealer (please change my
strats to heal or offheal)
focus_heal_provide_names | Please provide one or more player names
focus_heal_no_targets | I don''t have any focus heal targets
focus_heal_current_targets | My focus heal targets are %targets
focus_heal_cleared | Removed focus heal targets
focus_heal_add_remove_syntax | Please specify a + for add or - to remove
a target
focus_heal_not_in_group | I''m not in a group
focus_heal_not_in_group_with | I''m not in a group with %player_name
focus_heal_added | Added %player_name to focus heal targets
focus_heal_removed | Removed %player_name from focus heal targets
## AI Assistance
<!--
AI assistance is allowed, but all submitted code must be fully
understood, reviewed, and owned by the contributor.
We expect contributors to be honest about what they do and do not
understand.
-->
- Was AI assistance used while working on this change?
- - [ ] No
- - [x] Yes (**explain below**)
<!--
If yes, please specify:
- Purpose of usage (e.g. brainstorming, refactoring, documentation, code
generation).
- Which parts of the change were influenced or generated, and whether it
was thoroughly reviewed.
-->
OpenCode, to help migrate strategy
## Final Checklist
- - [x] Stability is not compromised.
- - [x] Performance impact is understood, tested, and acceptable.
- - [x] 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.
-->
From tests:
<img width="515" height="471" alt="obraz"
src="https://github.com/user-attachments/assets/ed6a2bce-e3b1-4fce-ba6f-1a2b10673c61"
/>
Its optional strategy mostly for raiders then performance is not a
issue.
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: Revision <tkn963@gmail.com>
<!--
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.
