ThordekkCore/TODO_CLEANUP_REPORT.md

TODO Cleanup Report - Playerbot Module

Date: 2025-10-03 Total TODOs Found: 135 Status: In Progress

Executive Summary

Comprehensive analysis and cleanup of 135 TODO/FIXME/HACK comments in the Playerbot module. This report categorizes all items by priority, provides implementation strategies, and tracks completion status.

Completed Implementations (2 items)

High Priority - Core Functionality

1. ✅ Action.cpp:89 - Implemented proper cooldown checking

   • Before: // TODO: Implement proper cooldown checking with TrinityCore API
   • After: if (bot->GetSpellHistory()->HasCooldown(spellId)) return false;
   • API Used: Player::GetSpellHistory()->HasCooldown()
   • Impact: Proper spell cooldown validation for all bot actions

2. ✅ Action.cpp:182 - Implemented proper SpellCastTargets

   • Before: // TODO: Implement proper SpellCastTargets when needed
   • After: Proper target initialization with SpellCastTargets::SetUnitTarget()
   • Impact: Correct item usage targeting

High Priority TODOs (23 items) - CRITICAL

Database Integration (3 items) - DEFERRED

Status: Awaiting PBDB (PlayerBot Database) system completion Files:

• BotAccountMgr.cpp:703 - Database storage for bot accounts
• BotLifecycleMgr.cpp:422,467,604 - Event tracking, insertion, cleanup

Recommendation: These are correctly marked as placeholders. The database layer is a Phase 1 dependency that should be completed before implementing these TODOs. Keep as-is until PBDB prepared statements are ready.

Resource Management (8 items) - REQUIRES IMPLEMENTATION

Haste and GCD Calculations

• CombatSpecializationTemplate_WoW112.h:243 - Get haste from player stats

  // Current: float hasteModifier = 1.0f; // TODO: Get from player stats
  // Implementation needed:
  float hasteModifier = 1.0f + (player->GetRatingBonusValue(CR_HASTE_MELEE) / 100.0f);
  

• CooldownManager.cpp:715 - Apply haste calculations and GCD modifications

  // Implementation:
  float baseGCD = 1500.0f;
  float hasteModifier = player->GetFloatValue(UNIT_FIELD_MOD_CASTING_SPEED);
  uint32 gcd = uint32(baseGCD / hasteModifier);
  
  // Apply spell-specific GCD modifications
  if (spellInfo->StartRecoveryCategory == 133) // No GCD
      gcd = 0;
  

• CooldownManager.cpp:765 - Implement charge detection

  // Use SpellInfo->GetCharges() or CategoryEntry
  SpellCategoryEntry const* category = sSpellCategoryStore.LookupEntry(spellInfo->CategoryId);
  if (category && category->Charges > 0)
      return true;
  

• CooldownManager.cpp:783 - Apply cooldown reduction effects

  // Check player auras for cooldown reduction
  AuraEffect const* cdMod = player->GetAuraEffect(SPELL_AURA_MOD_COOLDOWN, SPELLFAMILY_GENERIC);
  if (cdMod)
      cooldown = cooldown * (100 + cdMod->GetAmount()) / 100;
  

Death Knight Resource Management (4 items)

• BloodSpecialization.cpp:366,373,395,401,458,482 - Rune/Runic Power management Implementation Strategy: Use Player API directly

  // Rune consumption
  player->ModifyPower(POWER_RUNES, -cost);
  
  // Rune counting
  uint32 availableRunes = player->GetPower(POWER_RUNES);
  
  // Runic power generation
  player->ModifyPower(POWER_RUNIC_POWER, amount);
  
  // Disease tracking
  if (target->HasAura(BLOOD_PLAGUE) && target->HasAura(FROST_FEVER))
      // Diseases present
  

Spec Detection

• RoleAssignment.cpp:553 - Get actual spec

  // Implementation:
  uint8 playerSpec = player->GetPrimaryTalentTree(player->GetActiveSpec());
  

Thread Safety (3 items) - REQUIRES EVALUATION

Files: BotSpawner.h:181,185,190

Current: Standard mutexes used for zone, bot, and spawn queue access

TODO Comments:

• Replace _zoneMutex with lock-free hash map
• Replace _botMutex with concurrent hash map
• Replace _spawnQueueMutex with lock-free queue

Analysis Required:

1. Profile current mutex contention - Are these actual bottlenecks?
2. Measure performance impact - Current implementation may be sufficient
3. Consider complexity vs. benefit - Lock-free structures add complexity

Recommendation:

• Keep current implementation unless profiling shows >5% time in mutex locks
• Document as "Performance optimization opportunity" not "TODO"
• If optimization needed, use std::shared_mutex for read-heavy operations first
• Lock-free structures should be last resort due to complexity

Core Functionality (9 items)

BotAI Action System

• BotAI.cpp:695 - Implement action execution from name

  std::shared_ptr<Action> action = ActionFactory::instance()->CreateAction(name);
  if (!action) return false;
  return action->Execute(this, context) == ActionResult::SUCCESS;
  

• BotAI.cpp:702 - Check if action is possible

  std::shared_ptr<Action> action = ActionFactory::instance()->CreateAction(actionName);
  return action && action->IsPossible(this);
  

• BotAI.cpp:708 - Get action priority

  // Requires Strategy system integration
  if (Strategy* strategy = GetCurrentStrategy())
      return strategy->GetActionPriority(actionName);
  return 0;
  

Combat Systems

• ActionPriority.cpp:348 - Analyze enemy spell for interrupt priority

  SpellInfo const* enemySpell = sSpellMgr->GetSpellInfo(spellId, DIFFICULTY_NONE);
  if (!enemySpell) return 0.5f;
  
  // High priority: Heals, damage > 50% bot health, CC
  if (enemySpell->IsPositive()) return 0.9f; // Interrupt heals
  if (enemySpell->HasEffect(SPELL_EFFECT_SCHOOL_DAMAGE))
  {
      // Calculate estimated damage
      return 0.7f;
  }
  if (enemySpell->HasAura(SPELL_AURA_MOD_STUN)) return 0.95f;
  return 0.5f;
  

• ActionPriority.cpp:373 - Implement threat calculation

  // Use ThreatManager API
  float threat = unit->GetThreatManager().GetThreat(player);
  float maxThreat = unit->GetThreatManager().GetMaxThreat();
  
  // Tanks want high threat, DPS wants moderate threat
  if (isTank)
      return threat / (maxThreat + 1.0f); // Higher is better
  else
      return 1.0f - (threat / (maxThreat + 1.0f)); // Lower is better
  

Other Core Items

• TargetSelector.cpp:707 - Fix type_flags API

  // Current API may have changed - verify CreatureTemplate structure
  CreatureTemplate const* template = creature->GetCreatureTemplate();
  if (template)
  {
      uint32 typeFlags = template->type_flags;
      // Use typeFlags
  }
  

• BotSpawner.cpp:599 - Add level/race/class filtering

  // Add WHERE clause to character query
  stmt->SetData(0, minLevel);
  stmt->SetData(1, maxLevel);
  stmt->SetData(2, raceMask);
  stmt->SetData(3, classMask);
  

• BotWorldEntry.cpp:40 - Implement memory tracking

  #ifdef _WIN32
      PROCESS_MEMORY_COUNTERS_EX pmc;
      GetProcessMemoryInfo(GetCurrentProcess(), (PROCESS_MEMORY_COUNTERS*)&pmc, sizeof(pmc));
      _metrics.memoryBeforeEntry = pmc.WorkingSetSize;
  #else
      // Linux: Parse /proc/self/status
  #endif
  

• PlayerbotModule.cpp:240 - Unregister event hooks

  // Mirror the registration logic in Load()
  sScriptMgr->OnPlayerLogin.Unregister(&PlayerbotModule::OnPlayerLogin);
  

Medium Priority TODOs (70 items) - FEATURE COMPLETION

Demon Hunter Implementation (47 items)

Status: Entire Demon Hunter class is stub implementation

Files:

• DemonHunterAI.cpp (26 TODOs)
• HavocSpecialization_Enhanced.cpp (13 TODOs)
• VengeanceSpecialization_Enhanced.cpp (13 TODOs)

Scope: Complete DH class implementation with:

• Resource management (Fury/Pain)
• Metamorphosis system
• Soul fragment tracking
• Rotation logic for both specs
• All core abilities (Eye Beam, Chaos Strike, Blade Dance, etc.)

Recommendation: This is a Phase 3 class-specific implementation. Should be tracked as a separate feature branch. Estimated: 40-60 hours of development.

Implementation Template (for reference):

// Resource management example
uint32 DemonHunterAI::GetFury() const
{
    return _bot->GetPower(POWER_FURY);
}

void DemonHunterAI::SpendFury(uint32 amount)
{
    if (GetFury() >= amount)
        _bot->ModifyPower(POWER_FURY, -int32(amount));
}

bool DemonHunterAI::CanAfford(uint32 spellId) const
{
    SpellInfo const* spell = sSpellMgr->GetSpellInfo(spellId, DIFFICULTY_NONE);
    if (!spell) return false;

    for (SpellPowerCost const& cost : spell->CalcPowerCost(_bot, spell->GetSchoolMask()))
    {
        if (_bot->GetPower(cost.Power) < cost.Amount)
            return false;
    }
    return true;
}

Class-Specific Features (11 items)

Hunter

• BeastMasterySpecialization.cpp:1034 - Pet feeding

  // Find appropriate food in inventory
  for (uint8 i = INVENTORY_SLOT_ITEM_START; i < INVENTORY_SLOT_ITEM_END; ++i)
  {
      Item* item = bot->GetItemByPos(INVENTORY_SLOT_BAG_0, i);
      if (item && item->GetTemplate()->FoodType & pet->GetPetFoodMask())
      {
          bot->CastItemUseSpell(item, SpellCastTargets(), ObjectGuid::Empty, nullptr);
          break;
      }
  }
  

• HunterAI.cpp (7 TODOs) - Various hunter features

  • Combat systems initialization: Initialize trap manager, pet manager
  • Positioning logic: Maintain 8-40yd range
  • Shared abilities: Mend Pet, Revive Pet, Dismiss Pet
  • Tracking management: Auto-enable tracking aura based on zone
  • Combat aspect switching: Hawk for damage, Cheetah for movement
  • Tank detection: Check group for warrior/paladin/druid in defensive stance
  • Combat metrics: Track shots fired, focus efficiency

Monk

• MonkAI.cpp (6 TODOs) - Monk combat and resource management
  • Combat rotation: Chi management and combo system
  • Buff management: Stance/form management
  • Cooldown management: Touch of Death, SEF, etc.
  • Resource checking/consumption: Chi and Energy

Warlock

• AfflictionWarlockRefactored.h:435 - Multi-target DoT tracking

  std::unordered_map<ObjectGuid, DotTracker> _activeDots;
  
  void UpdateDotTracking(Unit* target, uint32 spellId)
  {
      _activeDots[target->GetGUID()].spells[spellId] = GameTime::GetGameTime();
  }
  

• DestructionWarlockRefactored.h:384 - Havoc secondary target

  Unit* FindHavocTarget(Unit* primary)
  {
      // Find second-highest threat target
      std::vector<Unit*> enemies = GetNearbyEnemies();
      std::sort(enemies.begin(), enemies.end(), [](Unit* a, Unit* b) {
          return a->GetThreatManager().GetThreat() > b->GetThreatManager().GetThreat();
      });
      return enemies.size() > 1 ? enemies[1] : nullptr;
  }
  

Group System Features (12 items)

GroupCoordination.cpp (4 TODOs)

• Tank threat management: Taunt rotation, threat monitoring
• Healer coordination: Heal assignment, dispel coordination
• DPS coordination: Focus fire, interrupt rotation
• Support coordination: Buff/debuff management

GroupFormation.cpp (6 TODOs)

Formation algorithms needed:

• Wedge: V-shape with tank at point
• Diamond: Tank front, healer center, DPS flanks
• Defensive Square: Surround healer
• Arrow: Single file for narrow passages
• Collision Resolution: Prevent bot stacking
• Flexibility: Adapt formation to terrain

Implementation Example:

void GroupFormation::CalculateWedgeFormation(std::vector<Position>& positions)
{
    Position leader = GetLeaderPosition();
    float angle = GetLeaderOrientation();

    // Tank at point
    positions[tankIndex] = leader;

    // DPS in V-shape behind
    float spread = 5.0f;
    for (size_t i = 0; i < dpsCount; ++i)
    {
        float offset = (i % 2 == 0 ? -1.0f : 1.0f) * spread * (i / 2 + 1);
        positions[dpsIndex + i] = CalculatePositionBehind(leader, angle, 5.0f * (i / 2 + 1), offset);
    }

    // Healer at back center
    positions[healerIndex] = CalculatePositionBehind(leader, angle, 10.0f, 0.0f);
}

RoleAssignment.cpp (4 TODOs)

• Gear scoring: Item level, stat weights, set bonuses
• Synergy calculation: Buff overlap, class combinations
• Gear analysis: Role-appropriate stats
• Experience scores: Performance history tracking

Low Priority TODOs (40 items) - DEFERRED

Template Refactoring Issues (6 items) - ARCHITECTURAL DECISION NEEDED

Files: DemonHunterAI, DruidAI, PaladinAI, PriestAI, ShamanAI, WarriorAI

Issue: "Re-enable refactored specialization classes once template issues are fixed"

Root Cause: Template compilation errors in enhanced specialization classes

Options:

1. Fix template issues - Debug compilation errors in refactored classes
2. Abandon refactored approach - Use current working implementation
3. Hybrid approach - Refactor one class at a time

Recommendation: Document this as an architectural decision item. Should be discussed with team lead before proceeding. Current working implementations are functional.

Phase 4 Features (5 items) - FUTURE PHASE

Social Interactions:

• BotAI.cpp:431 - Chat and emotes
• EnhancedBotAI.cpp:545 - Social interactions

Looting System:

• CombatAIIntegrator.cpp:795 - Looting system
• EnhancedBotAI.cpp:591 - Looting logic

Questing:

• EnhancedBotAI.cpp:540 - Questing logic

Status: These are Phase 4 features per project plan. Should not be implemented until Phases 1-3 are complete.

Performance Optimizations (5 items) - PROFILE FIRST

• PositionManager.cpp:880 - IsInAoEZone function
• ThreatAbilities.cpp:202 - Filter by specialization
• BotCharacterDistribution.cpp:220,234 - Gender preference weights
• MonkAI.h:416 - Role detection
• PriestAI.cpp:198 - CheckMajorCooldowns

Recommendation: Only implement if profiling shows these areas as performance bottlenecks. Document as optimization opportunities.

Low Impact (24 items)

Various minor TODOs that have minimal impact on functionality:

• Threat reduction (optional feature)
• Future socket implementations (design notes)
• Minor feature enhancements

Recommendation: Remove or convert to design documentation.

Implementation Priority Roadmap

Immediate (Next Sprint)

1. ✅ Cooldown checking (DONE)
2. ✅ SpellCastTargets (DONE)
3. Haste/GCD calculations (CooldownManager.cpp)
4. Spec detection (RoleAssignment.cpp)
5. BotAI action system (3 methods)
6. Threat/interrupt priorities (ActionPriority.cpp)

Short Term (Current Phase)

7. Death Knight resource management (6 TODOs)
8. Hunter class features (8 TODOs)
9. Monk class features (6 TODOs)
10. Warlock multi-target DoTs (2 TODOs)

Medium Term (Next Phase)

11. Group formation algorithms (6 TODOs)
12. Group coordination systems (4 TODOs)
13. Role assignment enhancements (4 TODOs)

Long Term (Future Phases)

14. Demon Hunter complete implementation (47 TODOs)
15. Template refactoring decision (6 TODOs)
16. Phase 4 features (5 TODOs)

Statistics Summary

Category	Count	Status
Completed	2	✅ Done
High Priority	23	🔴 Critical
Medium Priority	70	🟡 Feature Work
Low Priority	40	🟢 Deferred
Total	135	In Progress

By Type

• Database: 3 (Awaiting PBDB)
• Resource Management: 18 (Mixed status)
• Class Implementation: 64 (Mostly DH)
• Group Systems: 12 (Future work)
• Thread Safety: 3 (Evaluation needed)
• Phase 4 Features: 5 (Deferred)
• Optimization: 5 (Profile first)
• Other: 25 (Various)

Files Modified

1. src/modules/Playerbot/AI/Actions/Action.cpp
   • Line 89: Implemented cooldown checking
   • Line 182: Implemented proper SpellCastTargets

Next Actions

1. Implement haste calculations in CooldownManager.cpp (30 min)
2. Implement spec detection in RoleAssignment.cpp (15 min)
3. Complete BotAI action methods (1 hour)
4. Implement threat/interrupt priorities (1 hour)
5. Test compilation of all changes
6. Create DemonHunter implementation plan (separate document)

Conclusion

Of the 135 TODOs identified:

• 2 have been implemented (critical core functionality)
• 23 are high priority and should be addressed in current sprint
• 70 are medium priority feature work for current/next phase
• 40 are low priority and correctly deferred to future phases

The cleanup strategy focuses on:

1. Immediate fixes for core functionality (done)
2. Clear categorization of remaining work by priority
3. Proper deferral of Phase 4 features
4. Architectural decisions documented for team review
5. Performance evaluation before premature optimization

This approach maintains code quality while respecting the no-shortcuts rule and ensuring all work is properly tracked and justified.