API Extensible Armature

The Animation Armature system is extensible.

Third-party mods may register custom armature types, allowing animation definitions to reference armatures through their own identifiers while resolving them to existing Epic Fight Armature assets.

Every armature type consists of:

• An armature identifier.
• An Armature accessor.

Unlike Animation Accessors and Animation Groups, armature types primarily provide a named bridge between JSON data and an existing Epic Fight armature asset.

---

🧩 Architecture

ExtendedDatapacksRegistry
          │
          ▼
     IArmatureType
          │
          ├───────────────┐
          ▼               ▼
       id()           armature()
          │               │
          ▼               ▼
    JSON Identifier   Armature Asset

An IArmatureType associates a serialized identifier with an AssetAccessor pointing to an Epic Fight Armature.

For example:

epicfight:entity/biped
        │
        ▼
   Armatures.BIPED

---

📦 Step 1 — Create the Armature Type

Armature types implement:

IArmatureType

The interface provides:

• The identifier used in JSON.
• The armature accessor resolved at runtime.

Example

public enum EpicFightArmatureTypes
        implements IArmatureType {

    BIPED(
        "epicfight:entity/biped",
        Armatures.BIPED
    ),

    CREEPER(
        "epicfight:entity/creeper",
        Armatures.CREEPER
    ),

    ENDERMAN(
        "epicfight:entity/enderman",
        Armatures.ENDERMAN
    ),

    SKELETON(
        "epicfight:entity/skeleton",
        Armatures.SKELETON
    ),

    SPIDER(
        "epicfight:entity/spider",
        Armatures.SPIDER
    ),

    IRON_GOLEM(
        "epicfight:entity/iron_golem",
        Armatures.IRON_GOLEM
    ),

    RAVAGER(
        "epicfight:entity/ravager",
        Armatures.RAVAGER
    ),

    VEX(
        "epicfight:entity/vex",
        Armatures.VEX
    ),

    PIGLIN(
        "epicfight:entity/piglin",
        Armatures.PIGLIN
    ),

    HOGLIN(
        "epicfight:entity/hoglin",
        Armatures.HOGLIN
    ),

    DRAGON(
        "epicfight:entity/dragon",
        Armatures.DRAGON
    ),

    WITHER(
        "epicfight:entity/wither",
        Armatures.WITHER
    );

    private final String id;
    private final AssetAccessor<? extends Armature> accessor;

    EpicFightArmatureTypes(
            String id,
            AssetAccessor<? extends Armature> accessor) {

        this.id = id;
        this.accessor = accessor;
    }

    @Override
    public String id() {
        return id;
    }

    @Override
    public AssetAccessor<? extends Armature> armature() {
        return accessor;
    }
}

The identifier is explicitly defined by:

String id()

For example:

epicfight:entity/biped
epicfight:entity/creeper
epicfight:entity/enderman
epicfight:entity/skeleton

These identifiers are the values that appear in animation JSON.

---

📦 Step 2 — Provide the Armature Accessor

Each armature type must provide an:

AssetAccessor<? extends Armature>

through:

armature()

For an existing Epic Fight armature, this can directly reference its corresponding accessor:

Armatures.BIPED

For example:

BIPED(
    "epicfight:entity/biped",
    Armatures.BIPED
)

This establishes the relationship:

JSON identifier
      │
      ▼
epicfight:entity/biped
      │
      ▼
EpicFightArmatureTypes.BIPED
      │
      ▼
Armatures.BIPED
      │
      ▼
Epic Fight Armature

The armature type therefore does not need to contain the armature itself; it provides the accessor used to resolve it.

---

📦 Step 3 — Register the Armature Type

Armature types are registered through the centralized:

ExtendedDatapacksRegistry

using:

ANIMATION_ARMATURE

Single armature registry

ExtendedDatapacksRegistry.ANIMATION_ARMATURE.register(
        MOD_ID,
        EpicFightArmatureTypes.class
);

Multiple armature registries

Multiple enum classes can be registered in a single call:

ExtendedDatapacksRegistry.ANIMATION_ARMATURE.register(
        MOD_ID,
        EpicFightArmatureTypes.class,
        CustomArmatureTypes.class
);

The registry automatically verifies that every supplied enum implements:

IArmatureType

Invalid classes are rejected and a warning is emitted to the log.

---

📄 Datapack Usage

Once registered, an armature type can be referenced directly from animation JSON.

For example:

{
  "mod_id": "efdg",
  "type": "static",
  "transition_time": 0.15,
  "animation": "biped/living/greatsword_dual_idle",
  "armature": "epicfight:entity/biped",
  "is_repeat": true
}

The:

"armature": "epicfight:entity/biped"

field identifies the registered armature type.

The corresponding IArmatureType then provides the AssetAccessor used to resolve the actual Epic Fight armature.

---

🔄 Serialization

Armature types are exposed to the animation codecs through the armature registry.

Conceptually, the JSON value:

"epicfight:entity/biped"

is decoded into:

IArmatureType
      │
      ▼
EpicFightArmatureTypes.BIPED
      │
      ▼
AssetAccessor<Armature>

This allows animation accessors and other data-driven systems to work with armatures through the common IArmatureType abstraction rather than directly depending on a particular Armatures constant.

---

🧱 Custom Armatures

A third-party mod can define its own armature type by implementing IArmatureType:

public enum CustomArmatureTypes
        implements IArmatureType {

    CUSTOM(
        "example_mod:entity/custom",
        CustomArmatures.CUSTOM
    );

    private final String id;
    private final AssetAccessor<? extends Armature> accessor;

    CustomArmatureTypes(
            String id,
            AssetAccessor<? extends Armature> accessor) {

        this.id = id;
        this.accessor = accessor;
    }

    @Override
    public String id() {
        return id;
    }

    @Override
    public AssetAccessor<? extends Armature> armature() {
        return accessor;
    }
}

Then register it:

ExtendedDatapacksRegistry.ANIMATION_ARMATURE.register(
        MOD_ID,
        CustomArmatureTypes.class
);

It can subsequently be referenced by its identifier:

{
  "armature": "example_mod:entity/custom"
}

The actual Armature resolution remains encapsulated by the AssetAccessor supplied by the implementation.

---

⚙️ Registration Lifecycle

Armature types must be registered before Extended Datapacks initializes and consumes its animation registries.

Attempting to register an armature type after the registry has been consumed will throw:

RegistryObjectException

Registration should therefore occur during mod initialization:

private static void registerAnimationArmatures() {
    ExtendedDatapacksRegistry.ANIMATION_ARMATURE.register(
            MOD_ID,
            EpicFightArmatureTypes.class
    );
}

---

🔗 Armatures in the Animation API

Armatures are used by several other extensible animation systems.

For example, an animation accessor can declare:

IArmatureType armatureType

and decode it through the armature registry:

ArmatureTypeRegistry.CODEC
    .fieldOf("armature")

This creates a clean dependency chain:

Animation JSON
      │
      ▼
"armature"
      │
      ▼
ArmatureTypeRegistry
      │
      ▼
IArmatureType
      │
      ▼
AssetAccessor<Armature>
      │
      ▼
Epic Fight Armature

Consequently, an animation accessor does not need to hard-code every supported Epic Fight armature. New armature types can be added independently through the extension API.

---

⚠️ Notes

• Custom armature types must implement IArmatureType.
• Every armature type provides an explicit identifier through IArmatureType.id().
• Every armature type provides an AssetAccessor<? extends Armature> through armature().
• Register armature enum classes through ExtendedDatapacksRegistry.ANIMATION_ARMATURE.
• Multiple armature enum classes can be registered in a single call.
• The identifier is the value used by animation JSON in the armature field.
• The armature type acts as an abstraction between serialized JSON and the actual Epic Fight Armature.
• Animation accessors can consume IArmatureType without directly depending on a concrete Armature implementation.
• Registration must occur before Extended Datapacks initializes and consumes its animation registries.
• The centralized ExtendedDatapacksRegistry is the recommended registration API.