Playerbot recovery systems: health, mana, and supplies

[adrunkhuman]

Purpose

Maintain a working index of playerbot health, mana, regeneration, conditions, recovery actions, and supply policy. Add detail as concrete vertical slices establish reusable boundaries.

This is an umbrella and design notebook, not a commitment to build a generic framework first.

Boundaries to keep separate

The eventual system should separate these concerns without requiring one monolithic manager:

• Observe health, mana, soul, food/regeneration, conditions, cooldowns, supplies, attackers, and the current objective.
• Assess urgent survival needs separately from ordinary resource maintenance.
• Discover and check legality for carried items, runes, spells, passive regeneration, and future recovery methods.
• Select legal actions by urgency, expected effect, cooldown, overheal, resource cost, scarcity, and objective reserves.
• Interrupt and later resume or abandon combat, navigation, looting, service, quests, and idle objectives.
• Verify from observed health, mana, condition, cooldown, and inventory changes.
• Plan service/refill before required supplies are exhausted.
• Emit stable telemetry for the need, selected method, evidence, result, and fallback.

Candidate slices

• Health-potion use and stock replenishment.
• Healing spells and runes with vocation, level, magic level, mana, soul, range, and exhaustion requirements.
• Mana restoration and offensive/defensive mana reserves.
• Food and passive-regeneration policy.
• Poison, fire, energy, paralysis, and other condition treatment.
• Health and mana bands, hysteresis, and anti-oscillation behavior.
• Incoming-damage and available-recovery-throughput assessment.
• Disengagement, kiting, and map-derived safe-region retreat.
• Objective-specific supply budgets and proactive service triggers.
• Post-death state reconciliation; the bot manager still owns relog lifecycle.

These are candidates for focused child issues and PRs, not an ordered implementation checklist.

Constraints that apply to all slices

• Use normal player item-use, spell, combat, movement, cooldown, mana, soul, inventory, and condition APIs.
• Do not directly mutate gameplay state as bot behavior or parse Lua/XML source text in playerbot code.
• Treat missing supplies, cooldowns, unsupported methods, ineffective recovery, and unsafe continuation as explicit policy outcomes.
• Keep decisions bounded on the dispatcher/scheduler model for eventual multi-bot scale.
• Retain enough objective context to resume only when the interrupted objective is still valid.
• Derive capabilities from authoritative loaded runtime data where practical instead of permanent playerbot-only item or spell lists.
• Prefer concrete vertical slices over speculative abstractions. Extract common machinery only after multiple real consumers establish it.

Current progress

• Playerbot survival: healing, retreat, and recovery #38 covers healing and survival planning, including the initial potion milestone and future retreat integration.
• server: add playerbot potion healing #45 adds the first global health-maintenance interrupt: carried small health potions, observed-effect verification, and missing-supply service recovery.
• Playerbot death recovery: save, relog, and reconcile state #39 and server: recover playerbots after death #49 add normal death persistence, bounded relog backoff, fresh service-first controllers, retained server ownership, and death-loop abandonment.
• Add focused child issues for mana policy, spell capability discovery, condition treatment, regeneration, or retreat when their next bounded milestones are selected.

Current supply policy

• Mandatory potion-driven Service uses the two-potion safety floor, not the optional 20-potion shopping target. Eligible unlearned Light Healing temporarily takes priority over that optional stock; larger route reserves remain protected.
• Emergency purchases may spend the normal 100-gold cash reserve. A service visit that still leaves safety stock unmet defers unchanged restock attempts until total funds or potion count changes; bank transfers alone are not progress.
• A broke bot can earn coins through a supply-fitting recovery hunt capped at 120 seconds. Zero-potion outings budget combined hunt and outbound/depot-return damage only from health above the 80% floor. Unsafe candidates remain excluded.
• Potion observations start at hunt-area arrival and account for ending resource debt and level-up restoration. Routine progression, food changes, and depleted mana no longer reject whole observations automatically (Learn global and local potion demand from ordinary hunts #201). Food contexts are pooled; global/local estimates reset with the controller.
• Cheaper estimates require sufficient duration and combat exposure, at least 30% health at the 10th percentile, and no interruption, danger, death, or potion exhaustion. Higher measured demand applies immediately. Learn combat costs and explore promising hunts through bounded trials #188 owns later trials and food-specific calibration.
• The 200-gold carried-plus-bank buffer in Prefer coin-producing hunts below a 200 gold balance #205 affects hunt-selection preference only. It does not replace the 100-gold purchase reserve or change emergency spending.

Connected work

• Run a sustainable mainland hunt-to-depot loop #22: sustainable hunt/service/depot loop.
• Playerbot NPC services: discovery, dialogue, and transactions #33: NPC service discovery and refill.
• Playerbot looting: corpse handling and inventory planning #35: loot, inventory, and supply reserves.
• Playerbot death recovery: save, relog, and reconcile state #39: death and relog lifecycle.

Update this index as terminology and subsystem boundaries become clearer. Put detailed acceptance criteria in focused child issues.

[adrunkhuman]

Merged #186 (af562324dade073590fc6edd349cbac83f9df108). Safety stock is separate from optional shopping stock; emergency purchases may spend the cash reserve. The zero-money/zero-potion Carlin fixture selected a spider hunt, reached it, and looted coins normally without repeated Service selection. This establishes initial income recovery, not a soak through replenishing the full reserve. Potion-learning limitations remain in #187; broader learning is #188.