Skip to content

eve-online-mining-bot: add aggressive=yes flag to fight rather than flee - #493

Merged
smerwin merged 1 commit into
mainfrom
mining-bot-aggressive-mode
Sep 12, 2026
Merged

smerwin merged 1 commit into
mainfrom
mining-bot-aggressive-mode

Conversation

@smerwin

@smerwin smerwin commented Sep 11, 2026

Copy link
Copy Markdown
Owner

Summary

Stacked on #491 (mining-bot-wormhole-dscan), since this reuses wormholeSafetyStep's D-Scan hostile trigger as one of its two flee-replacement points -- this diff is just the aggressive-mode commit on top of it and will shrink to that alone once #491 merges and this is retargeted at main.

  • Adds an aggressive setting (yes/no, default no). Wherever this bot would otherwise flee -- the shield-percentage trigger, or (with wormhole=yes) the D-Scan hostile trigger -- it instead launches drones, locks the highest-priority hostile on the overview, and sends the drones after it.
  • Hostile identification and priority reuse what already exists: a rat by icon colour (ratsOnTheOverview), plus anything reading commonIndications.isWarpDisruptingMe -- checked first regardless of distance, since a scrambler is the one thing standing between the ship and leaving.
  • engageHostiles is the single gate reading the setting; both callers fall back to their existing runAway unchanged when it's off or when there's nothing on the overview to fight (e.g. a wormhole hostile the Directional Scanner has seen but that hasn't arrived on grid yet).
  • Drone-only -- this bot has no weapon-activation logic, and adding one is out of scope here (see the issue's own "Not in scope").

Fixes #492.

Test plan

  • elm make Bot.elm compiles clean.
  • elm-format --validate passes.
  • chooseHostileToEngage/hostileEngagementPriority (warp-disruptor-first, then-nearest) executed through the real Bot.elm in elm repl against synthetic overview entries: a scrambler farther away still wins over two closer rats; the nearest rat wins with no scrambler present; an empty list answers Nothing.
  • hostileOverviewEntries and both call-site wirings are exercised only by the whole-file compile -- building a full synthetic ReadingFromGameClient for the repl wasn't practical in the time available.
  • Not run against a live client. What to watch on the first aggressive=yes run: drones launching and the status line's Aggressive: fighting '<name>' clause naming a hostile, a warp-disrupting entry being locked ahead of a nearer plain rat when both are present, and the ship still fleeing (not sitting idle) on a trigger where nothing is on the overview to fight.

🤖 Generated with Claude Code

Adds an `aggressive` setting (yes/no, default no) that replaces both of this
bot's flee responses -- the shield-percentage trigger and (from #490/#491)
the wormhole D-Scan hostile trigger -- with launching drones, locking the
highest-priority hostile on the overview, and sending the drones after it.

Hostile identification reuses what already exists rather than adding new
parsing: a rat by the client's own icon colour (`ratsOnTheOverview`, already
built for the wormhole feature) and anything reading
`commonIndications.isWarpDisruptingMe`, which is checked first regardless of
distance since it is the one thing standing between the ship and leaving --
the same priority every combat-capable bot in this repo gives a scrambler.

`engageHostiles` is the single gate: it reads the setting once and answers
`Nothing` immediately when it is off or when there is nothing on the
overview to fight, so both callers fall back to their existing `runAway`
unchanged. Locking reuses `lockTargetFromOverviewEntryAndEnsureIsInRange`
with the existing `targeting-range` setting; engaging is a new context-menu
cascade ("Engage Target") on the drones-in-space group, the same shape
`launchDrones`/`returnDronesToBay` already use on the sibling group.

Drone-only, deliberately -- this bot has no weapon-activation logic and
adding one is out of scope here.

Verified without a live client: the whole file compiles clean under
`elm make`, and `chooseHostileToEngage`/`hostileEngagementPriority` (the
warp-disruptor-first, then-nearest selection) were executed through the
real `Bot.elm` in `elm repl` against synthetic overview entries, including
the empty-list and no-scrambler cases. `hostileOverviewEntries` and the two
call-site wirings are exercised only by the whole-file compile, since
building a full synthetic `ReadingFromGameClient` for the repl was not
practical in the time available. Not run against a live client.

Fixes #492

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Base automatically changed from mining-bot-wormhole-dscan to main September 12, 2026 14:22
@smerwin
smerwin merged commit c6dcd3f into main Sep 12, 2026
1 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

eve-online-mining-bot: needs an aggressive=yes flag to fight rather than flee

2 participants