mod-raid-runner

Raid orchestration module for AzerothCore. The module depends on mod-dungeon-clear, which provides the generic dungeon clear engine and controller API.

Responsibilities

• .dc raid start, .dc raid status and .dc raid stop;
• raid catalog and request/receipt lifecycle;
• RND/addclass-only auto-roster;
• selection of existing RND/addclass bots, whether online or offline;
• raid group, subgroup, role and Main Tank provisioning;
• raid live state, history and Molten Core-specific events.

Player characters are excluded from automatic rosters by default. The policy is configured in conf/mod_raid_runner.conf using the distributed template.

RaidRunner.ShowBanner controls the ANSI module banner in the worldserver startup log. Set it to 0 when the server log should stay quiet.

RND bot provisioning

At raid start the module filters the candidate pool by RND/addclass ownership, level, faction, active group and reservations. Real player characters are never used as a fallback. Offline candidates are logged in for the run; online candidates can join immediately when they are not already in a group.

If the pool is too small, the start is rejected with the current available capacity. Raid Runner never creates database accounts or characters; prepare the required RND/addclass pool through the normal mod-playerbots setup before the raid run.

RaidRunner.AutoRoster.GenerateMissingBots must remain disabled. The supported mod-playerbots dependency does not expose a bounded runtime generation API; enabling the option is rejected during configuration validation. Raid Runner reports the required size, selected size, and first missing role instead.

Dependency boundary

mod-dungeon-clear owns generic clear execution. mod-raid-runner must use its public controller API and must not depend on Dungeon Clear implementation classes directly.

mod-raid-runner -> mod-dungeon-clear -> mod-playerbots / AzerothCore

Current implementation boundary

The module now contains the configurable RND/addclass provisioning policy, candidate snapshot filtering, and an engine-free provisioning service. The service is deliberately independent from ChatHandler and database connections: the world adapter supplies a fresh candidate snapshot on start and on each poll, then passes the selected GUIDs to the playerbot login adapter.

The .dc raid command tree is now registered by mod-raid-runner only. mod-dungeon-clear exposes a temporary public backend facade while the raid provisioning implementation is being moved fully behind this module boundary.

Commands

All commands are issued by a GM or an authorized operator through the worldserver console/chat command handler:

.dc raid start molten-core
.dc raid status
.dc raid watch
.dc raid stop

start validates the catalog and candidate pool, creates the requested raid manifest, provisions the group, and starts Dungeon Clear only after the group is ready. status returns the request/run state, selected members, boss progress, and the latest stop or failure reason. watch is read-only and exposes the active raid target for a spectator session. stop requests a graceful teardown and releases reservations owned by the run.

The exact catalog token and available subcommands depend on the configured mod-dungeon-clear raid registry. Use .dc raid status without an active run to verify that the module is loaded before starting a raid.

Configuration example

Copy conf/mod_raid_runner.conf.dist to the server configuration directory:

RaidRunner.LiveSnapshot.Enabled = 1
RaidRunner.ResetInstance = 1
RaidRunner.Recovery.MaxAttempts = 1
RaidRunner.AutoRoster.Enabled = 1
RaidRunner.AutoRoster.RequireRndOrAddclass = 1
RaidRunner.AutoRoster.GenerateMissingBots = 0
RaidRunner.AutoRoster.AllowPlayerCharacters = 0
RaidRunner.AutoRoster.MinMembers = 10
RaidRunner.AutoRoster.MaxMembers = 40
RaidRunner.AutoRoster.MinLevel = 60
RaidRunner.AutoRoster.Faction = auto

Recovery.MaxAttempts bounds automatic recovery after a Dungeon Clear stop; once the limit is exceeded, the raid is marked failed. Runtime bot generation is intentionally unsupported, so GenerateMissingBots must remain 0; prepare the RND/addclass pool with mod-playerbots before launching.

How a run works

1. The command creates a request and validates dungeon, faction, level, and roster capacity.
2. The module reserves eligible RND/addclass bots and records an immutable raid manifest. Real player characters are rejected by policy.
3. The provisioning job logs in offline bots, forms the raid/subgroups, selects the Main Tank, and teleports the group into a fresh or existing instance.
4. Raid Runner hands generic movement and combat to the public controller API from mod-dungeon-clear and publishes live state for SBAzeroth.
5. Boss progress, loot, stop causes, and recovery attempts are recorded in the live snapshot/history. On completion or terminal failure, reservations and owned logins are released.

Build and compatibility

The module is not standalone. Build it inside an AzerothCore checkout with the matching mod-dungeon-clear and mod-playerbots revisions enabled. Re-run CMake after adding or updating the module, then rebuild worldserver.