AzerothCore Modding Basics

This article builds on the setup from AzerothCore local setup and focuses on client-side modding, not core development.

If you want concrete examples of server-side modding (pure C++ and ALE/AIO-based), see AzerothCore server-side modules for a short overview and links.

The goal is to have a clean, reproducible workflow for:

• Keeping a stock core and a custom/modded environment side by side.
• Iterating quickly on server-side modules.
• Creating client-side content (new spells, items, visuals, etc.) using DBC edits and MPQ-style patches.

The examples and paths here assume a 3.3.5a client.

1. High-level layout

For modding, it helps to explicitly separate three things:

1. Workspace core – your AzerothCore source + build.
2. Client data – your 3.3.5a client folder.
3. Modding tooling – modules, DBC editors, and export folders wired together with symlinks.

I keep two configurations in parallel:

• Stock AC: vanilla configuration, minimal modules, for reference and comparison.
• Custom AC: dedicated to modding and experiments, with extra modules and custom settings.

Using Git worktrees / workspaces for the core and a client version switcher (for example, rs-realmctl) makes this much easier.

2. Database and core configuration

2.1. Databases via Docker Compose

Use a small docker-compose.yml that brings up two MySQL instances:

• 3321 – development DB (where you iterate on changes).
• 3322 – source DB (kept clean, used as a "before" reference).

This lets you easily diff data (e.g. with Keira3, direct SQL, or export scripts) and quickly reset the dev DB from the reference DB when experiments go wrong.

2.2. Core config basics

Copy and adjust the usual config files for the modding environment:

• worldserver.conf
• authserver.conf

Key changes:

• Change ports away from the defaults to avoid conflicts (especially if you keep a stock core running).
• Set standard QoL values (starting gold, reduced restrictions, faster rates, disabled raid requirements, etc.).
• Enable and configure module-specific options.

3. First compile and bootstrap

1. Compile the core as usual
2. Start authserver once to populate the auth DB.
3. In the auth DB, update your realmlist entry:
   • Set a distinct realm name for your modding realm.
   • Adjust address/port to match your modding worldserver.
4. Configure your client realmlist using your preferred realmlist switcher:
   • For example: rs-realmctl.
5. Start worldserver -d (or with -c to create missing tables) to let it populate the world DB.

After this, you have a fully-initialized realm dedicated to modding.

4. Client-side modding workflow

Many powerful changes (new visuals, models, spell behaviors, etc.) require client-side DBC edits in addition to server DB changes.

The basic pattern:

1. Edit DBC files (client-side data) with a DBC editor.
2. Wire those edits into the server-side DBC folder via symlinks.
3. Package the same DBC files into a client patch (MPQ-style) and load it in the client.

This section describes a workflow built around:

• A DBC editor, e.g. WDBXEditor.
• A spell-focused editor, e.g. WoW Spell Editor.
• A small symlink layout on your desktop.

4.1. Symlink layout for DBCs

Example layout on the desktop:

cd ~/Desktop

# Server-side custom DBC folder
acore-custom-dbc -> /home/pc/wd/wow/acore-custom/env/dist/data/dbc

# Editor export folders
WDBXEditor-Export      -> /home/pc/wd/wow/tools/WDBXEditor/Export
WoWSpellEditor-Export  -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export

cd acore-custom-dbc
ls
ItemCondExtCosts.dbc
Item.dbc          -> /home/pc/wd/wow/tools/WDBXEditor/Export/Item.dbc
Spell.dbc         -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/Spell.dbc
SpellMissile.dbc  -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/SpellMissile.dbc
SpellMissileMotion.dbc -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/SpellMissileMotion.dbc
...

The idea:

• The server's data/dbc folder (acore-custom-dbc) only contains real files or symlinks.
• The symlinks point at DBC files under Export/ folders.
• When you click Save / Save All in WDBXEditor or WoW Spell Editor, the files update both in Export/ and effectively in the core's dbc/ folder.

Important: for some DBCs (notably Item.dbc), running a modified version server-side can cause startup issues. In that case, keep the server DBC unpatched and only ship a patched copy to the client (see MPQ section below).

4.2. Editors

Two editors work well together:

• WDBXEditor – general-purpose DBC editing (e.g. CreatureDisplayInfo.dbc, CreatureModelData.dbc, Item.dbc, etc.).
• WoW Spell Editor – specialized spell tooling, exporting Spell.dbc, SpellMissile*.dbc, SpellVisual*.dbc, and a small patch-4.MPQ with related data.

Because WDBXEditor's default file dialogs are clumsy for repeated use, the symlink approach above lets you always open and save from the same, simple paths.

4.3. Building the client patch (MPQ)

On WoW 3.3.5a, the client uses a strict, path-based virtual filesystem inside MPQ archives. A helpful trick: a folder whose name ends with .MPQ is treated like an MPQ archive. If you drop files inside with the correct structure, the client will load them.

You can create a staging area like this:

python -m build_mpq.cli create /home/pc/Desktop/acore-custom-staging/patch-Z.MPQ

This creates something like:

/home/pc/Desktop/acore-custom-staging/patch-Z.MPQ
├── Cameras
├── Character
├── Creatures
├── DBFilesClient
│   ├── CreatureDisplayInfo.dbc -> /home/pc/wd/wow/tools/WDBXEditor/Export/CreatureDisplayInfo.dbc
│   ├── CreatureModelData.dbc   -> /home/pc/wd/wow/tools/WDBXEditor/Export/CreatureModelData.dbc
│   ├── Item.dbc                -> /home/pc/wd/wow/tools/WDBXEditor/Export/Item.dbc
│   ├── patch-4.MPQ             -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/patch-4.MPQ
│   ├── Spell.dbc               -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/Spell.dbc
│   ├── SpellMissile.dbc        -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/SpellMissile.dbc
│   ├── SpellMissileMotion.dbc  -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/SpellMissileMotion.dbc
│   ├── SpellVisual.dbc         -> /home/pc/wd/wow/tools/WoW\ Spell\ Editor/Export/SpellVisual.dbc
│   ├── SpellVisualEffectName.dbc        -> ...
│   ├── SpellVisualKit.dbc               -> ...
│   ├── SpellVisualKitAreaModel.dbc      -> ...
│   ├── SpellVisualKitModelAttach.dbc    -> ...
│   └── SpellVisualPrecastTransitions.dbc -> ...
├── Fonts
...

Now symlink this folder into your client Data/ directory:

ln -s \
  "/home/pc/Desktop/acore-custom-staging/patch-Z.MPQ" \
  ~/Games/wow335/Data

Because the client treats patch-Z.MPQ as an archive, it will load your custom DBFilesClient/* content when starting.

If you prefer working with real MPQ files, you can also use tools like mpqcli:

mv mpqcli-linux-amd64-glibc mpqcli
chmod +x mpqcli
# place mpqcli somewhere on $PATH so you can call `mpqcli` from anywhere

Then point it at your staging folders to build an actual .MPQ file.

5. Example concept: caravan event

As a concrete example, imagine a caravan event starting in Goldshire and traveling to another outpost. This can be implemented in many ways:

• A merchant caravan where you buy goods in A and sell in B for profit.
• A quest-based escort with a standard quest reward.
• A PvE event where the caravan is attacked by scripted bandits.
• An opt-in PvP event where players can join a "bandit" faction.
• A group escort with different difficulty tiers or a custom wanted-level system.

Server-side work for such an event might include:

• Custom creatures (the caravan NPCs and guards).
• Custom gameobjects (crates, barrels, wagons, dropped goods).
• Custom quests and scripts to drive the event.
• Custom items as rewards or trade goods.

Client-side work often requires:

• New or reused models and displays via CreatureDisplayInfo.dbc and CreatureModelData.dbc.
• Custom spell visuals (e.g. a "rope beam" tether when someone is attached to a wagon).
• Possibly new UI visuals or icons via additional MPQ content.

You can take inspiration from guides such as the stoneharry/DBC-Editing-Workflow style approach for structuring client changes.

5.1. Creating content with Keira3

Copying creatures by hand is tedious because a single creature definition touches many linked tables:

• creature_template
• creature_equip_template
• creature_model_info / addons
• smart_scripts (if using SmartAI)

Modern versions of Keira3 include features to duplicate an existing creature and automatically handle the related tables. This turns a multi-table manual copy into a single operation, and is ideal when:

• You want a "variant" of an existing NPC with different stats or visuals.
• You are building caravans or bandit squads by reusing templates from the base game.

Similarly, you can:

• Edit items in Keira directly in the world DB.
• Export the SQL diff and version-control it along with your module.

For quick client testing of custom items, you can use a helper addon like CustomItemFix to avoid immediate client patching at the cost of some limitations (for example, not being able to place the item directly on action bars).

5.2. Handy visual IDs

Some example visual/gameobject IDs that are often useful when prototyping:

• Various boxes / crates / barrels / bags for cargo:
  • 224, 10001, 10224 (ham/food-style props)
  • 10288 (barrel), 10285–10287 (boxes), 10323 (bag), 10334 (small barrel)
• Rope-style visual (for spell effects):
  • SpellVisual ID 66206 – rope beam style effect.
• Drop crate visual:
  • GameObjectDisplay / related visual ID 46342.

These are just references; you should always confirm IDs in your own client/DB tooling.

6. Pain points and tips

Some recurring friction points when modding 3.3.5a:

• Finding creature models
  • Use in-game GM tools (e.g. /gm) to look up and preview entries.
  • Keep a small test map or area where you can quickly spawn candidates.
• Finding and testing gameobjects
  • Keep a "sandbox" map with many spawned gameobjects for quick visual reference.
  • Remember that visuals may depend on DBC entries and client patches.
• Copying spells
  • Use a dedicated spell editor (like WoW Spell Editor) and export synchronized server + client DBCs.
  • Keep exports wired into your symlink setup so you cannot forget to ship a client copy.
• Copying creatures
  • Avoid manual multi-table copying when possible; use tools like Keira3 that know about all the linked tables.
• MPQ structure
  • The WoW 3.3.5a client only scans specific hard-coded paths for assets.
  • Keep a reference tree or script that creates the correct DBFilesClient/ and related subfolders.

7. Where to go next

With this environment in place, you can now:

• Prototype simple modules (custom vendors, teleporter NPCs, debug tools) quickly.
• Add client-side polish with custom spell visuals, sounds, and object displays.
• Iterate on more ambitious systems like the caravan event described above.

Future articles can dive deeper into:

• A full, step-by-step caravan event implementation.
• Advanced spell visual chaining and missile behavior.
• Integrating Lua/AIO frontends (mod-ale) with server modules for richer UX.