FAQ

FAQ

Do I need all 73 modules?

No. Each module is a separate LoadOnDemand sibling addon. Your consumer only loads the ones it actually queries — the others sit on disk costing nothing at runtime. See Architecture: Per-module LoadOnDemand.

If you only need NPC and Quest data, embed LibCodex-1.0 (core) plus LibCodex-1.0-NPCs and LibCodex-1.0-Quests. Skip the other 71 directories.

Which WoW versions are supported?

The library publishes a TOC for every live flavor:

• Retail (Live) and Retail (Midnight beta)
• Mists of Pandaria Classic
• TBC Anniversary (Burning Crusade)
• Classic Era (Vanilla)
• PTR

The bundled data per module is generated separately for each flavor where applicable. A module that exists only in Retail (e.g., CustomizationOptions) won't ship a Vanilla-flavored data file.

Can I redistribute LibCodex inside my addon?

Yes. The MIT license permits embedding. The standard pattern is to vendor LibCodex-1.0 plus whichever module sub-addons you need into your addon's Libs/ directory and reference them from your TOC's ## libs: directive (BigWigs Packager handles this automatically if you list LibCodex in your .pkgmeta externals). See Getting Started: Embedding via BigWigs Packager.

A credit in your addon's README or about page is appreciated but not required.

What's the difference between LibCodex and consumer addons like Vellum or Forge?

LibCodex is the data layer. It carries the catalogs and the lookup API. It has no UI of its own beyond the standalone diagnostic log window.

Vellum is an in-house Zygor-style guide addon that consumes LibCodex's Quests module as its data source.

Forge is a dev-tools suite for Cairn / LibCodex addon authors — Forge_Codex is the in-game catalog browser that replaces LibCodex's old GUI dashboard, and Forge_Console, Forge_Logs, etc. are sibling sub-addons.

If you're building an addon that needs WoW game data, you're a LibCodex consumer. Vellum and Forge are examples of what consumers look like.

Why is LibCodexDB so large?

LibCodexDB accumulates everything the runtime adapter has captured across all your sessions: NPCs you've seen, items you've held, quests you've accepted, taxi nodes you've visited. It grows with playtime.

If it's getting unwieldy, you can:

• Delete WTF/Account/<account>/SavedVariables/LibCodex.lua to reset to bundled-seed-only.
• Disable the auto-scan ticker: /run LibCodex.Runtime.SetAutoScan(false).
• Disable the entire Runtime adapter by editing your addon's TOC to skip Adapters\Runtime.lua (you keep the bundled seed but stop accumulating runtime data).

Why two version numbers?

LibCodex follows the LibStub convention. LIB_MAJOR is the literal string "LibCodex-1.0" — the public identity. It only changes if the library makes a breaking API change, in which case it would become LibCodex-2.0 (a separate library that can coexist with LibCodex-1.0).

LIB_MINOR is a sequential integer that bumps +1 on every release. LibStub keeps whichever copy is registered with the highest minor, so a newer release loaded by any consumer addon takes precedence over older copies embedded elsewhere.

How do I know which copy of LibCodex won?

local LC = LibStub("LibCodex-1.0")
print(LC:VersionString())
-- LibCodex-1.0 v7 (modules:73 adapters:1)

The build number is the integer after v.

Why don't :Get results return the same table on subsequent calls?

They do. :Get(id) returns the same Lua table reference each time you call it — modifications you make to the returned entry persist, and other consumers see them. Treat returned entries as shared state. If you need an isolated copy, deep-clone it.

What's _handcrafted?

A field on an entry that locks every other field against future merges. Used for hand-curated rows in Data/<Module>.lua that should not be overwritten when the bake tool re-emits the module from import sources, or when the runtime adapter pushes a fresh observation.

For partial locks, use _locked = { "fieldName1", "fieldName2" } instead. See Architecture: Source provenance and locked fields.

My addon errors with "attempt to index a nil value (method 'NPCs')"

You called LC:NPCs() before the NPCs module registered. Either:

• Your TOC loads your addon's code before LibCodex's modules. Move the call to a PLAYER_LOGIN handler.
• The LibCodex-1.0-NPCs LoadOnDemand sub-addon isn't installed or is disabled. Force-load it: LC:LoadModule("NPCs"). If it returns false, the addon is missing.

My addon errors with "attempt to call a nil value (method 'Get')"

The module returned nil. Same root cause as above — module isn't registered. Check LC:IsModuleLoaded("NPCs").

What does /codex do?

In a standalone install, /codex registers a slash command for diagnostics. The current surface is mostly the log window plus a few subcommands:

• /codex — open the log window.
• /codex verbose on|off — toggle the Runtime adapter's verbose logging.
• /codex gui — redirects to Forge_Codex (the consumer addon that hosts the catalog browser UI).

/codex is only available when LibCodex runs as a standalone addon. Embedded copies don't register the slash command.

Where can I see the bundled data without loading the addon?

LibCodex-1.0-<Module>/Data/<Module>.lua in the repo. Each file is a series of LibCodex:_FeedBundledRowsLazy(...) calls with the rows tables inline. They're plain Lua, readable in any editor.

For interactive browsing in-game, use Forge_Codex from the Forge addon suite.

Can I help with crowdsourcing?

Crowdsourcing is planned but not yet implemented. There's nothing to upload to today. The library design is keeping the right schema invariants now so the pipeline can drop in cleanly later. If you have opinions on the design (conflict resolution, trust model, push cadence), file an issue tagged crowdsource.