ESODecoded

ESO Addon Shows Red "Dependency" and Won't Load — What It Means and How to Fix It

Addons · 10 min · updated 2026-08-22

✓ Current as of Update 50 (2026)⌨ Some tips use add-ons (PC)

The frustration“My addon says "Dependency" in red and won't load, and I don't want to quit to desktop.”

Red "Dependency" is one of three states that look alike in the ESO add-on list and are fixed three different ways. This page tells you what the red word means, how to read any addon's requirement line out of a text file you already have on disk, exactly where the missing folder goes, and the one thing about reloading that most guides get wrong. It ends with the addon loaded, and with a way to check every addon you own in one pass instead of one at a time.

What this page was checked against

Built 2026-08-22. Checked against the live game as it stood that day: interface (API) version 101050, which is Update 50, live since 2026-06-08. The next interface bump, Update 51, goes live on PC/Mac on September 28, 2026. Every rule quoted below carries the date it was fetched — all of the ESOUI quotes on this page were fetched on 2026-08-22, and the Update 51 date was verified at the ZeniMax announcement on 2026-08-19 and not re-fetched since.

You can read your own client's number in-game. The ESOUI dependency sticky gives the command verbatim: "/script d(GetAPIVersion())" (esoui.com/forums/showthread.php?t=9149, fetched 2026-08-22). If that prints 101050 you are on the same build this page was written against.

What the red word actually means

It is a real engine state, not a cosmetic hint. The live interface documentation defines an AddOnLoadState enum with a dedicated member for exactly this condition — ADDON_STATE_DEPENDENCIES_DISABLED — alongside ADDON_STATE_DISABLED, ADDON_STATE_ENABLED, ADDON_STATE_ERROR_STATE_UNABLE_TO_LOAD, ADDON_STATE_NO_STATE, ADDON_STATE_TOC_LOADED and ADDON_STATE_VERSION_MISMATCH (apidoc_101050.txt, lines 10354-10361, measured 2026-08-22). The game also exposes GetAddOnDependencyInfo, which returns, per dependency, both an "exists" flag and an "active" flag (line 24268) — which is precisely the missing-versus-switched-off distinction you are looking at.

ESOUI's dependency sticky states the on-screen version of it, fetched 2026-08-22: "If a dependency of an AddOn is missing you are able to see it directly in the in-game AddOn manager’s list, at the right column. The text “Dependency” is indicating it." The same post separates the two sub-states verbatim: "White entries are installed and enabled dependencies." / "Red entries are missing dependencies!" / "-If the dependency is installed the text “(Disabled)” is shown next to the dependency name." / "-If the dependency is totally missing (not installed yet) the text line will be simply red w/o the text “Disabled”."

So read the red line before you do anything: red WITH "(Disabled)" means the thing is already on your drive and just needs ticking. Red WITHOUT "(Disabled)" means you have to go and get it.

Read the requirement yourself: the ## DependsOn line

Every addon carries a manifest — a small text file inside its own folder, with the same base name as the folder. Two directives in it declare what it needs. ESOUI's dependency sticky, fetched 2026-08-22: "Must dependency: Another addon or library which must be installed and enabled in the in-game addon manager in order to enable the addon in question at all. The AddOn will not load in total in that case. The must dependency is defined via the ## DependsOn: tag in the txt files of addons." The soft one, same post, verbatim: "The optional dependency is defined via the ## OptionalDependsOn: tag in the txt files of addons."

A name can carry a version floor. The same sticky gives the syntax verbatim as "## DependsOn: LibAddonMenu-2.0>=41". The >= is a minimum, not an exact match: >=41 means version 41 or anything newer. This is the failure people miss — the folder is present, so it looks installed, but the copy on disk is older than the floor, and the line still shows red.

Open the file in any text editor. It is plain text; nothing installs and nothing runs. The manifest is usually <Folder>\<Folder>.txt, but not always: some authors ship it as <Folder>\<Folder>.addon instead. SkyShards does — its manifest is SkyShards\SkyShards.addon (SkyShards v10.64, read from our addon corpus 2026-08-22). If you find no .txt in the folder, look for a .addon.

Worked example: Pithka's Achievement Tracker

The addon installs one folder, PithkaAchievementTracker, and its manifest is PithkaAchievementTracker\PithkaAchievementTracker.txt. The requirement line in it reads, verbatim (read from our addon corpus 2026-08-22): "## DependsOn: LibAddonMenu-2.0>=40 LibQRCode".

That is the whole answer to "what does it want": two things, one of which has a floor. LibAddonMenu-2.0 at version 40 or newer, and LibQRCode at any version. Nothing else on that line, so nothing else is a hard requirement. Its optional line names LibDebugLogger, LibHarvensAddonSettings and LibStub — optional means the addon loads without them.

Both are on ESOUI as standalone downloads. As of our dataset (built 2026-08-22 from the feed retrieved 2026-08-19), LibAddonMenu-2.0 declares interface version 101050 — the live one — and 1,408 addons in the catalogue depend on it, so it is very likely you already have it. LibQRCode declares 101046 and has 2 dependents. The tracker itself declares 101046, so expect it to also carry the "Out of Date" flag; that is a separate matter and does not stop it loading.

The on-disk shape: beside, never inside

ESOUI's install FAQ gives the PC path verbatim (fetched 2026-08-22): "C:\Users\< username >\Documents\Elder Scrolls Online\live\AddOns\< AddOn A FolderName >\< files >". The Mac line on the same page, verbatim: "~/Documents/Elder Scrolls Online/live/AddOns/< AddOn A FolderName >/< files >". (Worth knowing: a browser parses "< username >" as a tag and swallows it, so the rendered FAQ page displays that path with the placeholder missing. The source is as quoted.)

The troubleshooting sticky adds two things that bite people, fetched 2026-08-22: "Your addons need to be placed in the folder /live/AddOns (create the folder if it is missing, but please watch the case-sensitive name, with capital A and O!)." and "Important: The live/AddOns folder will be created after your first login to the game, it will be missing if you had not logged in before at least once!"

Every addon and every library sits at the same level, side by side. A library is not filed under the addon that needs it. The commonest single failure is one folder too deep — you unzip and get LibAddonMenu-2.0\LibAddonMenu-2.0\LibAddonMenu-2.0.txt, or you drop the library inside the addon's folder because that is where it is "for".

The honest answer to "without quitting to desktop"

You cannot reliably do it. For a folder that was not there when the client started, the manifests are not re-read by /reloadui. The troubleshooting sticky, fetched 2026-08-22, verbatim: "The game read those txt files in total at first client login, and not always "in total" if you just do a character switch or /reloadui ingame)." The dependency sticky is blunter still, verbatim: "Logout AND close the game ESO!" and "Better log out before installing them and close the game in order to let the in-game AddOn manager detect all new/changed dependencies and their load-order properly".

This is not the same as saying /reloadui does nothing — the function is real and still in the live interface documentation (ReloadUI, apidoc_101050.txt line 11423, measured 2026-08-22). It reloads the interface. It is the manifest scan for folders the client has never seen that it does not reliably redo. So: add folders, close the game fully, start it again. That single habit removes most of the "I installed it and it isn't there" reports.

Tick the library too — then confirm it loaded

A hard dependency has to be both present and switched on. From the definition quoted above, verbatim: a must dependency is one "which must be installed and enabled in the in-game addon manager in order to enable the addon in question at all". Installing the library and leaving it unticked produces the red "(Disabled)" variant, which reads to most people like the install failed.

Confirming it worked is a named on-screen state, not a feeling: the dependency line for that addon turns from red to white — "White entries are installed and enabled dependencies." — and the addon stops showing "Dependency" in the right-hand column. After that, use whatever entry point the addon's own listing names: a slash command, or an entry under ESC → Settings → Add-Ons.

One caveat we will not paper over: we could not establish, from any source retrieved on 2026-08-22, whether a library that declares itself a library is hidden from the add-on list or shown in it. Treat "tick everything you just installed" as the safe instruction — ticking something that is already handled costs nothing, and leaving a library unticked is a documented failure.

The duplicate-library trap — measured

Libraries are not only distributed standalone. Authors bundle copies inside their own downloads, and that is measurable. Across the 3,163 addons in our 2026-08-19 feed snapshot, the corpus scan (built 2026-08-22) finds 3,192 distinct install-folder names, of which 240 are shipped by more than one download. LibAddonMenu-2.0 is the extreme case: 87 different downloads ship a folder by that name. Only one of them is the standalone library; the rest carry a bundled copy.

A stale bundled copy is a known cause of breakage, and the documented instruction is to delete it. The dependency sticky, in its LibStub-removal section, fetched 2026-08-22, verbatim: "Delete the folder /libs/LibAddonMenu-2.0/ as it is outdated and will cause problems!"

A real instance of duplicate-registration damage, from an author's own changelog (HodorReflexes, entry dated 2025.04.08, read from our addon corpus 2026-08-22): the error "user:/AddOns/LibGroupBroadcast/HandlerManager.lua:34: Handler name 'GroupResources' has already been registered by 'LibGroupResources'." — and the author's own fix, verbatim: "Do not click reinstall in Minion, it will not help. Uninstall LibGroupBroadcast and then install it again after it got removed."

Which copy wins when you have two — not establishedUnverified

We are not going to guess at this one. No source we retrieved on 2026-08-22 states the order in which the game resolves two copies of the same library in different places. Anyone telling you "the standalone always wins" or "the bundled one always wins" is asserting something we could not source.

So the rule we give is the documented remedy rather than a statement about engine behaviour: keep the standalone folder in live\AddOns, delete the bundled copy that sits inside another addon's folder, and if deleting it breaks that addon, put it back and raise it with that addon's author. That sequence works whichever copy the game happens to prefer, which is exactly why we recommend it.

Undoing it — and where your settings physically live first

Removing an addon is deleting its folder from live\AddOns. Before you delete anything, know where the accumulated data is, because it is not in the addon's folder. The ESOUI request sticky, fetched 2026-08-22, verbatim (including its own typo): "SavedVariablse are stored in live/SavedVariables but we do not have access to the files directly, only via the ZO_SavedVars wrapper class". The same post explains why editing them while the game runs achieves nothing, verbatim: "They are copied in internal game memory and only read from that memory, saved to the disk on a reloadui or zone change with a loading screen. Any altered data on the disk file will be overwritten from internal game memory at that point!"

So: live\SavedVariables holds the settings and data; live\AddOns holds the code. Delete a folder from AddOns and the matching SavedVariables file stays behind, which is what lets you reinstall later without losing anything. Copy live\SavedVariables somewhere safe with the game closed if you want a real backup.

Before deleting a library, check what else wants it. In our dataset, LibAddonMenu-2.0 has 1,408 dependents and LibQRCode has 2 — deleting the first would break a large fraction of your setup, and deleting the second breaks almost nothing. Every addon page on this site prints that count.

Do this for everything you own, in one pass

Doing it addon by addon is the slow way. 1,782 of the 3,163 addons in our snapshot declare at least one required dependency, and our closure resolver traces 1,763 of those requirement sets all the way to named ESOUI downloads (data/addon_deep.json, built 2026-08-22). That is what powers the "You need N things" list on each addon page here — the required set, in install order, each with its own version floor and its own current status.

Paste your AddOns directory listing into the folder checker and it will tell you, for everything you actually have installed, which required folders are missing. If you are staring at an error rather than a red line, the folder resolver turns the path in the error into the addon that owns it.

What this guide cannot tell youUnverified

Which copy of a library the game loads when two are installed in different places. No source retrieved on 2026-08-22 states the resolution order; the instruction above (keep the standalone, delete the bundled one) is the documented remedy, not a statement of engine behaviour.

Whether a library is displayed in the in-game add-on list or hidden from it. We could not establish this either way on 2026-08-22, which is why the instruction is "tick everything you installed".

Whether the version of a library you already have on disk clears an addon's floor. Our dataset knows the floor a manifest declares and the version currently published on ESOUI; it cannot see the copy on your drive. Open that library's own manifest and read its ## Version line.

Anything about ZeniMax's position on any of this. ZeniMax's Add-On Terms of Use page returned only "This page is under translation." when fetched on 2026-08-22, so no first-party rule text about add-ons was retrievable that day. Everything quoted here is either ESOUI's own documentation or a measurement of the game's own interface documentation.

Console. This whole procedure is the PC/Mac add-on folder and the PC add-on list. Console add-ons are obtained a completely different way — see the console guide.

Red "Dependency" is the most fixable state in the add-on list, because the addon has already told you exactly what it wants — the line is sitting in a text file in its own folder. Read the line, put the folders side by side, restart the client fully, tick everything. Then check the rest of your set in one pass rather than waiting to be surprised by the next one.

Sources & further reading

Related

All 3,163 addons, datedCheck my whole AddOns folderWhich addon is this error?Folder → addon indexPatch-Break RadarAddon Creator'Out of date' after an updateWhich addon is crashing my UIIs an auto-anything addon allowed?Add-ons on console