WowClassicGrindBot

The Web UI is the primary interface for interacting with the bot, providing configuration, monitoring, and debugging tools. Key components include:

The ReadItems utility is used to extract NPC IDs and names from database files.

Database Compatibility Note:

• For SoM (Servants of Mithrandir), use the TBC DB files.
• For Classic, use the Classic DB files.
• For WOTLK, use the WOTLK DB files.

To use this utility, you must provide the appropriate .sql database files from the cmangos repositories.

The development of the Headless Pathing Server follows these phases:

• P1 — Retarget + carve: Retargeting the pathing chain to net10.0, creating a minimal PathingServer hosting PPatherController + PPatherService, and smoke-testing routes against baked tiles.
• P2 — Docker + CI: Implementing multi-stage, multi-arch Dockerfiles and GHCR publish Actions (submodule-aware).
• P3 — Provisioning + polish: Adding an R2-fetch entrypoint option, optional native self-contained RID builds, and an optional split between PPather.Query and PPather.Bake.
• P4 — macOS bake host: Enabling Apple-silicon machines to act as bake machines (independent of the query server).

Since there is no direct memory access, the Lua addon and C# core communicate via pixel color encoding. This is a high-performance bridge that uses:

• 32-bit integer packing: Data is packed into RGB components as B | (G << 8) | (R << 16).
• Fixed-point math: Used for sub-meter precision coordinates.
• UTF-8 encoding: Text is encoded as color values (3 characters per pixel).
• Sentinel pixels: Used for validating frame integrity.
• Event-driven caching: Reduces API calls from 56/frame to 5/frame.

The bot uses two distinct expression scopes to prevent logic leakage between player-state requirements and creature-state filters. While they share similar syntax, they use different variable tables.

1. Requirements (Player Scope): Used for standard goal requirements (e.g., "Level < 5" refers to the player's level).
2. Generate.Mobs (Creature Scope): Used within the route generation logic to filter which mobs to include in a path (e.g., "Level < 5" refers to the creature's level).

Key Differences:

• The creature scope includes PlayerLevel as an explicit variable, but does not include player-only variables like Health%.
• If you use a player-only variable in a Generate.Mobs filter, it will throw a parse-time error rather than failing silently.
• Log lines for generated paths will print the resolved filter and the matched creature count to help debug these scopes.

The bot follows specific rules to decide which items are eligible for mailing:

Mailed items must be:

• Meeting the MinimumItemQuality threshold.
• Not present in the ExcludedItemIds list.
• Tradable (not soulbound, not quest items).

Items that are NEVER mailed:

• Soulbound items.
• Quest items.
• Bind-on-Pickup (BoP) items.
• Items in the ExcludedItemIds list.
• Hearthstones (it is recommended to add Hearthstone ID 6948 to your exclusion list).

WowClassicGrindBot uses a custom fork of DotRecast (Xian55/DotRecast @ wow-mods) to handle navmesh generation.

Unlike standard Recast workloads which are typically baked offline on build servers, this bot requires navmeshes to be baked on the player's local machine upon their first visit to an area, while the game client is simultaneously running. The fork is specifically optimized for this high-pressure, real-time constraint, focusing on reducing CPU time, memory allocation, and Garbage Collection (GC) pressure.

The CanRun:_KeyAction_Name_ requirement allows you to check if a specific KeyAction (identified by its Name) is currently eligible to be executed. This is useful for interrupt logic or prioritizing instant spells over long cast times.

// Example: Only allow this action if 'Frost Shock' is not currently running/castable
"Requirement": "!CanRun:Frost Shock"

// Example: Allow if 'Fire Blast' can be run
"Requirement": "CanRun:Fire Blast"