The idea is to centralize the creation, assignment, and management of
bot guilds into a single class that can be referenced.
The way this is intended to work.
when the manager is created, if the config option to delete guilds is
set, then it deletes all bot guilds.
On startup
1. Load all guild names from database. Shuffle keys for some
randomization.
2. Load Guilds from database
3. For existing guilds, identify the guild faction, number of members,
and assess if the guild is 'full' based on the number of bots set in
config.
4. Determine if the leader of the guild is a real player based on the
leader account.
5. Mark any playerbot guild names as not available (false).
The validation process (2-5) is set to run once an hour.
Guild Creation.
Now guild creation occurs on an as needed bases during the
initialization process. Previously, all of the guilds would be created
at once, and then randomly assigned.
When a bot is not in a guild during initialization, it will check if
there are any partially filled guilds of that bots faction where the bot
can be assigned to. If not, and the cache of bot guilds is less than the
set number in config, it will randomly return the available name. This
then goes to the CreateGuild function where the core guild manager
creates a guild, the guild emblem is set, and the cache updated.
If a bot is assigned to guild, but fails to join then it throws an
error.
Checking for real player guilds function now lives in the guild manager.
---------
Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
Merging this isn't required but rather to provide an option to core
changes.
The scripts can be written from scratch when someone feels like doing it
without touching the core.
This shouldn't be merged unless
https://github.com/mod-playerbots/azerothcore-wotlk/pull/130 is merged
too.
Lines 481 through 484 are the only substantive changes. Bots were having
the potion strategy added in arenas, and since potions are not allowed
in arenas, this caused them to lock up and attempt to repeatedly drink
potions when under the applicable health or mana trigger thresholds. Now
they won't have the potion strategy in arenas.
Otherwise, I noticed a bunch of magic numbers for spec tabs and so went
ahead and did some refactoring:
1. All references to spec tab numbers now use the appropriate constant
name.
2. A bunch of extra braces were deleted.
3. DEATHKNIGHT_TAB was changed to DEATH_KNIGHT_TAB, and
HUNTER_TAB_BEASTMASTERY was changed to HUNTER_TAB_BEAST_MASTERY, to
reflect the correct names of the class and spec.
4. Deleted some comments that were clearly unneeded. There's much more
that can be cleaned up, and probably the entire logic sequence for
adding/removing strategies in AiFactory.cpp can be redone, but that's
above my pay grade.
I found an existing config option that allows bots to speak without a
master, and extended its use so that protected commands (nc, co) are
taken from a bot by GM players. This is primarily a debugging tool and
shouldnt be on generally.
My testing of this is the following.
With the option off, no error is seen, but no text output is shown.
With the option on
GM accounts (Whether GM is on or off) will respond to nc and co commands
by just saying the output directly. Strategies can be changed by GMs for
bots whom they are not masters for (Note, im pretty sure that a GM could
change the strategies even before this change, you just couldnt see the
output of that.)
For non GM characters you get "Invite me to your group first" with the
option on/off.
**Original issue:**
https://github.com/mod-playerbots/mod-playerbots/issues/1902
**Original cause:** charmed bot (with lost client control) got rooted at
the same time.
**How to reproduce:**
1. Spawn creatures 11350 (x3) and 11830 (x3) using the command: `.npc
add <entry>` in a quiet place.
2. Create any party with random bots or alt bots (should be 60-65
levels), make sure there is at least one healer.
3. Set the healer's mana to a high value, like 100M, using command:
`.mod mana <value>`.
4. Start the fight while continuously respawning creatures with: `.resp
all`.
5. When console starts to spam 'heartbeat' messages, check your party
members' movement flags to identify which one has `MOVEMENTFLAG_ROOT`
0x00000800 (2048) using the command: `.debug move`.
This PR will not fix ALL 'heartbeat' issues, as
`ServerFacade::SetFacingTo` still sends `SendMovementFlagUpdate` while
bots can have the `MOVEMENTFLAG_ROOT` flag.
These contains various fixes, fixes that have history worked one in past
more then once as person as group, aswell @Wishmaster117. But due
various reasons we had to drop them due priority or simply timewise.
These fixes have recollected again by @Regrad based on his crash logs.
Most crash logs we have, i am talking 30+ of them, to many to post here.
@Regrad running a larger server 100+ real players with bots, which means
he will walk into issues that most of us wont or are extremely difficult
to reproduce.
@Regrad used LLM to solve them based on crash log and mentioned his
server crashes almost disappeared, instead of redoing every single PR
and pull them apart. I tried to keep his bunch of changes together as
whole, reviewed them, some redone, verified again etc etc. This is not
how would normally do this. But since i want @Regrad being able to
confirm, we need this in a package as a whole. Pulling them apart in the
current situation is simply to much, to complicated in the verification
process.
So this PR is open and in my opinion has priority above others, but
@Regrad is only person who can give the green light for the
mod-playerbot changes for now.
I, we spend huge amount of time into these issues over last couple of
months. I will put other PR's on hold for abit.
---------
Signed-off-by: Engardium <regradius@gmail.com>
Co-authored-by: Engardium <regradius@gmail.com>
I removed bots checking if they should leave group every tick, and will
rely on the LeaveGroupFarAway action. I also increased the timer from 5
seconds to 20 seconds. No need to check this that often.
Fix the naming conventions.
Master should be reserved to identify a bots Master.
groupleaders are not necessarily group masters and it should be clear
what the bot is looking for. (In most solo cases leader=master)
# Description
This addresses the infamous "Possible hacking attempt" error when bots
were furiously trying to interact with despawned game objects.
The problem was that the game objects were not being as spawned when
evaluating what the bot should do. It was only done when spells were
being cast on entities.
Fix warnings: -Wsign-compare and -Wsign-compare.
I would also like to mention that there are issues with the following
methods:
`IsMainTank` -- in the last loop, it returns the result of comparing the
first alive tank it finds with the current bot, which seems odd.
`IsBotMainTank` -- it is used in only two places in the code (Yogg-Saron
strategy) and has a completely different logic for checking. In the last
loop, it only checks for a suitable tank-bot with a lower index (if it's
not the bot itself). Additionally, there is a logic issue in the loop:
if none of the conditions are met after the first iteration, the method
returns `false`.
Can someone from the maintainers take a look at this section of the code
for possible errors and logic issues?
Adds a check for if current master left the BG and group, if so release
set master and carry on in BG.
This prevents multiple bots in (potentially multiple different) BG's to
still consider you as their master when you yourself have left.
- Applies when you join BGs with a party of bots.
Fix for issue #1768 where the bot master was not getting reset.
I also cleaned up leave group action to focus up function scope.
I moved the resets from #612 to the actual leaving function.
Disclosure: LLMs were NOT used in authoring this PR.
Test cases to consider for testers.
1. Master disbands group with random bots. Bots should go about their
business.
2. If you can dual box, create a raid where two real player both invite
random bots. One player leaves group, their bots should also leave.
(edge case, if a random bot that is supposed to leave the group becomes
leader they may disband the whole group.
I'm marking this as a draft for now because I haven't done a detailed
review of the code, but I'm posting it now in case anybody wants to give
it a try.
Here's what the strategy (should) do.
### **Channeler Phase**
While you can probably AoE down all five Hellfire Channelers, that's
more dicey with IP nerfs and it's no fun, so the strategy takes what
would have still been considered an aggressive approach back in the day
by (1) assigning the Main Tank to the first Channeler, (2) having
Hunters misdirect two more Channelers to the MT, and (3) one Off Tank
picking up each of the fourth and fifth Channelers and dragging them out
of Shadow Volley Range from the main group. Sometimes the pull gets a
little wonky and one of the OTs might end up with one of the Channelers
that was intended for the MT, but it should work out in the end.
DPS will move through Channelers from Square -> Star -> Circle ->
Diamond -> Triangle. Once Square, Star, and Circle are down, the MT will
go sit by Magtheridon and wait for him to become active instead of
helping with the last two Channelers. I could have made the MT help with
the fourth Channeler too, but it's not needed, and positioning to pick
up Magtheridon after the third Channeler is a failsafe for low DPS
groups that aren't able to get four down before Magtheridon breaks free.
The top priority for Warlocks is to banish/fear the Burning Abyssals,
and they will continue to do so even after Magtheridon becomes active
(you are not supposed to kill the Abyssals; they have a gazillion HP and
automatically despawn after a minute). Their next priority is to put
Curse of Tongues on the Channelers.
### **Magtheridon Positioning**
The MT will pick up Magtheridon and pull him (moving backwards because
Magtheridon kind of hits like a bus) to a position up against the far
wall. Ranged DPS will spread out from a point roughly in the center of
the room, and Healers will spread out from a point that is a little
closer to Magtheridon. I have not built in aoe avoidance (except for
cube clickers, see below) because the general avoid aoe strategy seems
to work fine for this fight.
### **Clicking Manticron Cubes**
Now, the fun part. Bots will be assigned to clicking cubes by standard
group selection order (reverse join order), but assignment is done via
two passes. The first pass will look to select five ranged DPS bots that
are _not_ Warlocks. This is because Warlocks may still be needed to keep
Abyssals banished/feared and because Warlocks of all three specs put out
by far the most damage of all ranged DPS at level 70 in pre-raid/T4
gear. If there are not five non-Warlock ranged DPS bots available, then
the logic goes to the second pass, which can pick any bot that is not a
Tank.
Cube clicking works on a timer:
1. 48 seconds after Magtheridon breaks free, assigned cube clickers move
near their cubes (but a few yards outside of interact distance). During
this time, they should move around still to avoid Debris (by maintaining
distance from the triggering NPC) and Conflagration (by maintaining
distance from the triggering gameobject). Blast Nova is on a 54.35s to
55.4s timer, and I found 48s to always be ample time to get to the
cubes, but YMMV so this is a good thing to test. Going to a cube too
early not only takes away DPS but also risks more hazards appearing
on/around the cube that will then cause problems when the cube needs to
be clicked.
2. Blast Nova is a 2s cast, followed by a 10s channel (if not
interrupted by the cubes). As soon as the cast begins, bots will move
into interaction range and click the cube. Well, there is a randomized
delay between 200ms (about the fastest possible human reaction time to
visual stimuli) and 1500ms. It didn’t happen to me in a few runs, but it
may be possible that the delay causes the raid to eat one tick of Blast
Nova (I’m not sure if the first blast comes as soon as the channel
starts). Again, another good thing to test, but also one tick is not
going to kill anybody, and it’s arguably good to introduce some degree
of imperfection.
3. Once Blast Nova stops channeling (i.e., all five cubes have been
clicked and channeled simultaneously), bots will interrupt their cube
clicking and go back to regularly scheduled activities. Again, I’ve
introduced a randomized delay, this time between 200ms and 3000ms. Note
that bots can easily be perfect at this—if I don’t do the randomized
delay, they click and let go so fast that you can barely even see the
beams appear. It’s so atrocious for immersion that I consider the lack
of any randomization to be totally unacceptable for this strategy.
4. 48s after Blast Nova, bots will go back to their near-cube positions,
rinse and repeat.
If an assigned cube clicker dies, another bot should be immediately
assigned. All bots in the raid track the same timer so the new bot
should step into the prior bot’s shoes. Of course, if Blast Nova is
about to go off and a clicker dies next to a cube, you’re probably
wiping because I didn’t assign backups to stand in place. That’s too
much of a dad guild-level strategy even for me.
And that’s about it. Figuring out the cubes was a tremendous pain in the
ass, but I’ve really enjoyed the learning process.
---------
Co-authored-by: bash <31279994+hermensbas@users.noreply.github.com>
* Implement Gruul's Lair strategy
* minor non-gameplay tweaks to code
* Use multiplier for tank assist
* HKM warlock & Gruul tank tweaks
* Fixed declarations
* rewrote HKM + minor Gruul tweaks
* Update PlayerbotAI.cpp
* modernize code and address comments
* clean ups to tank logic
* Oops.
* Remove post-move delay
For actions like positioning bosses, the standard post-movement delay should be overridden IMO since a player would be sequencing their actions in this type of situation
* Update RaidGruulsLairActions.cpp
* Replace break statements with return true
* enum class to enum
* moved all isuseful checks to triggers
* Split multipliers and improved banish logic
* Update for comments
* changes to int
* use helpers for marking icons
* address compile errors
* correct MoveTo and use RTI helper
* address comments and rename actions/triggers
* adjust alignment of location constants
* fix some crappy returns
* allow return true when changing targets
* change indents and move enums inside namespace
* style changes, trim trailing whitespaces, address comments
* Revert "Correct side effects of merge f5ef5bd1c2 (#1512)"
This reverts commit 966bf1d6af.
* Revert "Fix ACCESS_VIOLATION in mod-playerbots: purge stale AIs, add thread-safety, and harden HasRealPlayerMaster (#1507)"
This reverts commit f5ef5bd1c2.
* Revert "[Large server fix] #1537 Serialize playerBots/botLoading with a mutex and use snapshot-based loops to fix concurrency crashes (#1540)"
This reverts commit 3fff58df1a.
* Revert "[Fix] teleport to invalid map or invalid coordinates (x , y , z 200000, o ) given when teleporting player (g UI d full type player low , name , map , x , y , z , o ) (#1538)"
This reverts commit ca2e2ef0db.
* Revert "Fix: prevent MoveSplineInitArgs::Validate velocity asserts (velocity > 0.01f) for bots, pets, and charmed units (#1534)"
This reverts commit 4e3ac609bd.
* Revert "[Fix issue #1527] : startup crash in tank target selection — add TOCTOU & null-safety guards (#1532)"
This reverts commit c6b0424c29.
* Revert "[Fix issue #1528] Close small window where the “in a BG/arena” state can change between the check (InBattleground() / InArena()) and grabbing the pointer (GetBattleground()), which leads to a null dereference. (#1530)"
This reverts commit 2e0a161623.
* Revert "Harden playerbot logout & packet dispatch; add null-safety in chat hooks and RPG checks (#1529)"
This reverts commit e4ea8e2694.
* Revert "Dont wait to travel when in combat. (#1524)"
This reverts commit ddfa919154.
* Revert "nullptr fix (#1523)"
This reverts commit 380312ffd2.
* Revert "Playerbots/LFG: fix false not eligible & dungeon 0/type 0, add clear diagnostics (#1521)"
This reverts commit 872e417613.
* Revert "nullptr exception (#1520)"
This reverts commit 3d28a81508.
* Revert "Removed bot freezing at startup and system message, not relevant anymore (#1519)"
This reverts commit bcd6f5bc06.
Bots will now add level- and spec-appropriate oils and stones when maintaining and, with respect to randombots, leveling. All bots (other than those with class-specific temporary weapon enchants) will apply oils and stones to their weapons. General clean-ups to associated code were made.
Hello everyone,
This is a fix for issue #1233
I have added a clause in the CanCastSpell check that checks if the bot is in flight form/swift flight form & not in combat. It will no longer attempt to shift into a caster form and repetitively try and heal/buff party members while flying. Tested on my PC with the changes and druid now successfully flies as fast as the player with no stopping.
This was causing the issue:
static ActionNode* thorns([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("thorns",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ nullptr,
/*C*/ nullptr);
}
static ActionNode* thorns_on_party([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("thorns on party",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ nullptr,
/*C*/ nullptr);
}
static ActionNode* mark_of_the_wild([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("mark of the wild",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ nullptr,
/*C*/ nullptr);
}
static ActionNode* mark_of_the_wild_on_party([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("mark of the wild on party",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ nullptr,
/*C*/ nullptr);
}
static ActionNode* regrowth_on_party([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("regrowth on party",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ NULL,
/*C*/ NULL);
}
static ActionNode* rejuvenation_on_party([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("rejuvenation on party",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ NULL,
/*C*/ NULL);
}
static ActionNode* remove_curse_on_party([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("remove curse on party",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ NULL,
/*C*/ NULL);
}
static ActionNode* abolish_poison_on_party([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("abolish poison on party",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ NULL,
/*C*/ NULL);
}
static ActionNode* revive([[maybe_unused]] PlayerbotAI* botAI)
{
return new ActionNode("revive",
/*P*/ NextAction::array(0, new NextAction("caster form"), nullptr),
/*A*/ NULL,
/*C*/ NULL);
}
The *P* stands for prior, aka before this action is taken, do this other action "caster form". This is the Caster Form action:
class CastCasterFormAction : public CastBuffSpellAction
{
public:
CastCasterFormAction(PlayerbotAI* botAI) : CastBuffSpellAction(botAI, "caster form") {}
bool isUseful() override;
bool isPossible() override { return true; }
bool Execute(Event event) override;
};
And this:
bool CastCasterFormAction::isUseful()
{
return botAI->HasAnyAuraOf(GetTarget(), "dire bear form", "bear form", "cat form", "travel form", "aquatic form",
"flight form", "swift flight form", "moonkin form", nullptr) &&
AI_VALUE2(uint8, "mana", "self target") > sPlayerbotAIConfig->mediumHealth;
}
bool CastCasterFormAction::Execute(Event event)
{
botAI->RemoveShapeshift();
return true;
}
So basically, the druid was triggering to heal/buff the party, and before it could do that, it had to switch into "caster form" which executed RemoveShapeshift(). After it did that, mounting back up into flight form/swift flight form had the highest priority, so it would loop the triggers/actions.
Hello everyone,
Back again with another class overhaul. Here is a list of what changes have been made:
1. Consolidated the AoE strategies into "aoe". For light aoe (2+ enemies) the mage will use Cone of Cold (frost)/Arcane Explosion (Arcane)/Multi-Dot with Living Bomb (Fire/Frostfire). For medium aoe (3+ enemies) they will use Flamestrike -> Blizzard. Also, the mage will automatically cancel channeling their blizzard if there is less than 2 enemies around. This is huge, since the mage would often stand there and finish their entire channel during a boss fight after the adds died.
2. Organized actions, triggers, and the aiobjectcontext
3. Enabled Deep Freeze to be casted on bosses regardless of their immune status. Big benefit for frost dps on boss fights.
4. Slight tweaks in the conf so Arcane gets Arcane Barrage and Frostfire gets 2/2 Firestarter
5. Streamlined Arcane DPS to use Missile Barrage proc when at 4 stacks of Arcane Blast
5. Streamlined Fire/Frostfire DPS to keep Improved Scorch active (5% spell crit) unless there is a debuff of equal type
6. Added "firestarter" strategy, that utilizes the Fire talent Firestarter better. The mage will multi-dot Living Bomb while running towards melee, and cast Dragon's Breath -> instant cast Flamestrike -> Blast Wave -> instant cast Flamestrike -> Blizzard for bonkers damage. Disabled by default - not everyone wants their mages running into melee. Enable by typing "co +firestarter" on fire and frostfire mages.
7. Streamlined Frost DPS by finally adding support for Cold Snap for mages. It will proc when both Icy Veins and Deep Freeze are on cooldown. There is an exception to this - if the mage is level 30-59, it will not check for Deep Freeze - only Icy Veins.
8. Added Conjure Mana Gem support in the generic non-combat strategy and Use Mana Gem support in the generic combat strategy. This might be the biggest benefit of the overhaul - the gem has a 90 second cooldown, not shared with mana potions. It really prevents the mage from gassing out in longer fights. And the mana gem has 3 charges!
9. Added Mana Shield ability, which triggers on low health.
10. Changed Mirror Image from a boost ability to an anti-threat tool. Not many people know this, but it's best use in PvE is it's anti-threat modifier: "Mod Total Threat - Temporary Value: -90000000". It also doesn't do good damage, and is essentially used best as a pre-pull spell. But until the mages know how to react to a pull-timer, it's going to be used to reduce threat.
Let me know what y'all think!
