For Developers

For Developers

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

Depending on it

repositories {
    maven {
        name = "RegaliaSlotsApi"
        url = uri("https://gitlab.com/api/v4/projects/<project-id>/packages/maven")
    }
}

dependencies {
    runtimeOnly "com.skd.regaliaslotsapi:regalia_slots_api-neoforge:${version}"
    compileOnly "com.skd.regaliaslotsapi:regalia_slots_api-neoforge:${version}:api"
}

runtimeOnly for normal operation, compileOnly for the api classifier when you are writing against the API. Replace ${version} with the version you want.

The two supported entry points

1. The Regalia API — preferred

Package com.skd.regaliaslotsapi.api. This is the supported surface and the one that will not be removed. Notable types:

Type	Purpose
RegaliaSlotsApi	Entry point.
SlotType	The slot type itself, built through a builder.
SlotPredicate	Filters — reads a slots list from JSON.
SlotContext / SlotResult	Slot interaction callbacks.
SlotAttribute	Attribute handling for slotted items.
RegaliaSlotsApiTags	The tag conventions.
RegaliaSlotsApiCapability	The inventory capability.

Use the SlotType builder, not SlotTypePreset. The preset enum is deprecated and scheduled for removal in Minecraft 1.22 — see Slots.

2. The Curios API — works, but borrowed

Package top.theillusivec4.curios.api. A verbatim copy of Curios' API package, present so mods compiled against real Curios load and work.

You may code against it, and that is the point. But it is someone else's API under someone else's namespace, it comes with the gaps listed in Curios Compatibility, and it is not where new Regalia features will land.

Registering a slot

Slots are on demand. Nothing appears because you registered a type — it appears because a type exists and something can occupy it, or because a player forces it.

The flow:

1. Build a SlotType with an identifier, an icon, an order and a validator.
2. Declare which entities may have it — by default via data/regalia_slots_api/tags/entity_type/player_like.json.
3. Tag the items that belong in it, under data/<yournamespace>/curios/slots/<slot>.json.

Identifiers are the merge key. Two mods registering the same identifier get one slot, not two. That is deliberate — it is what stops a dozen mods each adding their own ring — but it means the identifier you pick is a shared namespace. Pick something namespaced if you mean something specific.

Data-driven, not code-driven

Categorising an item into a slot needs no code. A JSON file under data/<yournamespace>/curios/slots/ is enough, and a datapack can override the lot.

A slot file declares an order, an icon and a list of validators. The default validator is the tag validator, so the slot's contents are defined by item tags.

Player control

A player can be given or have taken a number of slots of a given type through the API, and slots can be enabled or disabled per player. The same operations are available to server operators as commands — see Commands.

Things that will bite you

SlotTypePreset is deprecated and scheduled for removal in 1.22. It also lists only ten entries and omits feet, so anything using it will not see that slot. Build through SlotType instead.

The build system is Curios', not the studio standard. This fork keeps Curios' original Gradle setup — version/group/mod_id keys and generated mod metadata — rather than the net.neoforged.moddev template with mod_version/mod_group_id. Do not force the standard template onto it; the original architecture is kept to avoid breaking the build.

Per-item custom behaviour does not work through the Curios path. ICurioItem / ICurio is not bridged. If your mod depends on custom sounds, glow or tooltips, code against the Regalia API.

There are roughly 46 inherited deprecation warnings in a clean build, carried over from Curios' own unfinished migration to NeoForge's newer item APIs. They are known and are being left alone. An automated cleanup was attempted once and broke slot validation and changed a public method signature, so it was reverted — do not retry it blind. Wait for Curios to finish its own migration and port their real fix.

What is intentional and must not be "cleaned up"

The top/theillusivec4/curios/ tree and the Curios* classes under the compatibility package look like leftovers from the fork. They are not. They are what makes binary compatibility with mods compiled against real Curios possible, and removing them breaks every one of those mods.