Feature/bg strategy wintergrasp #1
Open
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
Fix error with isUseful check that caused bots not to run away from Shadow Nova when no Infernals were spawned + some tightening of code to avoid Shadow Nova
Add isUseful and check array size instead of pointer size
Introduces dedicated strategies and triggers for Wintergrasp, focusing on vehicle-centric behavior and siege objectives. Updates battleground type handling and strategy initialization to include Wintergrasp, ensuring consistent support across all relevant components.
Introduces support for Wintergrasp as an instanced battleground, including strategy handling, tactical decision-making, and pathing adjustments. - Conditionally includes Wintergrasp-specific logic based on availability. - Updates battleground strategy initialization to include Wintergrasp when enabled. - Implements minimal Wintergrasp stubs for paths and flags to prevent crashes. - Adjusts tactical behavior to pursue nearby enemies or maintain position. These changes enhance compatibility and improve bot behavior in Wintergrasp scenarios.
…le-based objective selection
…nearby friendly vehicles in Wintergrasp
…e-based movement strategies
…nearest enemy vehicles and adjust positioning for melee defenders at the gate
icemansparks
commented
Nov 4, 2025
conf/playerbots.conf.dist
Outdated
|
|
||
| # Random bots may auto-join the Wintergrasp queue (anywhere), so at war start they get teleported in. | ||
| # This simulates queuing via the Dalaran WG battlemage/gossip and fills teams when players join. | ||
| # Default: 1 (enabled) |
Collaborator
Author
There was a problem hiding this comment.
Deafult value is wrong
icemansparks
commented
Nov 4, 2025
| case BATTLEGROUND_IC: | ||
| _bgType = "IoC"; | ||
| break; | ||
| // WG is Battlefield on AC; no BG id mapping here |
Collaborator
Author
There was a problem hiding this comment.
unnecessary comment
icemansparks
commented
Nov 4, 2025
| case BATTLEGROUND_IC: | ||
| _bgType = "IoC"; | ||
| break; | ||
| // WG is Battlefield on AC; no BG id mapping here |
Collaborator
Author
There was a problem hiding this comment.
unnecessary comment
line error fixed
Update 2025_10_27_00_ai_playerbot_german_texts.sql
…als_fix Random bot guild count / generation fix
* 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
…e updates (mod-playerbots#1758) * Rewrite RandomPlayerbotFactory - rewrite constructor and utility methods, simplify checks and logic * Update the comment to clarify the original logic for race selection * Remove magic numbers from CombineRaceAndGender method (gender) * Add checks for races and classes disabled during random bot creation
* Check item score of rings/trinkets to determine the correct slot to equip * Early return, removed unecessary if statements, single line statements Simplify logic for equipping items by reducing nested conditions.
…ine strategy for bot participation based on player presence
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>
… assignments based on game state and team dynamics
…ry in objective selection
…namic vehicle limits, and refined role assignments based on urgency and rank. Update vehicle ability usage for authentic gameplay experience.
Fix for issue mod-playerbots#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 mod-playerbots#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.
… workshops and game objects, ensuring accurate references for gameplay mechanics and interactions.
…g in join actions
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
(WINTERGRASP_ZONE_ID) for improved code readability and maintainability. Centralizes Wintergrasp-related constants and enumerations in a header file, reducing duplication and aligning with best practices. Updates related logic to use the new definitions, ensuring consistency across files and improving the clarity of battlefield handling and strategy execution.
Warning: Dont change this PR as draft to make it testable DONT REVIEW UNTIL Codestyle C++ workflow dont pass
Caches Wintergrasp team capacity to minimize redundant config lookups, improving performance. Introduces a method to refresh the cache when needed. Refactors vehicle selection and workshop control logic for clarity and consistency, replacing magic numbers with constants and enhancing readability. Removes unused Wintergrasp Titan's Relic handling to streamline related code paths.
Adds logic to prevent bots from entering IoC Catapults by introducing a new constant for the vehicle entry ID. Updates the existing check to exclude both Keep Cannons and Catapults in Isle of Conquest while allowing WG tower cannons for defenders. Improves bot behavior consistency and ensures they avoid restricted vehicles in IoC.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
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.
This pull request adds support for the Wintergrasp battleground to the bot AI system, enabling bots to participate in Wintergrasp battles with appropriate strategies and vehicle usage. The main changes include introducing a new
WintergraspStrategy, updating the strategy context to recognize it, and refining vehicle entry logic to respect Wintergrasp-specific rules and ranks.Wintergrasp battleground support:
WintergraspStrategyclass inBattlegroundStrategy.hand implemented its triggers inBattlegroundStrategy.cpp, focusing on vehicle-centric actions and abilities for Wintergrasp. [1] [2]StrategyContextand provided a factory method for it. [1] [2]AiFactory::AddDefaultNonCombatStrategiesto add the "wintergrasp" strategy only when a Wintergrasp battle is active in the zone.Battleground and vehicle logic improvements:
VehicleActions.cppto enforce Wintergrasp rank requirements, prefer tower cannons for defenders near the fortress gate, and handle vehicle selection more intelligently during battles. [1] [2] [3] [4]BattleGroundJoinAction.cpp. [1] [2]Miscellaneous:
BattleGroundTactics.hfor future movement logic.AiFactory.cpp.