Guild manager #11
Closed
Guild manager #11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s#1713) - Move Starfall from default actions to AOE strategy only - Require 2+ enemies for Starfall usage (prevents single-target casting) - Add CC safety: avoid casting Starfall near current CC targets - Prioritize Starfall over Hurricane in medium AOE situations - Remove Starfall from pull/opener rotation to prevent early single-target usage This prevents Balance druids from wasting Starfall on single targets and breaking crowd control effects in group content.
…ayerbots#1841) ## Summary This PR fixes the Crash 1 Source from Issue [mod-playerbots#1840](mod-playerbots#1840) posted in a @Regrad posted logs, in `SeeSpellAction::Execute` when an RTSC "see spell" event arrives with an empty or malformed `WorldPacket`. In that case the code used to read from the packet without any validation, causing a `ByteBufferException` and a crash in the map thread. ## Fix - Reset the packet read position and check that the RTSC header (castCount + spellId + castFlags) fits into the packet before reading. - Wrap `SpellCastTargets::Read` in a `try { } catch (ByteBufferException const&) { }` block so truncated RTSC payloads are handled gracefully. - Check that `targets.GetDst()` is not `nullptr` before accessing its position. For valid RTSC packets the behavior is unchanged; malformed packets are now safely ignored instead of crashing the server. ## Testing - Sent bots to multiple locations using RTSC and verified they still move as before. - Reproduced the previous crash scenario with malformed RTSC packets: the worldserver no longer crashes and the event is simply ignored. --------- Co-authored-by: bash <hermensb@gmail.com> Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
I've had this problem for a long time, my bots only speak English even though I'm playing on a French client. I suppose this must be the case for some other people who do not have a large number of players with the same local client. If we use French DBCs, the bots bug because they only recognize US DBCs. From what I understand, the language is chosen as follows: On load, the module reads the entire `ai_playerbot_texts` table and stores each text variant in a dictionary indexed by the locale ID: the `text` column remains the default value (English), and the `text_loc1` to `text_loc8` columns fill slots 1 through 8. Whenever a real player connects, the module increments a counter for that player's DBC locale using `AddLocalePriority(player->GetSession()->GetSessionDbcLocale())`. When a bot needs a text, `GetLocalePriority()` returns the most frequently used locale index among currently connected players. The corresponding string is then retrieved. if the box is empty, we fall back to the English version (text[0]). ### This PR improve language detection. **Summary** - log both the client DBC locale and the account database locale when a player logs in - fall back to the account locale when the client reports enUS but the account is configured for another locale - keep the existing vote-based selection so bots always speak the majority language among connected players **Therefore, the original behavior is maintained. Bots still choose the most represented language among connected players (the counter is simply more efficient by prioritizing the account's locale when it differs from the client's English). For example, if more English-speaking players are connected, the language will revert to English, as the bots always share the majority locale.**
fixes mod-playerbots#1854 ----- Also includes fixes for: ----- * Bots swimming with waterWalk kept switching between swimming and walking, as result jittering effect swimming under water when water walking active * Bots flying close above water they would land on water and start walking, now they stay flying unless on solid ground they will land and start walking by design ----- Moved all flag setting to updateMovementState: * So all movement flag are handled in updateMovementState which also contains the restricted movement logic. * Handle restricted movement logic and preventing SendMovementFlagUpdate while being restricted. ----- Known issue when flying the following bots feel a bit jittering, wont touch for now at least till core movement changes quirks has been dealt with. The current code is the extended version of what is originally was before core merge with refactored movements. Once the core movement refactors are settled a bit more i would like to revisit this code; as i would expect more imperative code and less manual flag setting e.g. bot->SetWaterWalking, SetGravitiy..SetCanFly etc.
Fixes crashes and race conditions when bots perform group/guild/arena operations by moving thread-unsafe code to world thread. Potentially fixes mod-playerbots#1124 ## Changes - Added operation queue system that runs in world thread - Group operations (invite, remove, convert to raid, set leader) now queued - Arena formation refactored to use queue - Guild operations changed to use packet queueing ## Testing Set `MapUpdate.Threads` > 1 in worldserver.conf to enable multiple map threads, then test: - Group formation and disbanding - Arena team formation - Guild operations (invite, promote, demote, remove) - Run with TSAN cmake ../ \ -DCMAKE_CXX_FLAGS="-fsanitize=thread -g -O1" \ -DCMAKE_C_FLAGS="-fsanitize=thread -g -O1" \ -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=thread" \ -DCMAKE_INSTALL_PREFIX=/path/to/install \ -DCMAKE_BUILD_TYPE=RelWithDebInfo build export TSAN_OPTIONS="log_path=tsan_report:halt_on_error=0:second_deadlock_stack=1" ./worldserver The crashes/race conditions should no longer occur with concurrent map threads. ## New Files - `PlayerbotOperation.h` - Base class defining the operation interface (Execute, IsValid, GetPriority) - `PlayerbotOperations.h` - Concrete implementations: GroupInviteOperation, GroupRemoveMemberOperation, GroupConvertToRaidOperation, GroupSetLeaderOperation, ArenaGroupFormationOperation - `PlayerbotWorldThreadProcessor.h/cpp` - Singleton processor with mutex-protected queue, processes operations in WorldScript::OnUpdate hook, handles batch processing and validation --------- Co-authored-by: blinkysc <blinkysc@users.noreply.github.com> Co-authored-by: SaW <swerkhoven@outlook.com> Co-authored-by: bash <hermensb@gmail.com>
…tegies (mod-playerbots#1867) Lol oops. Confirmed with logs/in-game that the prior one was wrong (and thus always returning false) and current one is correct.
…yerbots#1838) First stab at getting this working. Im not sure if Im missing something, but it seemed to be a pretty simple change overall. Based on testing the bots do respond to commands via whisper and group. Edit: Relevant PR this addresses. azerothcore/azerothcore-wotlk@50f8f14#diff-baadebd8cd1117ca48225f316a5ab3fd5fd55b20963394d302341147183db067
Temp Hotfix to resolve mod-playerbots#1870.
Well, I hope nobody has tried Magtheridon lately. It looks like this got inadvertently deleted during the merge.
…ots#1875) 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)
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.
This is my first attempt of implementing playerbot strategies. A team of 40 can steamroll Molten Core relatively easy, even with lower item levels. Regardless, this PR adds resistance triggers and actions to mitigate some damage. Additionally, improvements were made for the encounters with Garr, Baron Geddon, Shazzrah and Golemagg. A short summary per boss is listed below. All planned features are included, but feedback is of course appreciated. ### Lucifron - Shadow resistance: mitigate damage from [Impending Doom](https://www.wowhead.com/classic/spell=19702/impending-doom) and [Shadow Shock](https://www.wowhead.com/classic/spell=19460/shadow-shock). ### Magmadar - Fire resistance: mitigate damage from [Lava Bomb](https://www.wowhead.com/classic/spell=19411/lava-bomb) and [Magma Spit](https://www.wowhead.com/classic/spell=19450/magma-spit). - Like King Dred and the fraction commander (Nexus), this fight might profit from an anti-fear strategy in order to counter [Panic](https://www.wowhead.com/classic/spell=19408/panic). Not implemented here. ### Gehennas - Shadow resistance: mitigate damage from [Shadow Bolt](https://www.wowhead.com/classic/spell=19728/shadow-bolt) and increase the chance to resist [Gehennas' Curse](https://www.wowhead.com/classic/spell=19716/gehennas-curse). ### Garr - Fire resistance: mitigate damage from the Firesworn adds ([Immolate](https://www.wowhead.com/classic/spell=20294/immolate) and [Eruption](https://www.wowhead.com/classic/spell=19497/eruption)). - Disabled dps aoe abilities via multiplier. This one is important because multiple exploding adds at once might delete bots rather quick... ### Baron Geddon - Refactored the existing strategy. - Fire resistance: mitigate damage from [Ignite Mana](https://www.wowhead.com/classic/spell=19659/ignite-mana), [Inferno](https://www.wowhead.com/classic/spell=19695/inferno) and [Living Bomb](https://www.wowhead.com/classic/spell=20475/living-bomb). - Better Inferno handling: Before moving away, bots stop attacking and interrupt their spells. Additionally, the new multiplier prevents bots from running back to Geddon while Inferno is still active. ### Shazzrah - Ranged bots now position themselves in a sweet spot that prevents them from getting hit with [Arcane Explosion](https://www.wowhead.com/classic/spell=19712/arcane-explosion) but still close enough to dps and heal. ### Sulfuron Harbinger - Fire resistance: mitigate damage from [Hand of Ragnaros](https://www.wowhead.com/classic/spell=19780/hand-of-ragnaros) and [Immolate](https://www.wowhead.com/classic/spell=20294/immolate). To be fair, this one is quite negligible... ### Golemagg - Fire resistance: mitigate damage from [Magma Splash](https://www.wowhead.com/classic/spell=13880/magma-splash) and [Pyroblast](https://www.wowhead.com/classic/spell=20228/pyroblast). - Disabled dps aoe abilities via multiplier. Kind of a preference on my side. Otherwise, the Core Ragers spam emotes about not wanting to die. ### Majordomo Executus - Shadow resistance: mitigate damage from [Aegis of Ragnaros](https://www.wowhead.com/classic/spell=20620/aegis-of-ragnaros), [Shadow Shock](https://www.wowhead.com/classic/spell=20603/shadow-shock) and [Shadow Bolt](https://www.wowhead.com/classic/spell=21077/shadow-bolt). This one is also negligible, TBF. ### Ragnaros - Fire resistance: mitigate damage from [Wrath of Ragnaros](https://www.wowhead.com/classic/spell=20566/wrath-of-ragnaros) and [Lava Burst](https://www.wowhead.com/classic/spell=21158/lava-burst).
…1829) Stripped down version of mod-playerbots#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.
…ts#1789) # Fix: Arena PersonalRating and MMR issue for bot teams ## Problem Bot arena teams are created with artificial random ratings (1000-2000 range), but when bots join these teams, their personal ratings and matchmaker ratings (MMR) use default config values instead of being adjusted to match the team's artificial rating. This causes matchmaking issues since the system uses personal ratings for queue calculations. ## Root Cause The issue occurred because `SetRatingForAll()` was called during team creation but only affected the captain. When additional bots were added later via `AddMember()`, they received default values from `CONFIG_ARENA_START_PERSONAL_RATING` and `CONFIG_ARENA_START_MATCHMAKER_RATING` instead of values appropriate for the team's artificial rating. ## Solution After bots are added to arena teams, the fix: 1. Uses `SetRatingForAll()` to align all personal ratings with team rating 2. Adjusts matchmaker ratings based on team context vs default configuration 3. Saves changes to both database tables with proper data types ## Impact - Personal ratings now match team ratings for artificial bot teams - MMR values are adjusted for artificial bot team ratings instead of using default config values - Arena matchmaking functions correctly for bot teams with random ratings - Only affects new arena team assignments after deployment - Existing player teams and normal config behavior are unaffected ## Manual Database Update For existing installations, the provided SQL script could be used to fix bot teams created before this patch. ### Update personal rating ```sql UPDATE arena_team_member atm JOIN arena_team at ON atm.arenaTeamId = at.arenaTeamId JOIN characters c ON atm.guid = c.guid JOIN auth.account a ON c.account = a.id SET atm.personalRating = at.rating WHERE a.username LIKE 'rndbot%' AND atm.personalRating != at.rating; ``` ### Update MMR for existing entries ```sql UPDATE character_arena_stats cas JOIN characters c ON cas.guid = c.guid JOIN auth.account a ON c.account = a.id JOIN arena_team_member atm ON cas.guid = atm.guid JOIN arena_team at ON atm.arenaTeamId = at.arenaTeamId SET cas.matchMakerRating = GREATEST(at.rating, 1500), -- Use team rating or 1500 minimum cas.maxMMR = GREATEST(cas.maxMMR, cas.matchMakerRating) -- Update maxMMR if needed WHERE a.username LIKE '%rndbot%' AND ( -- Update if MMR doesn't match team context (at.rating > 1500 AND cas.matchMakerRating < at.rating) OR (at.rating <= 1500 AND cas.matchMakerRating != 1500) OR cas.matchMakerRating IS NULL ) AND ( -- Map arena team type to character_arena_stats slot (at.type = 2 AND cas.slot = 0) OR -- 2v2 teams use slot 0 (at.type = 3 AND cas.slot = 1) OR -- 3v3 teams use slot 1 (at.type = 5 AND cas.slot = 2) -- 5v5 teams use slot 2 ); ``` ### Insert missing MMR records for bots without character_arena_stats entries ```sql INSERT INTO character_arena_stats (guid, slot, matchMakerRating, maxMMR) SELECT atm.guid, CASE WHEN at.type = 2 THEN 0 -- 2v2 -> slot 0 WHEN at.type = 3 THEN 1 -- 3v3 -> slot 1 WHEN at.type = 5 THEN 2 -- 5v5 -> slot 2 ELSE 0 END as slot, GREATEST(at.rating, 1500) as matchMakerRating, GREATEST(at.rating, 1500) as maxMMR FROM arena_team_member atm JOIN arena_team at ON atm.arenaTeamId = at.arenaTeamId JOIN characters c ON atm.guid = c.guid JOIN auth.account a ON c.account = a.id WHERE a.username LIKE '%rndbot%' AND NOT EXISTS ( SELECT 1 FROM character_arena_stats cas2 WHERE cas2.guid = atm.guid AND cas2.slot = CASE WHEN at.type = 2 THEN 0 WHEN at.type = 3 THEN 1 WHEN at.type = 5 THEN 2 ELSE 0 END ) AND at.rating > 0; ``` ## Related issues Fixes: mod-playerbots#1787 Fixes: mod-playerbots#1800 ## Verification Queries ### Query 1: Check personal rating alignment ```sql SELECT 'Personal Rating Check' as check_type, COUNT(*) as total_bot_members, SUM(CASE WHEN atm.personalRating = at.rating THEN 1 ELSE 0 END) as correct_ratings, SUM(CASE WHEN atm.personalRating != at.rating THEN 1 ELSE 0 END) as incorrect_ratings, ROUND(AVG(at.rating), 2) as avg_team_rating, ROUND(AVG(atm.personalRating), 2) as avg_personal_rating FROM arena_team_member atm JOIN arena_team at ON atm.arenaTeamId = at.arenaTeamId JOIN characters c ON atm.guid = c.guid JOIN auth.account a ON c.account = a.id WHERE a.username LIKE '%rndbot%'; ``` ### Query 2: Check MMR alignment ```sql SELECT 'MMR Alignment Check' as check_type, COUNT(*) as total_mmr_records, SUM(CASE WHEN at.rating > 1500 AND cas.matchMakerRating >= at.rating THEN 1 WHEN at.rating <= 1500 AND cas.matchMakerRating = 1500 THEN 1 ELSE 0 END) as correct_mmr, SUM(CASE WHEN at.rating > 1500 AND cas.matchMakerRating < at.rating THEN 1 WHEN at.rating <= 1500 AND cas.matchMakerRating != 1500 THEN 1 ELSE 0 END) as incorrect_mmr, ROUND(AVG(at.rating), 2) as avg_team_rating, ROUND(AVG(cas.matchMakerRating), 2) as avg_mmr, ROUND(AVG(cas.maxMMR), 2) as avg_max_mmr FROM arena_team_member atm JOIN arena_team at ON atm.arenaTeamId = at.arenaTeamId JOIN characters c ON atm.guid = c.guid JOIN auth.account a ON c.account = a.id JOIN character_arena_stats cas ON atm.guid = cas.guid WHERE a.username LIKE '%rndbot%' AND ( (at.type = 2 AND cas.slot = 0) OR (at.type = 3 AND cas.slot = 1) OR (at.type = 5 AND cas.slot = 2) ); ``` ### Query 3: Detailed team-by-team analysis ```sql SELECT at.arenaTeamId, at.name as team_name, at.type as team_type, at.rating as team_rating, COUNT(atm.guid) as member_count, GROUP_CONCAT(DISTINCT atm.personalRating) as personal_ratings, GROUP_CONCAT(DISTINCT cas.matchMakerRating) as mmr_values, CASE WHEN COUNT(DISTINCT atm.personalRating) = 1 AND MIN(atm.personalRating) = at.rating THEN 'OK' ELSE 'MISMATCH' END as personal_rating_status, CASE WHEN COUNT(DISTINCT cas.matchMakerRating) = 1 AND ( (at.rating > 1500 AND MIN(cas.matchMakerRating) >= at.rating) OR (at.rating <= 1500 AND MIN(cas.matchMakerRating) = 1500) ) THEN 'OK' ELSE 'MISMATCH' END as mmr_status FROM arena_team at JOIN arena_team_member atm ON at.arenaTeamId = atm.arenaTeamId JOIN characters c ON atm.guid = c.guid JOIN auth.account a ON c.account = a.id LEFT JOIN character_arena_stats cas ON atm.guid = cas.guid AND cas.slot = CASE WHEN at.type = 2 THEN 0 WHEN at.type = 3 THEN 1 WHEN at.type = 5 THEN 2 ELSE 0 END WHERE a.username LIKE '%rndbot%' GROUP BY at.arenaTeamId, at.name, at.type, at.rating ORDER BY at.rating DESC; ```
…ayerbots#1857) # Description This PR changes the way loot rolls are being evaluated. It puts a maximum priority on the loot action so it does not hang for so long.
This PR completely refactors the Karazhan raid strategies to clean up the code and polish up/introduce new strategies, including for Nightbane. General changes with respect to the code: - Moved gating checks for action methods to triggers instead of relying on isUseful functions - Got rid of the nonsensical helper class I made and switched to a helper namespace - Broke up some longer action classes into separate methods and/or private members - Deleted/consolidated some excess code - Made greater use of early returns - Renamed methods, multipliers, and triggers to make them easier to understand - Generally made edits to conform with AC code standards Below are the implemented strategies. I’m including all of them, not just new/modified ones, because I don’t think the first set of strategies was ever tested. So each boss could probably use complete testing. ### **Trash** I added strategies for a trash mob that I find particularly annoying: - Mana Warp: These are, IMO, the most annoying trash mobs in Karazhan. They blow up when low on health, and having two blow up in quick succession is enough to take out a decent chunk of your raid. The strategy directs bots to use pretty much every stun in the book on Mana Warps when they’re low on HP, which is the only way to prevent the explosion. ### **Attumen** - During the first phase, bots will focus on Midnight (taking either Midnight or Attumen to 25% starts the next phase). When Attumen spawns, the assist tank will pick him up and move him away so that bots don’t get cleaved. - When Attumen mounts Midnight, starting phase 2, threat is wiped, and bots will pause DPS for a few seconds to allow the main tank to get aggro. All bots, other than the main tank and any bot that pulls aggro, will stack behind Attumen (~6 yards for ranged so Hunters can still attack). ### **Moroes** - As before, bots will mark and prioritize adds and the boss in the recommended kill order: Dorothea, Catriona, Keira, Rafe, Robin, Crispin, and Moroes. In practice, the enemies will probably be stacked up, and the bots will AoE them down in accordance with their typical AoE strategies, but classes without AoE capabilities should still prioritize the skull. - Based on testing feedback, added a method for the main tank to prioritize Moroes ### **Maiden of Virtue** I’ve made only minor changes to Revision’s original strategy here. - The tank with aggro will position Maiden in the middle of the room and move her to a healer when Repentance is cast so that the Holy Ground will break the healer’s stun. - Ranged bots have assigned positions between the columns around the middle of the room (to prevent chain damage from Holy Wrath). ### **The Big Bad Wolf** - The tank with aggro brings the boss to the front left of the stage. - If a bot gets turned into Little Red Riding Hood, it will run around the stage in a counter-clockwise rectangle until the transformation fades. I tweaked this strategy a bit; it's still not perfect, but it works better than before. ### **Romulo and Julianne** There are no substantive changes to this strategy. As before, in phase 3, when both bosses are active, the bots switch back-and-forth between the bosses by alternating the skull icon based on which boss has lower HP (10% differential). ### **The Wizard of Oz** There are no substantive changes to this strategy. As before, bots mark the bosses with a skull icon in their recommended kill order: Dorothee, Tito (assuming he spawns before you kill Dorothee), Roar, Strawman, Tinhead, and the Crone. Additionally, Mages will spam Scorch on Strawman to daze him. ### **The Curator** - The tank will drag the boss to a fixed spot down the hallway. Ranged bots will spread out to avoid chain damage from Arcing Sear, and bots will mark Astral Flares with the skull icon to prioritize them down. - Those strategies already existed, but now I made the assist tank also focus on the boss to try to stay second in aggro and therefore absorb Hateful Bolts. - Added a multiplier to save Bloodlust/Heroism until Evocation. ### **Terestian Illhoof** There are no substantive changes to this strategy. The bots will mark targets with the skull icon in the following order: Demonic Chains, Kil'rek, and Illhoof. ### **Shade of Aran** I redid the strategies a bit, and I think (hope) they work better. - Flame Wreath: Bots will stop moving until the aura fades. There is a bug in which Flame Wreath will sometimes persist long beyond its supposed 20-second duration. If Aran casts Arcane Explosion during this time, you will almost certainly wipe, so that’s frustrating. I made it so that bots will stay in place still and eat the Arcane Explosion because it’s the lesser of two evils, and if you are overgeared, you may be able to survive. In the previous strategy, bots would stop actions entirely, but now they should keep attacking/casting without moving. - Arcane Explosion: No substantive changes here--bots will run out immediately and stay out of range until the cast finishes. - Conjured Elementals: No substantive changes here--they will be marked one-by-one by the skull icon, except that the marking will skip any elemental that is banished. - Ranged Positioning: I redid this strategy. Ranged bots will now maintain a distance between 11 and 15 yards from the boss. This keeps them out of the 10-yard radius in which Aran silences while also keeping them from getting too far away and getting stuck in the alcoves. ### **Netherspite** I significantly refactored the action methods here, but substantively the original strategy remains mostly intact. - Red (Tank) Beam: One tank will be assigned to block the beam for each Portal Phase. The assigned tank will dance in and out of the beam (5 seconds in, 5 seconds out). Tanks intentionally do not avoid Void Zones (it was the lesser of two evils for them to take that damage vs. trying to dynamically avoid them, moving the boss, and possibly getting everybody out of position. - Blue (DPS) Beam: DPS other than Rogues and Warriors are eligible to be assigned (one-by-one) to block this beam. When the assigned blocker reaches 25 stacks of the debuff, they will leave the beam, and the next assigned blocker will take their place. If a Void Zone drops under the assigned blocker, the bot will move along the beam to get out of the Void Zone so that they do not stop blocking. - Green (Healer) Beam: This works the same way as the Blue Beam, except that eligible blockers are healers, Rogues, and DPS Warriors. Healers that are assigned to block will swap in the same way as Blue Beam blockers. If a Rogue or DPS Warrior is the assigned blocker, however, they will stand in the beam for the entire Portal Phase since they do not suffer any adverse effects from the beam. In this PR, I made the strategy prioritize Rogues and DPS Warriors over healers to try to avoid the need for bots to swap (and to avoid the irritating scenario in which a healer would block the beam for the first half of a phase and then tag in a Rogue or DPS Warrior, which would be wasted by blocking only half of a phase). - Non-Blockers: They will stay at least 5 yards away from each beam until called to be an assigned blocker. They will also avoid Void Zones. - Banish Phase: The only strategy I implemented was for bots to avoid residual Void Zones from the Portal Phase. - Phase Transitions: Bots should pause DPS at the beginning of the encounter and whenever Netherspite transitions back from the Banish Phase to the Portal Phase (which is an aggro reset). Note that this doesn't wipe DOTs, and there's not much I can do about that. ### **Prince Malchezaar** The action methods are significantly refactored, but the strategy substantively is not changed very much. - Bots will maintain distance from Infernals. The tank has a larger avoidance radius to give DPS a little bit of margin to work with. Depending on Infernal placement, it is possible for bots to get stuck in some bad positions. In that case, the best solution is to put them on “flee” and lead them to a better position. - Bots that get Enfeebled will run out of Shadow Nova range. They should pick a path that does not cross within any Infernal's Hellfire radius. - Added a multiplier to save Bloodlust/Heroism until Phase 3. ### **Nightbane** **Disclaimer**: Bots are terrible at this encounter, in large part because the map is awful (even before the recent Core changes). So the strategies are not ideal because they need to operate within the bots’ limitations. I STRONGLY suggest you clear the entire Livery Stables (including the upper level) because the mobs in them have a high risk of pulling through the floor of the Master’s Terrace. Ideally, you should clear out the Scullery too. The strategy uses waypoints toward the Northeastern door to the Master’s Terrace. I tried several different locations, and that worked best for me based on where Nightbane lands (note that he has a different landing spot for the encounter start vs. the start subsequent ground phases). - Ground Phase, main tank: The main tank uses two waypoints after it picks up the boss—the movement pattern should be kind of like a reverse checkmark, where the tank moves back along the inner edge of the terrace, then pivots and moves at a bit of an angle to the outer edge. I did this as a way to get the tank to face Nightbane sideways across the terrace, which is how he’s supposed to be tanked. The main tank will not get out of Charred Earth. This is intended. The tank cannot move dynamically enough to avoid it while also not turning the boss and wiping the raid. - Ground phase, ranged: Ranged bots rotate between three waypoints. They start stacked at the same position. If Charred Earth is dropped on that position, the bots will rotate to the second position. If Charred Earth is dropped on that position, they will rotate to the third position. The maximum number of Charred Earths that can be active is two, so if one is dropped on the third position, the ranged bots should rotate back to the first position. - Ground Phase, other melee: Melee bots have no coded Charred Earth avoidance strategy. They do decently enough with the general “avoid aoe” strategy. - Flight Phase: Bots move to Nightbane’s flight position—Nightbane is bugged and cannot be attacked in the air in AC, but all bots still need to stay near him or he will wipe the raid with Fireball Barrage. Bots stack on the same position; when Rain of Bones is cast (one time, snapshotted on the target’s location), all bots will move away to a second nearby position. They will then kill the Restless Skeletons. The Flight Phase lasts for 45 seconds, but Nightbane emotes after 35 seconds and goes to land—during the final 10-second period, bots are freed from all strategies and will follow the master. You need to lead them back to the Northeastern part of the terrace before Nightbane lands so that bots can get immediately positioned when he lands. - Phase Changes: Whenever Nightbane lands, bots should pause DPS for the main tank to get aggro. - Managing bots/pets: During the Flight Phase, bots and pets have a tendency to chase Nightbane outside of the boundaries of the map and pull mobs from other parts of the instance as well as cause Restless Skeletons to spawn out of bounds (and then further cause bots/pets to go out of bounds to attack the skeletons). The strategy should solve for this, but if there are still issues, it should be noted. My resolution was to implement the following: (1) when Nightbane takes flight, bots stop attacking and mark him with the moon icon, and Hunters and Warlocks put pets on passive and recall them (they will put pets on defensive again when Nightbane lands), and (2) all temporary pets are disabled for the duration of the fight (Water Elementals, Shaman wolves, Druid treants, etc.). **Known Issues:** - The approach to getting Nightbane to turn sideways is not always spot on since it’s a workaround to account for what should be dynamic movement. He can end up at a bit of an angle. I’ve tweaked the positions such that if he is at an angle, it should not be a situation in which any ranged position is exposed to Smoldering Breath or Cleave. That does increase the risk that poor positioning may expose a ranged position to Tail Sweep. This is obviously suboptimal, but that attack is much more survivable. - Ranged bots move between the three waypoints by reading the presence of the Charred Earth aura on themselves. Sometimes, a bot may reach the next waypoint with the Charred Earth aura from the previous waypoint still on them (depending on timing of ticks), in which case the bot will keep moving to the next waypoint. This can cause an issue in which the ranged group gets split. So you could have Charred Earth dropped on position 1, and some ranged bots will go to position 2 but others will go to position 3, and then if the second Charred Earth is dropped on position 3, the bots at position 3 will move back to position 1 (which is still in Charred Earth) before then moving to position 2. Balancing spacing between waypoints, positioning with respect to the boss, line of sight, and maximum distance is very difficult to do. I messed with the positioning a lot, and I am not sure if this possibility cannot be entirely avoided without creating other issues. I have at least reached a result in which I have not seen any bots cycle indefinitely (though if testing observes this, it is obviously a problem). Ultimately, I wouldn’t say I’m totally satisfied with the strategy. Wipes are still possible on account of bad RNG. But I think it does make the fight a lot more manageable, as it is a fight that is very difficult with IP nerfs in the absence of any strategy. Previously, I needed to bring 3 healers, and they would still all be out of mana by the first Flight Phase and reliant on MP5 for the remainder of the fight, and I would wipe multiple times before a kill.
Summary of ChangesHello @Celandriel, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request delivers a substantial refactor and enhancement of bot group and guild management, moving towards a more robust, thread-safe, and modular system. A key architectural change is the introduction of a dedicated world thread processor to handle operations that previously posed thread-safety risks, thereby preventing crashes and improving overall system stability. Concurrently, the bot's intelligence for the Molten Core raid has been greatly expanded, enabling more sophisticated and role-specific behaviors for various bosses. The changes also include improved localization for bot communications and a consistent renaming of group leadership terminology for better clarity. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new PlayerbotGuildMgr to centralize guild-related logic for bots, which is a great architectural improvement. It also includes a major refactoring to handle group operations in a thread-safe manner by queuing them for the world thread. Many function and value names have been updated from "master" to "group leader" for better clarity. Additionally, there are significant enhancements to the Molten Core raid strategy and various bug fixes, such as preventing a fall-through in a switch statement and improving the robustness of packet handling.
I have found a critical bug in the new PlayerbotGuildMgr that will prevent it from functioning correctly, along with some minor issues.
data/sql/playerbots/updates/2025_11_25_00_ai_playerbot_pet_action_texts.sql
Show resolved
Hide resolved
Celandriel
force-pushed
the
guildManager
branch
from
b48d28c to
d694ecb
Compare
Celandriel
force-pushed
the
guildManager
branch
from
d694ecb to
3aeca14
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.