AzerothCore Server-Side Modules (Examples)

This article complements AzerothCore Modding Basics, which focuses on client-side workflows (DBC edits, MPQ-style patches, visuals, etc.).

Here we briefly document two server-side modules you can use as reference or drop into your own modding realm:

• A pure C++ quality-of-life module that resets raid cooldowns.
• A small Eluna + AIO minigame that demonstrates a simple custom UI with minimal client changes.

The goal is not to duplicate their READMEs, but to give you enough context to decide which patterns might be useful in your own projects.

1. mod-reset-raid-cooldowns (C++ only)

• Repository: https://github.com/sogladev/mod-reset-raid-cooldowns
• Type: Pure C++ AzerothCore module (no Eluna, no AIO, no database schema changes).

1.1. What it does

The module emulates Wrath Classic behaviour by:

• Removing Sated / Exhaustion-style debuffs.
• Resetting long raid cooldowns after encounters.
• Optionally resetting cooldowns for bosses that are pulled and then reset after being engaged for some time.

In practice, this means your raid can chain-pull bosses without having to wait for long offensive cooldowns, much closer to how modern Wrath Classic handles resets.

1.2. When cooldowns reset

From a high level (see the project README for full details), cooldowns can be reset via:

• Completing a raid encounter – killing a raid boss will reset relevant cooldowns, with a few exceptions that are configurable.
• Resetting a boss after X seconds – if a boss has been in combat for at least a configurable number of seconds and then evades/resets, cooldowns are reset.
  • For bosses using BossAI / SetBossState, the module hooks the standard boss state changes.
  • For older or custom bosses that do not use SetBossState, the module uses combat/evade hooks and an explicit list of entries in reset_raid_cooldowns_entries.h.

By default, this mirrors Blizzard’s approach for Wrath Classic, but you can tune the behaviour via config.

1.3. Configuration and deployment

• No database migrations – the module does not require extra tables.
• Config-driven – behaviour (which cooldowns to reset, which content is affected, timings, etc.) is controlled via its .conf file.
• Requires recompilation – as with most C++ modules, you need to:
  • Install it under modules/ in your AzerothCore source.
  • Re-generate build files if necessary.
  • Recompile the core with the module enabled.

This is a good example of a pure server-side quality-of-life module: it meaningfully changes gameplay without any client patches, addons, or UI work.

2. mod-deathroll-aio (Eluna + AIO UI)

• Repository: https://github.com/sogladev/mod-deathroll-aio
• Type: Eluna Lua module with AIO (AddOn–In–One) integration.
• Tested with: AzerothCore and ElunaTrinityWotlk (see README for exact versions).

2.1. What it does

This module implements a Deathroll gambling minigame where players can:

• Challenge another player to a Deathroll duel.
• Set a gold wager.
• Choose a starting roll value.
• Enable a special “to the death” mode where the loser dies at the end of the game.

The game works without requiring players to be grouped and uses an in-game UI window powered by AIO.

2.2. Features at a glance

From the player’s perspective:

• Challenge UI – target a player and challenge them through the window (or a “skull” button for the to-the-death variant).
• Slash commands – open the window, accept/decline challenges, play via chat-only commands, or request a refund in edge cases (see README for exact command list).
• Timeouts – games automatically time out if a player does not respond or roll in time.
• Automatic payouts – on completion, the module awards the gold to the winner.
  • When the amount is large, winnings are sent via in-game mail.

From the server’s perspective:

• Optional database persistence – if enabled in config, a deathroll table is created automatically on launch.
  • Stores active and completed games.
  • Enables safe refunds after restarts when configured.
• Configurable behaviour – you can:
  • Decide whether to remove gold at the start of a game or only settle at the end.
  • Enable/disable “to the death” mode and the corresponding UI.
  • Adjust timeouts between rolls.
  • Customize strings and other presentation details.

2.3. Client-side impact (AIO pattern)

The interesting part, from a modding perspective, is how little "real" client modding is required:

• The heavy lifting (game rules, gold transfers, persistence) lives on the server.
• The client sees a small AIO-driven UI – a lightweight window rendered by the AIO addon.
• There are no DBC edits or MPQ patches needed for this feature.

This makes mod-deathroll-aio a strong example of:

• How to build a feature that feels like a custom in-game system.
• While keeping your client modifications to a single addon + AIO bridge, instead of full-blown client data modding.

3. When to use which pattern

You can think of these modules as two ends of the server-side spectrum:

• Pure C++ rules changes (like mod-reset-raid-cooldowns):
  • Best for systemic changes that don’t need new UI.
  • Ideal when you want to mimic official behaviour (e.g. Wrath Classic) or add QoL toggles.
• Eluna + AIO UX features (like mod-deathroll-aio):
  • Best when you want a simple custom UI and interactive minigames without touching DBC/MPQ.
  • A good bridge between classic addon scripting and full client data modding.

If your end goal is advanced client-side modding, these server-side patterns are still useful:

• Start with a purely server-side prototype.
• Add AIO/Eluna where you need interaction and UI.
• Only move into DBC/MPQ work when you truly need new visuals, models, or deep client data changes.