feat(arena): Give arena bots PvP talents and rating-scaled gear - #2902

Overview

Random bots fight in arenas in their PvE spec and PvE gear: a leveling or raid build with no resilience, whatever the opponents' rating. A 2000-rated player and a fresh 80 meet the same bots.

With AiPlayerbot.PvpLoadoutSwap = 1 (off by default), a random bot entering an arena (rated or skirmish):

• respecs in place to the PvP premade of its talent tree and applies its glyphs;
• equips match gear scaled to the opponents' rating: a four-piece PvP set the rating allows, then the remaining slots chosen against per-role stat targets (hit, spell penetration, resilience, then the role's main stats), from vendor-sold PvP gear and the BiS table, keeping its own items where they are better; gemmed and enchanted towards the same targets;
• gets its PvE talents, glyphs and gear back when the match ends, when it leaves, or after a crash.

The PvE items it takes off are saved as full copies (crafter, gems, enchants, random suffix, durability) and recreated afterwards, so a bot needs no free bag space and no item is lost in a crash.

Feature Evaluation

• Minimum logic: one strategy, trigger, action and value. Gear choice is precomputed once per class, talent tree, level, faction and rating tier and shared by every bot in it; per bot only its own items are compared against it.
• Processing cost:
  • Option off (default): nothing runs; the strategy is not added to bots.
  • Option on: every random bot carries the strategy; its trigger checks a cached value every 2 s and its multiplier one flag, and only bots in an arena do real work. Per bot per match: one respec, one gear plan, ~17 item creations and destructions, one async save, one restore. Building a cached loadout takes a few ms the first time a tier is needed. The gear pool is built once at startup on the world thread. No synchronous database access on map threads.

How to Test the Changes

1. Apply the update SQL; set AiPlayerbot.PvpLoadoutSwap = 1. Optional: AiPlayerbot.PvpLoadoutAnnounce = 1 (bots say their spec, item level and rating in party chat in skirmishes) and AiPlayerbot.PvpLoadoutDebug = 1.
2. Queue a skirmish (2v2 to 5v5) with random bots, or let bots auto-join rated arenas (AiPlayerbot.RandomBotAutoJoinBGRatedArena*Count); tested at 70-79 and 80, ratings 0 to ~1900.
3. Before the gates open, inspect bots: PvP spec, PvP set and gear with gems and enchants. With debug on, each bot logs plans match gear, match gear for rating and match gems and enchants (totals against targets).
4. After the match, inspect again: PvE talents, glyphs and gear back, enchants and gems intact.
5. Restart the server mid-match: bots log back in with their PvE gear, no duplicates.

Impact Assessment

• 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)

  Off by default. When on, only bots in arenas do real work, once per match; every random bot carries a cached-value trigger check every 2 s and a multiplier check.

  pmon, 500 bots, BotActiveAlone = 100, smart scale off, rated arenas auto-joined, 103 minutes each: bot AI 1.627 ms per tick with the option off, 1.530 ms with it on (run-to-run noise). With it on, the feature's trigger, action and multiplier took 1.64 s of 951.9 s (0.17%, ~2.6 µs per tick): the trigger 0.5 µs and the multiplier 0.1 µs per call, the action 2.0 ms per call (max 3.7 ms), 360 calls across the arena entries in the window.

• Does this change modify default bot behavior?

  • • No
  • • Yes (explain why)

  The feature itself is opt-in. Two shared-code changes apply to every bot: TalentSpec::ReadTalents now reads learned talents with HasTalent (it missed most ranks with HasSpell), and InitTalentsBySpecNo no longer stores the spec as the bot's chosen spec (ChangeTalentsAction, the caller choosing a spec, stores it).

• Does this change add new decision branches or increase maintenance complexity?

  • • No
  • • Yes (explain below)

  New strategy, trigger, action and value, two playerbots tables, and ~2,600 lines in src/Mgr/PvpLoadout, PvpGearListMgr and the repository (3,300 in all, without tests). The decision logic is pure and unit-tested; shared code only gains small, default-off extension points.

AI Assistance

Was AI assistance used while working on this change?

• • No
• • Yes (explain below)

Claude Code (Claude Opus 5.5) wrote the design notes and most of the code from my design decisions, iterated with me over in-game tests (skirmishes at 70-79 and 80, a crash mid-match) and ran simplification reviews. I reviewed the changes and tested them in game.

Code Provenance / Attribution

Was any code in this PR copied or adapted from a sister / upstream project (e.g. CMaNGOS playerbots, MaNGOS, another module)?

• • No, all code in this PR is original
• • Yes (name the project and the original author(s) below)

Final Checklist

• • Changes are understood and tested for server stability and performance impact.
• • Any new bot dialogue lines are translated.
• • New source files use the GPLv2 header.
• • Documentation updated if needed (Code comments, Conf comments, WiKi commands).
• • New and modified files do not introduce new compiler warnings.

Notes for Reviewers

• Commits are grouped for review: a standalone talent fix, shared-code groundwork (no behaviour change), the pure model, gear selection, the swap, and unit tests (-DPLAYERBOTS_TESTS=ON, off by default; droppable).
• The two shared-code commits stay in this PR rather than a separate one: the talent fix is what makes the PvE talent snapshot correct, and the groundwork only adds default-off extension points the feature uses. Each can be reviewed (or cherry-picked) on its own.
• Known gaps, from data rather than code: the BiS table lacks level-70 tiers for some specs, and death knights have no TBC PvP sets, so 70-79 death knights keep most of their own armor. Casters never reach the spell penetration target.