Pull Request Description

Initialize random bot professions from the factory using class-matching or weighted-random profession pairs, respect the active primary profession cap, and restore required profession tools during bot init/refresh.

This PR also initializes profession specializations for eligible bots so crafted professions are not left in an unspecialized state after profession assignment. Supported specialization families include:

• Alchemy: Transmute / Elixir / Potion
• Engineering: Goblin / Gnomish
• Leatherworking: Dragonscale / Elemental / Tribal
• Tailoring: Spellfire / Mooncloth / Shadoweave
• Blacksmithing: Armorsmith / Weaponsmith, plus Hammersmith / Axesmith / Swordsmith for eligible Weaponsmith bots

Specialization choices are stored in bot values so they remain stable across later refreshes. Required tool items are also restored for relevant professions during maintenance.

Feature Evaluation

• Describe the minimum logic required to achieve the intended behavior.

  • Select one or two professions during factory initialization from a small weighted list.
  • Clamp the assigned professions to the configured primary profession limit.
  • Learn the profession starter spell and set skill to the bot’s profession cap.
  • For professions with supported specialization branches, assign exactly one valid specialization when the bot meets the same level/skill gates used by AzerothCore profession scripts.
  • Persist the specialization selection in stored bot values so the choice is stable and does not need to be recalculated repeatedly.
  • Restore missing profession tools only when the bot has the related profession and the tool is absent.

• Describe the processing cost when this logic executes across many bots.

  • The added logic executes only during bot init/refresh, not as part of per-tick combat or trigger evaluation.
  • Runtime cost is limited to a few small switch statements, stored value lookups, spell checks, and item presence checks.
  • No expensive repeated searches, map scans, or per-trigger decision trees were added.
  • The design keeps specialization selection deterministic after first assignment by storing the result, avoiding repeated random branching later.

How to Test the Changes

1. Build and restart the server with this branch.
2. Trigger random bot creation, refresh, or level-based reroll for multiple bots.
3. Verify in Playerbots.log that bots receive profession pairs and, when eligible, profession specializations.
4. Check that low-level bots do not receive specializations before the required thresholds.
5. Check that eligible bots do receive one specialization for supported profession families.
6. Verify that specialization choices remain stable across subsequent refreshes.
7. Verify that profession tools are restored when missing:
   • Mining Pick
   • Blacksmith Hammer
   • Arclight Spanner
   • Runed Arcanite Rod
   • Skinning Knife
8. For a few bots, inspect in game or via debug tooling that profession spells/specialization spells are present as expected.

Expected behavior:

• Bots receive professions that respect the configured primary profession limit.
• Profession skill values are initialized to the level-based cap.
• Eligible bots receive exactly one valid specialization for supported profession families.
• Specialization assignments are logged and persist across refreshes.
• Profession tools are restored only when required.

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)

  Explanation:

  • The added work runs during initialization/refresh rather than normal per-tick behavior.
  • Logic is bounded, data-local, and based on direct skill/spell/value checks.

• Does this change modify default bot behavior?

  • • No
  • • Yes (explain why)

  Explanation:

  • Bots can now start with initialized professions, required tools, and eligible profession specializations instead of remaining partially configured or unspecialized.

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

  • • No
  • • Yes (explain below)

  Explanation:

  • The factory now contains specialization assignment branches for supported profession families.
  • Complexity is intentionally limited to init-time switch-based logic with stored specialization values to preserve predictability.

AI Assistance

Was AI assistance used while working on this change?

• • No
• • Yes (explain below)

AI assistance was used for:

• code generation and refactoring in PlayerbotFactory
• drafting and refining profession/specialization initialization logic
• PR description preparation

All generated and suggested code was reviewed, adjusted, built locally, and validated before submission.

Final Checklist

• • Stability is not compromised.
• • Performance impact is understood, tested, and acceptable.
• • Added logic complexity is justified and explained.
• • Any new bot dialogue lines are translated.
• • Documentation updated if needed (Conf comments, WiKi commands).

Notes for Reviewers

• Target branch is test-staging.
• Profession/specialization logic is intentionally limited to init/refresh paths to avoid per-tick cost.
• Specialization selections are stored to keep bot behavior stable across later refreshes.
• Recent changes also add debug logging for assigned specializations and save the bot after specialization learning so assignments are visible and persisted.