Curios Compatibility

Curios Compatibility

Applies to Regalia Slots API 1.0.2 for Minecraft 1.21.1, and to 1.1.4 for 26.2.

What this is

Regalia Slots API is a fork of Curios API. But most third-party mods that integrate with accessories do not check "is there an accessory API" — they check for the specific mod id curios and link against classes in top.theillusivec4.curios.api. They do not recognise regalia_slots_api as an equivalent, and simply do not work.

So this mod ships a compatibility layer that makes those mods work without Curios installed.

In practice: install Regalia Slots API instead of Curios, and mods like Sophisticated Backpacks, Relics and Apothic Attributes keep working.

How it works

The JAR declares two logical mod ids:

• regalia_slots_api — the mod itself.
• curios — a compatibility entrypoint that registers the curios:inventory and curios:item capabilities under the ids real Curios uses.

Those capabilities are backed live by Regalia's own data. There is no second copy of your inventory, and the two ids cannot disagree — it is one set of slots under two names.

A verbatim copy of Curios' top.theillusivec4.curios.api package is included so that mods compiled against the real thing find the classes they expect at load time. Five of Curios' ServiceLoader services — the registry, slots, extensions, codecs and network — each have an adapter.

Client-side shims exist for a few Curios internal classes that some mods reference beyond the API package, so they do not fail with NoClassDefFoundError.

Incompatible with real Curios installed alongside

You cannot have both. Both JARs declare the mod id curios, and NeoForge refuses to load two mods with the same id.

This is a known, accepted limitation rather than something quietly worked around. Pick one.

Replacing real Curios on an existing world

Handled. Starting in 1.1.0, if a world was played with real Curios and you then swap the JAR for Regalia Slots API, your equipped items do not vanish.

The fork's rename did not touch the attachment id Curios used, nor the internal NBT key of its inventory — so without a bridge that data would be orphaned and appear lost. A read-only migration path watches for the original key on first login, copies each item into its equivalent slot, and returns anything that does not fit — a missing or occupied slot — to your normal inventory rather than destroying it. A marker prevents it running again on later logins.

Requires the real Curios JAR to be removed from mods/, for the duplicate-id reason above.

Known gaps

The layer gets a mod recognised and its slot read and written. It does not get everything.

Per-item custom behaviour is not bridged. Curios' ICurioItem / ICurio interfaces carry around twenty methods of per-item behaviour — custom sounds, glow, tooltips. None of that is bridged, so an item registered through the compatibility path gets default behaviour. This is the largest gap and it is the one you are most likely to notice.

Curios' own datapack codecs are stubs. ISlotType, ISlotData and IEntitiesData do not read from datapacks. Regalia remains the single source of truth for slot types, so a datapack written for real Curios will not configure Regalia the same way.

The Curios GUI is a load shim only. top.theillusivec4.curios.client.gui.CuriosScreen exists purely so mods referencing it — Apothic Attributes, for one — do not crash. Regalia's own screen does not extend it, so a mod that integrates with the Curios inventory screen loads but its integration is not actually attached. Known and accepted.

Curios' renderer registry is forwarded, not replaced. Client renderers registered by third-party mods (Relics, for example) are connected to the real render layer so they show up. Verified to build; rendering in game was not verified.

If something fails to load

A NoClassDefFoundError naming top/theillusivec4/curios/… means a mod is using a Curios symbol the shims do not cover. The class name in the error tells you which one is missing.

For developers

If your mod targets Curios, it will most likely work through this layer unchanged. If you want to support Regalia natively instead, use the API in the com.skd.regaliaslotsapi.api package — it is the supported surface. See For Developers.