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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  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
  ```cpp
  std::shared_ptr<Action> action = ActionFactory::instance()->CreateAction(actionName);
  return action && action->IsPossible(this);
  ```

- **BotAI.cpp:708** - Get action priority
  ```cpp
  // 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
  ```cpp
  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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  // 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
  ```cpp
  #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
  ```cpp
  // 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):
```cpp
// 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
  ```cpp
  // 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
  ```cpp
  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
  ```cpp
  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**:
```cpp
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.