Why does the error name the jar I didn't touch?

Because that's the one that's now wrong. If you updated the addon, the core you still have is too old for it. If you updated the core, the addon you still have was built against an older core and doesn't know the new one's shape. Either direction, the error names whichever jar failed to keep up, not the one you actually downloaded.

Isn't this the same as any missing-dependency error?

Same shape, tighter tolerance. A mod depending on Fabric API usually accepts a wide range of Fabric API versions, so updating one side rarely breaks the other. A core and addon jar from the same author often share internal, undocumented interfaces that change between releases, so the addon is pinned to a narrow range of the core, sometimes a single version. Treat these pairs as glued together, not as a mod with a dependency.

My modpack manager says everything is up to date. Why does it still crash?

Because "up to date" can mean each jar individually matches its own latest release, checked separately, not that the pair matches each other. Some managers update mods one at a time as new versions appear rather than as a pack-wide batch, so the addon can land before the core, or the reverse. Update status per mod is not the same guarantee as version compatibility between two mods.

Does this happen with any two mods that depend on each other?

It's most common, and most severe, between a core and its own addons from the same author, because they share internal code that isn't a stable public API. Two unrelated mods that both depend on something like Fabric API run into it far less, because that shared dependency changes slowly and deliberately supports a range of versions. See fixing an incompatible mod set for the general version of this error.

How do I know what version of the core an addon actually needs?

Check the addon's own mod page, not the core's. The addon's description or changelog states the minimum, and often the exact, core version it was built against. That number is more current than anything you remember from when you first installed it.

I deleted the old core jar but forgot to add the new addon jar. What now?

Same failure, opposite direction: an addon that expects a core symbol the older core doesn't have, or a core the loader can't satisfy because nothing needs it anymore isn't the issue, a missing addon is. Get both jars from the same release page or same download pass, every time you touch either one.

Guidefor players4 min read

When a mod's core and addon jars fall out of sync

Xaero's Minimap and XaeroLib, Sophisticated Backpacks and Sophisticated Core: mods shipped as a library jar plus one or more addon jars, and what happens when you update only one of the pair.

Why some mods ship as two jars

Several popular mods are actually two downloads. Xaero's Minimap needs XaeroLib. Xaero's World Map needs the same XaeroLib. Sophisticated Backpacks needs Sophisticated Core. This isn't an accident or a packaging mistake: rendering code, data storage, and UI framework that multiple feature mods from the same author all need gets factored out once, into a shared library jar, instead of being duplicated inside every addon that uses it.

It's a reasonable architecture. Xaero's Minimap and Xaero's World Map both need the same map-rendering internals, so XaeroLib holds those once and both addons build on it. Sophisticated Backpacks needs storage and UI plumbing that Sophisticated Core provides, and other addons in that family use the same core rather than reimplementing it. The split saves the author real duplicated work, and it's common across the modding ecosystem well beyond these two examples.

The catch is that you now have two jars that both have to be right, not one.

Why this pairing is stricter than an ordinary dependency

A mod that depends on Fabric API is depending on something slow-moving and broadly compatible. Fabric API adds features without breaking old ones for long stretches, so a mod built against last month's Fabric API usually still works against this month's. That looseness is why checking mod compatibility treats "needs a library" as a mostly-solved problem once the library is present at roughly the right version.

A core and addon jar from the same author are a different situation. The interfaces between them are internal, not a published stable API, because both jars are maintained by one author who can change either side freely. That's exactly what makes the split useful for the author in the first place, and exactly what makes it fragile for you: the addon is often pinned to a narrow range of the core, sometimes to one specific version, not "anything equal or newer." Update one jar without the other and you've broken that pin.

This is what shows up, repeatedly, in real reports on both mod families:

"It says I need XaeroWorldMap 1.44.0 but I only have 1.39.12."
"Your lib is made for older versions... I don't know what you would have to do for that to not work."
"Sophisticated Backpacks and Sophisticated Core keep 'failing to load correctly.'"
"Sophisticated Core is incompatible with the new version of Just Enough Items."

Different mods, same failure shape: one half of a pair moved and the other didn't.

What the crash actually looks like

Sometimes the loader catches it cleanly, with a message naming the exact version it wanted. Other times it gets further before failing, and you get a real crash. A field or method that existed in the old core jar simply isn't there anymore, because the addon was compiled against a newer core than the one sitting in your mods folder. From a real Waystones crash log:

Caused by: java.lang.NoSuchFieldError:
  Class net.blay09.mods.waystones.core.WaystoneVisibility does not have
  member field 'TEAM'

That's the signature of a version mismatch between tightly coupled jars, not a corrupted install or a genuine bug. The addon (or a mod depending on it) is calling a symbol, TEAM on WaystoneVisibility, that only exists in a newer build than what's on disk. NoSuchFieldError and NoSuchMethodError both mean the same thing: compiled against one version, running against another.

The tell: which jar the error names versus which jar you touched

The direction is the diagnostic. Read the error and ask which jar it's unhappy with, then compare that against which jar you remember downloading:

Error names the core, you just updated the addon. The addon now expects a newer core than you have. Update the core to match.
Error names the addon (or a symbol the addon owns), you just updated the core. The addon was built against the old core's internals and hasn't caught up. Update the addon, or if no newer addon build exists yet, revert the core.

Either direction, the mismatch is never really about the jar the error names. It's about the jar you didn't touch.

The fix: update both, from the same moment

Don't patch one jar and leave the other. When either half of a core-addon pair needs updating:

Delete both old jars. Not just the one you're upgrading.
Download both current jars, from the same release moment, both from the same author's current pages.
Check the addon's own page for the core version it states it needs. That number is authoritative; your memory of what you installed originally is not.

If you're using a modpack manager or launcher, don't assume it updates dependency pairs atomically. Some update every mod in a pack together; others surface individual mods as available updates and let you apply them one at a time, which is exactly the gap that produces this error. After any update, however it was applied, open the mods folder and verify both jars' version numbers by hand, especially for a mod family you know ships in pairs.

When you're not sure a mod is part of a pair

If a mod page lists a "required" or "library" dependency from the same author, rather than a general-purpose library like Fabric API or Cloth Config, assume the pairing is tight until proven otherwise. Why mods are loader specific covers the broader reason mods are compiled against specific internals rather than a stable API, and the same logic applies here: two jars from one author, sharing unpublished internal code, move together or not at all.

Last reviewed 2026-08-05. Version data on this site updates automatically; this guide is reviewed by hand when the ecosystem changes.