Feature list with real statuses
Every capability carries its true status: Available (implemented and tested), In development (partially built, not announced), Planned (identified, not built), Out of scope (this product will not do it).
Float detection
PrintWindow capture of the game window, HSV colour analysis, day/night water ranges, texture discrimination, area thresholds. Detection parameters were calibrated on real captures of a real client, not on screenshots found online.
Cast → bite → catch cycle
Bite detection, instrumented bite → click latency (median 308 ms in our logged sessions), background clicks without window focus. F9 stops everything cleanly, at any time.
Persistent spot memory
Each fishing spot: position, reliability measured over repeated visits, real results, mobs seen nearby, time spent on site. Versioned schema with migrations and backups; export / import as JSON.
Route planner
Nearest neighbour + 2-opt optimiser over expected cost (travel time, mob risk, failure probability), three modes: Cautious, Balanced, Exploration. The site's JS planner and the bot's Python planner are compared on the same map at each build.
Casinobabe runtime addon
A WM-monitored in-game addon keeps the fishing journal (casts, targets, spots, risks) visible to the bot. The addon deliberately performs no input simulation: nothing it does can act on your character.
Licences & delivery
Machine-locked licence keys, server-side validation, limited-count download link, manual bitcoin rail with explicit admin approval. Payment via Mollie checkout (card).
Movement between spots
Minimap odometer and movement controller implemented and unit-tested (zero drift at rest, observed-position arrival checks). Full spot-to-spot travel is being validated in game before we claim it.
Inventory & vendor
Bag planning and vendor trips exist today as a tested offline planner (free-slot math, sell/restock lists, bounded trip plan) with a defined BagSnapshot data contract. Wiring it to the game is the current step — nothing runs in-game yet.
Corpse-run recovery
After character death the bot stops safely and asks for a human — that part is tested. The full recovery state machine (detect death → confirm ghost → navigate to corpse → resurrect) is specified and being implemented. Nothing is promised.
Grind, gathering, questing, battlegrounds
Design phase only. These combat roles need a detection layer (target state, cooldowns) that does not exist yet; no code has been written and no date is promised. When real work starts, the module ledger shows them as In development first.
Scripting & follower
A bounded script runner and a follower mode are written designs, sequenced after navigation and combat prove themselves. No editor ships while the concept is unproved, and no date is promised.
More game clients
Only WoW Classic 1.13 (anniversary) is tested today. TBC / WotLK / Retail profiles could follow once core in-game validation is done — when we can name a date, we will.
MacOS / Linux
The bot relies on Windows display and input APIs of the game client. No macOS or Linux build exists.
"Undetectable" operation
No automation tool is undetectable. Behaviour analysis can spot intensive automation. We document risks on the compatibility page instead of promising safety we cannot prove.