Build reusable playerbot combat targeting and tactics

[adrunkhuman]

Scope

Track reusable combat target selection and tactics. The first concrete gap is mid-fight retargeting: a bot fighting a low-priority monster should switch when a materially higher-priority threat appears, such as an orc joining a fight with three rats.

This is an umbrella and design record, not a commitment to build a generic combat framework first. Create focused child issues only where vertical slices establish reusable boundaries.

Current behavior

• Visible-monster acquisition is mainly ordered by distance and creature ID.
• Traversal combat keeps its target until death, disappearance, loss, or timeout.
• Active combat does not compare the current target with newly visible candidates.

First milestone: priority retargeting

• Reevaluate visible, legal, reachable hostile monsters during combat.
• Score candidates from available evidence: attacks on the bot, monster threat, route impact, distance/range, and current-target state.
• Use the normal player attack operation only when a candidate materially outranks the current target.
• Add hysteresis or a bounded switch cooldown to prevent thrashing.
• Preserve kill, corpse, loot, navigation, and interrupted-objective bookkeeping across a target change.
• Emit stable telemetry for previous target, selected target, reason, relevant evidence/scores, and rejected switches.

Acceptance

• In a deterministic three-rats-and-an-orc fixture, the bot starts on a rat and switches to the orc when it exceeds the defined retargeting threshold.
• Equal or near-equal targets do not cause successive-cycle oscillation.
• Unreachable, unseen, dead, invalid, or legally unattackable candidates are never selected.
• Retargeting uses normal combat/movement APIs; it does not mutate health, position, or combat state directly.
• After the higher-priority target dies or disengages, the bot reevaluates valid targets and resumes the valid hunt objective.
• Telemetry records the selected switch and each rejected switch with an explicit reason, including below-threshold, cooldown, or eligibility rejection.
• Regression coverage verifies the target-change sequence and telemetry, not only the final kill.

Later capability areas

• Multi-attacker threat assessment and target scoring.
• Melee/ranged position, chase, hold-ground, and disengagement policy.
• Stickiness, overkill avoidance, and opportunistic finishing.
• Offensive spells, runes, ammunition, and weapon selection.
• Coordination with healing, retreat, navigation, looting, supplies, and later party behavior.

These are candidate child issues, not an ordered checklist.

Constraints

• Use normal player combat, movement, spell, item, scheduler, and persistence APIs.
• Keep decisions bounded and staggerable for eventual multi-bot scale.
• Prefer authoritative loaded monster, item, spell, and combat data to permanent playerbot-only name lists.
• Preserve explainable deterministic telemetry even if later preferences become probabilistic.
• Keep tactical targeting separate from hunting-region selection and global survival interrupts.

Related

#8 established normal one-target rat combat and intentionally excluded tactics. #38 owns healing, survival interrupts, and retreat. #46 indexes health, mana, conditions, and recovery. #51 owns hunting-region selection. #35 owns corpse looting and inventory policy.

[adrunkhuman]

Route-impact regression observed

While validating PR #63, this command failed:

pwsh -File scripts/test-playerbot-gameplay.ps1 -FullNavigation -CorpseLoot

The bot did not prioritize the attacker occupying its failed navigation step.

scripts/test-playerbot-gameplay.ps1:228-233 observed a defensive interruption, but its first defensive target was not route_critical. server/src/playerbotcombat.cpp:257-306 intends an attacker at navigationStepTarget or the recently blocked target to outrank other adjacent attackers.

Required behavior:

failed navigation step occupied by attacker
-> preserve blocked-step evidence until defensive selection
-> select that attacker as route-critical
-> fight without chasing
-> replan and resume the interrupted objective

This is #54 target selection and crosses #28, which owns the marker and expiry. Diagnose whether the marker expires, clears, or mismatches after movement before selection. Keep the correction limited to this regression, not broad retargeting.

[adrunkhuman]

Diagnosis: assertion ordering, not production targeting

Repeated clean runs on server/playerbot-route-blocker-priority did not reproduce a production failure. The classifier consistently marked the fixture blocker route_critical=true, including a run where defensive combat began before step_result_mismatch because navigationPending still identified the occupied next step.

The intermittent failure was Assert-CycleEvents: it inspected [0] across all monsters. The fixture permits unrelated natural attackers, so an earlier valid defensive interruption could fail the assertion before the named blocker was correctly classified and defeated.

The focused correction correlates Playerbot Defensive Threat by creature ID across target_changed, route-critical non-chasing combat start, and matching target_defeated. It preserves the contract while ignoring unrelated ordering.

Passed: cycle scenario; the original matrix pwsh -File scripts/test-playerbot-gameplay.ps1 -FullNavigation -CorpseLoot -SkipBuild; cycle 124s, navigation 136s, corpse 48s. No production combat or navigation behavior changed.

[adrunkhuman]

#64 merged: stabilize route-impact coverage

PR #64 merged in 743528197. The cycle assertion follows Playerbot Defensive Threat by creature ID through:

• target_changed with reason=defensive_path_blocker and route_critical=true.
• Non-chasing defensive combat start.
• Matching target_defeated.

This prevents unrelated earlier defensive combat from causing a false failure. Runtime tracing confirmed the existing pending-step/recently-blocked-step classifier already worked; PR #64 changed no production combat or navigation logic.

No #54 milestone item became complete. Active-combat retargeting, threat scoring, hysteresis, target switching, and its bookkeeping remain open.

[adrunkhuman]

PRs #114 and #115 now use the existing route-impact classifier in two additional production paths: suspended corpse navigation and failed hunt patrol navigation. In the post-fix wasp-cave observation, Bot One repeatedly selected and fought wasps as defensive_path_blocker before continuing.

No #54 milestone item is complete. Active-combat priority retargeting, score thresholds, hysteresis, rejected-switch telemetry, and target-switch bookkeeping remain open.

[adrunkhuman]

Refactor path update after #118, #122, #130, and #133:

• Route-critical marker and expiry: server/src/playerbotnavigationsession.cpp:176-181
• Defensive priority selection: server/src/playerbottargetingsession.cpp:45-57
• Live attack and telemetry: server/src/playerbotcombat.cpp:362-417
• Regression assertion: scripts/playerbot-gameplay/assertions-cycle.ps1:33-75

This records relocated ownership only. It does not complete #54's active-combat retargeting milestone.