Enemies & Allies

Register reusable enemy templates, write custom AI strategies, and define combat allies that fight alongside the player.

Enemies

An enemy template is a reusable set of combat stats tied to a mob entity type. Once registered, biome JSON can reference it by id with "enemy": "<id>" instead of spelling out the same stats in every biome that uses that mob. Templates are registered with CrafticsAPI.registerEnemy().

Enemy templates can also be loaded from JSON datapacks with no Java code required. Both approaches produce the same result: a named entry in the enemy registry that biomes can reference.

Java API

Build an EnemyEntry with its fluent builder and pass it to CrafticsAPI.registerEnemy():

EnemyEntry entry = EnemyEntry.builder("mymod:desert_husk", "minecraft:husk")
    .ai("minecraft:skeleton")   // optional: use a different AI key
    .hp(10)
    .attack(3)
    .defense(1)
    .range(1)
    .speed(2)
    .build();

CrafticsAPI.registerEnemy(entry);

JSON Datapack Schema

Place JSON files at data/<namespace>/craftics/enemies/<name>.json. The id and entity fields are required. All stat fields are optional and fall back to the same defaults as the Java builder. The entity value must be a valid, loaded entity type or the file is skipped with a warning.

Example JSON

// data/mymod/craftics/enemies/desert_husk.json
{
  "id": "mymod:desert_husk",
  "entity": "minecraft:husk",
  "ai": "minecraft:skeleton",
  "hp": 10,
  "attack": 3,
  "defense": 1,
  "range": 1,
  "speed": 2
}

Once loaded, a biome JSON can reference this template with "enemy": "mymod:desert_husk" instead of repeating all the stat fields inline.

Enemy AI

Craftics uses a strategy interface, EnemyAI, to decide what each enemy does on its turn. Built-in strategies cover all vanilla hostile mobs. Addon mods can register custom strategies for new mob types (or override behavior for existing ones) with CrafticsAPI.registerAI().

Registration

CrafticsAPI.registerAI("mymod:custom_zombie", (self, arena, playerPos) -> {
    // Decide what this enemy does this turn and return an EnemyAction.
    return new EnemyAction.MoveAndAttack(path, self.getAttackPower());
});

The first argument is the entity type id (or any custom string you used as the ai key in an enemy template). The second argument is an EnemyAI instance, which is a functional interface.

The EnemyAI Interface

public interface EnemyAI {
    EnemyAction decideAction(CombatEntity self, GridArena arena, GridPos playerPos);

    default Set<GridPos> computeThreatTiles(CombatEntity self, GridArena arena) {
        return null; // null = use the generic speed+range danger diamond
    }
}

decideAction is called once per enemy turn. It receives the enemy's own CombatEntity, the full GridArena (tile data, occupancy, obstacle positions), and the player's current GridPos. Return any EnemyAction record to describe what the enemy does.

computeThreatTiles is optional. Override it when the enemy's real attack reach does not match the generic danger diamond computed from speed + range. Return a set of GridPos values that Craftics will highlight red as the danger indicator for the player. Return null (the default) to use the generic formula.

AIUtils Helpers

The AIUtils class provides pathfinding and geometry helpers so you do not have to implement common patterns from scratch.

EnemyAction Types

EnemyAction is a sealed interface. Return one of these records from decideAction. The records marked with an asterisk carry additional fields described below the table.

Supported Mob Types (Built-in)

These mobs already have registered AI strategies. You can use them in enemy templates and biome JSON without writing any code.

• Passive: minecraft:cow, minecraft:pig, minecraft:sheep, minecraft:chicken, minecraft:horse, minecraft:donkey, minecraft:panda, minecraft:parrot, minecraft:rabbit, minecraft:bat, minecraft:cod, minecraft:salmon, minecraft:axolotl, minecraft:cat, minecraft:ocelot, minecraft:fox, minecraft:bee, minecraft:wolf, minecraft:goat, minecraft:polar_bear, minecraft:llama
• Hostile: minecraft:zombie, minecraft:zombie_villager, minecraft:husk, minecraft:drowned, minecraft:zombified_piglin, minecraft:skeleton, minecraft:stray, minecraft:bogged, minecraft:spider, minecraft:cave_spider, minecraft:creeper, minecraft:vindicator, minecraft:evoker, minecraft:pillager, minecraft:ravager, minecraft:witch, minecraft:enderman, minecraft:endermite, minecraft:phantom, minecraft:silverfish, minecraft:slime, minecraft:hoglin, minecraft:piglin, minecraft:blaze, minecraft:ghast, minecraft:shulker, minecraft:breeze, minecraft:magma_cube, minecraft:wither_skeleton
• Boss: minecraft:warden, minecraft:ender_dragon

Example: Custom Ranged AI

import com.crackedgames.craftics.combat.ai.EnemyAI;
import com.crackedgames.craftics.combat.ai.EnemyAction;
import com.crackedgames.craftics.combat.ai.AIUtils;

// A simple ranged AI: attack in place if in range, else close the distance.
EnemyAI archerAI = (self, arena, playerPos) -> {
    int dist = self.getGridPos().manhattanDistance(playerPos);
    int range = self.getRange();

    if (dist <= range && AIUtils.hasCardinalLOS(arena, self.getGridPos(), playerPos, range)) {
        // Already in range with a clear line: shoot.
        return new EnemyAction.RangedAttack(self.getAttackPower(), "arrow");
    }

    // Out of range or blocked: move toward the player.
    return AIUtils.seekOrWander(self, arena, playerPos);
};

CrafticsAPI.registerAI("mymod:dungeon_archer", archerAI);

Allies

Combat allies are mobs recruited from the player's hub that fight alongside them in the arena. Allies have their own combat stats and can optionally scale with the owner's gear, accept a heal item during combat, or run a custom per-round effect. Allies are registered with CrafticsAPI.registerAlly().

Like enemies, allies can be defined in JSON datapacks. Datapack allies always use the default melee AI. Allies that need a custom AI strategy, a per-round hook, or programmatic stat logic must be registered through the Java API.

Java API

AllyEntry entry = AllyEntry.builder("minecraft:wolf")
    .hp(12)
    .attack(4)
    .defense(1)
    .range(1)
    .speed(3)
    .recruitMode(AllyEntry.RecruitMode.TAMED)
    .scalesWithOwnerGear(true)
    .healItem(Items.BONE, 6)
    .build();

CrafticsAPI.registerAlly(entry);

RecruitMode Values

JSON Datapack Schema

Place JSON files at data/<namespace>/craftics/allies/<name>.json. The entity field is required. Datapack allies always use the default melee AI and cannot have a per-round hook.

Example JSON

// data/mymod/craftics/allies/iron_golem.json
{
  "entity": "minecraft:iron_golem",
  "hp": 20,
  "attack": 6,
  "defense": 3,
  "range": 1,
  "speed": 1,
  "recruit_mode": "BUILT",
  "scales_with_owner_gear": false
}

Example: Custom Ally with a Round Hook

Round hooks require the Java API. The hook receives the living ally as a CombatEntity and the arena's EnvironmentDef. It is called once per round for each living ally of this type.

import com.crackedgames.craftics.api.CrafticsAPI;
import com.crackedgames.craftics.api.registry.AllyEntry;

CrafticsAPI.registerAlly(AllyEntry.builder("minecraft:cat")
    .hp(8)
    .attack(2)
    .defense(0)
    .range(1)
    .speed(3)
    .recruitMode(AllyEntry.RecruitMode.TAMED)
    .scalesWithOwnerGear(false)
    .roundHook((self, environment) -> {
        // Round hook receives the ally itself and the arena environment.
        // Use self to read or modify the ally's own combat state each round.
    })
    .build());

Field Ally Providers

Craftics' battle party is built from real mobs standing in the hub. You Shift+Right-Click a wolf to tag it, and when combat starts it is snapshotted, removed from the hub, fielded as an ally, and put back afterwards. That model assumes the ally exists in the world before the fight.

A mod whose party is data on the player cannot use it. There is no wolf to tag - there is a list of creatures the player is carrying, and they should appear in the arena because the player owns them. A FieldAllyProvider is the hook for that: Craftics asks, the addon answers with specs, and they are fielded alongside any real hub pets.

Registering a provider

CrafticsAPI.registerFieldAllyProvider("mymod:party", (world, player, freeSlots) -> {
    List<FieldAlly> out = new ArrayList<>();
    for (Creature c : MyModApi.partyOf(player)) {
        out.add(FieldAlly.builder("mymod:creature")
            .stats(AllyEntry.builder("mymod:creature")
                .hp(c.hp()).attack(c.attack()).defense(c.defense()).range(1).build())
            .aiKey("mymod:" + c.species())   // per-species AI, typing and spawn hook
            .spawnNbt(c.toNbt())             // what it IS
            .displayName(c.nickname())       // what it is called in combat
            .build());
    }
    return out;
});

The party cap is advisory

Providers receive freeSlots: how many slots remain under the player's own party cap after real hub pets are counted. It may be zero or negative.

Craftics does not truncate what you return. The cap is written for tamed wolves and scales off the player's Pet affinity; a mod with a six-creature party owns its own rules, and silently cutting that to one would look like a Craftics bug rather than a design decision. Respect freeSlots if it suits your design, ignore it if it does not.

Provider allies never touch the hub

Ordering and failure

Providers are asked after real hub pets are collected, so freeSlots reflects what the hub already took and a provider can never displace a pet the player explicitly tagged.

Every registered provider is asked and the results are concatenated, so two mods can both field allies without knowing about each other. The key exists so a provider can be replaced rather than duplicated. A provider that throws is logged and skipped - one broken addon costs its own allies, not everyone else's, and never the fight.

Reserves and switching

A party larger than the field is the point of having a party. Override reserves to send creatures into the fight on the bench - carried along, given no tile and no mob in the world, and fielded only when the player swaps one in.

CrafticsAPI.registerFieldAllyProvider("mymod:party", new FieldAllyProvider() {
    @Override
    public List<FieldAlly> provide(ServerWorld world, ServerPlayerEntity player, int freeSlots) {
        return MyModApi.partyOf(player).active().stream().map(MyMod::toFieldAlly).toList();
    }

    @Override
    public List<FieldAlly> reserves(ServerWorld world, ServerPlayerEntity player) {
        return MyModApi.partyOf(player).benched().stream().map(MyMod::toFieldAlly).toList();
    }
});

Reserves are built from the same FieldAlly as field allies and follow the same rules once they take the field - same stats, same aiKey, same spawn NBT, still temporary. reserves defaults to an empty bench, so a provider written before this existed keeps working and reads correctly: it has no reserves, rather than an unanswered question.

Asking for a switch

Craftics does not draw the menu. Read the bench, show it however you like, and ask for the swap:

for (BenchedAlly benched : CrafticsAPI.benchedAllies(player)) {
    // benched.index(), .displayName(), .hp(), .maxHp(), .aiKey()
}

CrafticsAPI.switchFieldAlly(player, outgoingAllyEntityId, benched.index());

This is the same split the combat tools use: register a tool, open your own screen from its onUse, and call back in. Craftics owns what a switch means - it costs 1 AP, it happens on your turn, the incoming creature takes the tile the outgoing one vacated - and your mod owns the screen the player picked from.

A benched ally is addressed by index, not by entity id, because it has no entity: no mob in the world, no tile on the grid, nothing to be found by. That absence is what being benched is. Indices are only valid until the next swap reorders the bench, so read it again rather than holding them.

A switch is refused - with a message to the player and no AP spent - when it is not their turn, when the ally is not theirs, when it is one of Craftics' hub pets, when someone is riding it, or when the incoming creature is too large for the tile being vacated.

The Bench, and Switching Off It

A field ally provider can declare reserves alongside the allies it fields: creatures carried into the fight with no tile and no mob in the world, fielded only when the player swaps one in.

A party larger than the field is the point of having a party. Six creatures where three fight is a different game from six all swinging at once, and choosing which three is the interesting part.

Declaring reserves

CrafticsAPI.registerFieldAllyProvider("mymod:party", new FieldAllyProvider() {
    @Override
    public List<FieldAlly> provide(ServerWorld world, ServerPlayerEntity player, int freeSlots) {
        return activeThree(player);     // what starts on the grid
    }

    @Override
    public List<FieldAlly> reserves(ServerWorld world, ServerPlayerEntity player) {
        return theRest(player);         // carried, benched, swappable
    }
});

reserves is a defaulted method returning an empty list, so a provider written before the bench existed keeps working and reads correctly: it has no reserves, not an unanswered question.

Reading the bench and switching

for (BenchedAlly b : CrafticsAPI.benchedAllies(player)) {
    // b.index(), b.entityTypeId(), b.aiKey(), b.displayName(), b.hp(), b.maxHp()
}

boolean ok = CrafticsAPI.switchFieldAlly(player, outgoingAllyEntityId, reserveIndex);

What a switch costs and when it is refused

A switch costs 1 AP and places the incoming creature on the tile the outgoing one vacated. switchFieldAlly returns false, with no AP spent, when:

• it is not the player's turn
• the outgoing ally is not theirs
• someone is riding the outgoing ally
• the incoming creature is too large for the tile being freed

A benched creature keeps everything

No menu, and only provider allies

Craftics owns what a switch means; the addon owns the screen the player picked from. Read the bench, draw it however you like, ask for the swap - the same split the combat tools use.

Craftics' own hub pets deliberately have no bench. A hub pet is a real animal that was standing in your yard and is owed back to it; one that is neither in the yard nor in the fight is an animal in no place at all. Every end-of-fight path filters on exactly the flag that excludes it, and each would have to learn about a bench before one could be safe - where a miss duplicates the animal and a false positive destroys it, since the hub copy was discarded when the party was collected.

Trainers and Enemy Benches

The mirror of the player's bench. Any enemy can carry a team of creatures it fields one at a time, withdrawing and sending out as the fight turns against it.

This is deliberately not a boss mechanic. A route trainer with three creatures is the ordinary case and a gym leader is the same thing with better ones, so the bench lives on CombatEntity rather than on anything boss-shaped.

Giving an enemy a bench

A benched creature is described by an EnemyBench rather than by a live entity, because it has no entity yet - no mob, no tile, nothing to be found by. Stats are required for the same reason: there is no world entity to derive them from.

CombatEntity leader = /* the trainer on the field */;

leader.getBench().add(
    EnemyBench.builder("cobblemon:pokemon")
        .stats(AllyEntry.builder("cobblemon:pokemon")
            .hp(120).attack(14).defense(8).range(1)
            .build())
        .aiKey("cobblemon:onix")        // AI, typing and spawn hooks key off this
        .displayName("Brock's Onix")
        .spawnNbt(onixNbt)              // merged onto the mob when it is fielded
        .build());

Switching, and sending out

Two calls, for two different situations. Reach for the wrong one and it will refuse rather than improvise.

// The leader's next creature, after the last one fainted.
if (!leader.getBench().isEmpty()) {
    CrafticsAPI.sendOutEnemy(player, leader, 0, new GridPos(4, 2));
}

// Rotating out of a bad matchup, with one still standing.
CrafticsAPI.switchEnemy(player, leader, fielded, 1);

Both field the incoming creature through the same path a level's own enemies take, so its spawn NBT, its spawn customizer, its AI key and its typing land exactly as if it had started the fight on the grid.

When they refuse

Each returns false and changes nothing - the bench included - rather than improvising a placement the player did not expect. A switch that silently repositions is worse than one that says no.

• The reserve index is out of range, or the trainer is not an enemy.
• switchEnemy: the outgoing creature is not on the field, is not an enemy, or is the trainer. A trainer cannot bench itself - it is the thing holding the bench, and removing it strands the whole team with nobody able to switch them back in.
• sendOutEnemy: the tile is out of bounds, occupied, or not standable.
• The incoming creature's footprint does not fit - for a switch, the space the outgoing one freed; for a send-out, the tile you named.

Clicking an ally

On its own Craftics does exactly one thing when a player clicks their own ally: if they are holding that ally's registered heal item, it heals. Everything else is refused with a message, and the turn is not spent.

That is far too narrow for an addon whose allies are the game. Clicking your own creature to open its moves, use an item on it, or give it an order is the most natural gesture there is, and there was no route in - grid clicks arrive on Craftics' own packet and go straight to the attack path, so no Fabric event sees them.

CrafticsAPI.registerAllyClickHandler((player, ally, held) -> {
    if (!"mymod:creature".equals(ally.getEntityTypeId())) return false;   // not ours

    if (held.isOf(MyItems.POTION)) {
        useItemOn(player, ally, held);
        return true;
    }
    openMoveMenu(player, ally);
    return true;
});

• First refusal, before the heal-item check, so an addon that owns its allies entirely owns this gesture too.
• Return false for anything you do not recognise. Handlers are asked in registration order and the first to claim wins, so one that claims every click removes healing for everyone.
• Nothing is spent for you. Craftics charges no AP for an ally click, because until now there was nothing worth charging for. If your action should cost something, spend it yourself.
• A handler that throws loses the click and is logged; the built-in behaviour runs instead. One broken addon should not cost everyone the ability to heal a pet.

Commanding an ally

The player's side of the same idea. CrafticsAPI.commandAlly(player, ally, action) leaves a standing order that overrides the ally's own judgement on its next turn, and is consumed as it is read so it is obeyed exactly once. Any EnemyAction works, custom actions included.

// The move the player picked from your own UI.
ally.setPendingAttackType("cobblemon:water");   // typing for this one move
ally.setPendingAccuracy(0.85);                  // and its accuracy

CrafticsAPI.commandAlly(player, ally, new EnemyAction.CustomAction(
    "mymod:surf", List.of(targetTile), 12, params));

Set the attack type and accuracy on the ally when you issue the order, not when it resolves. Both ride along with the order and are read on the ally's turn; the order decides what, never how it resolves, so a commanded move goes through the same damage, typing and accuracy handling an AI-chosen one does.

A blinded ally still swings wide at a commanded move: blindness scales whatever accuracy the order brought rather than replacing it, so an already-unreliable move gets worse rather than better.

Accuracy

Attacks can miss. Accuracy is a per-action multiplier living beside the attack type, on the same slot with the same lifecycle: set for the one action an AI is about to name, cleared before the next decision.

A creature whose movepool holds a wild haymaker and a reliable jab needs the haymaker to land less often, and nothing about the defender can express that.

Setting it

@Override
public EnemyAction decideAction(CombatEntity self, GridArena arena, GridPos playerPos) {
    Move move = pickMove(self);
    self.setPendingAttackType(move.typeId());   // what it is
    self.setPendingAccuracy(move.accuracy());   // how often it lands, 0.0 - 1.0
    return new EnemyAction.MoveAndAttack(path, move.power());
}

How it behaves

• Distinct from the armor-class dodge. Dodge is the defender's property and answers "did I get out of the way". Accuracy is the attack's own.
• Inert until something asks for it. Every attack defaults to always landing, and a certain hit draws no randomness at all. Had it drawn and discarded, every dodge and crit downstream would have started landing differently the day it shipped - which reads as a balance change nobody made.
• A miss skips the hit outright rather than dealing zero. Zero already means three other things, and a hit that "lands for 0" still fires every on-hit rider behind it: knockback, thorns, weapon debuffs, counters.
• onMiss fires on the combat effect handler.

Custom Actions

EnemyAction is a sealed set of about forty shapes - Move, Attack, Pounce, Teleport, Explode and so on. An AI returns one and the turn machine carries it out. Composing those shapes covers a great deal, but not an action whose resolution is genuinely new.

For that, return an EnemyAction.CustomAction and register a handler for its id. Craftics recognises that one shape and hands resolution straight back to you.

Registering a handler

CrafticsAPI.registerCustomAction("mymod:flamethrower", ctx -> {
    for (GridPos tile : ctx.tiles()) {
        CombatEntity victim = ctx.arena().getOccupant(tile);
        if (victim != null) ctx.damage(victim, ctx.damage());
    }
    ctx.message("§cThe flames wash down the lane!");
});

Returning one from an AI

@Override
public EnemyAction decideAction(CombatEntity self, GridArena arena, GridPos playerPos) {
    List<GridPos> lane = AIUtils.tilesInLine(self.getGridPos(), playerPos, 4);
    return new EnemyAction.CustomAction("mymod:flamethrower", lane, 6);
}

Getting a telegraphed wind-up for free

Wrap the custom action in a BossAbility and it inherits the entire charge-up system: the warning tiles are painted, the windup VFX plays across the player's turn - camera shake, per-tile marks, a gesture matched to the attack's shape - and the handler fires a turn later when it resolves.

return new EnemyAction.BossAbility(
    "mymod:flamethrower",                                        // names the VFX category
    new EnemyAction.CustomAction("mymod:flamethrower", lane, 6),  // what resolves next turn
    lane);                                                        // tiles to warn on

The ability name is matched against keywords to pick a windup gesture, so naming it something containing beam, line, slam, charge, summon or pull gets the matching telegraph automatically.

The Context

Handlers are handed a context rather than raw fields, and the damage and movement methods on it are not conveniences - they are the supported route.

One handler, either side

The same registered handler resolves whether an enemy or one of the player's allies performs it, so a move behaves identically in either hand. Register it once and use it for both.

ctx.damage() routes by the side ctx.self() is on. An enemy's action hits allies, and anything that is neither an ally nor the actor is taken to be the player. An ally's action hits creatures only and never falls through to the player - so a pet's own move cannot end up striking its owner. Say ctx.damagePlayer(amount) when you mean the player, from either side.

Attack-type effectiveness is applied for you on creature targets, so pass the move's base figure and let the chart do its work. It is a no-op when the actor never declared a typing.

// Works unchanged for an enemy Pokemon and for one of yours.
CrafticsAPI.registerCustomAction("mymod:earthquake", ctx -> {
    for (GridPos tile : ctx.tiles()) {
        CombatEntity victim = ctx.arena().getOccupant(tile);
        if (victim != null && victim != ctx.self()) ctx.damage(victim, 10);
    }
    // Named explicitly, so it lands whichever side threw the move.
    if (ctx.tiles().contains(ctx.playerPos())) ctx.damagePlayer(10);
    ctx.message("§6The ground shakes!");
});

What happens around the handler

The handler is the action: damage, movement, effects, particles and messages are all yours. Craftics still owns the turn rotation, death checks on anything you damaged, and the telegraph if you wrapped the action in a BossAbility.

An unregistered id costs that enemy its turn and logs once. That is deliberate - an addon can be uninstalled while a save still holds an AI naming its actions, and a missing handler should not wedge the fight waiting for something that will never resolve. A handler that throws is caught with the same outcome.

Spawn Customization

Craftics builds every combatant the same way: look the entity type up in the registry and create it bare. That is everything a zombie needs, because a zombie's entity type is its identity. It is not enough for anything whose identity lives somewhere else.

The case that forces the issue is a mod that ships one entity type for hundreds of creatures and records which creature it is in NBT or a component. Created bare, every single one spawns blank and identical. Variants, mobs that should arrive holding something, and pre-tamed allies all hit smaller versions of the same wall.

Two mechanisms solve it, and they cover different ground. Use the first where you can.

Spawn NBT (no Java required)

Any enemy or ally entry can carry NBT that is merged onto the mob the instant it spawns, before it takes its first turn. This is authorable from a datapack, so a pack with no code at all can field variant mobs.

In biome JSON, add an "nbt" field written as an SNBT string. That is the same syntax /summon takes, so it can be copied straight out of a working command:

{
  "type": "mymod:creature",
  "nbt": "{Variant:3,Tame:1b}",
  "ai": "mymod:charizard",
  "weight": 5,
  "hp": 14,
  "attack": 4
}

From Java, the same thing on an EnemyEntry or AllyEntry:

EnemyEntry.builder("mymod:charizard", "mymod:creature")
    .ai("mymod:charizard")
    .hp(14).attack(4).range(2)
    .spawnNbt(StringNbtReader.parse("{Species:\"charizard\",Level:36}"))
    .build();

A pool entry's "nbt" overrides the template's; otherwise the entry inherits it, so an enemy registered once with its tags can be dropped into any biome without restating them. A malformed SNBT string is logged and dropped rather than failing the biome, so one bad tag costs that entry its extras instead of taking the level definition down.

Spawn Customizer (code hook)

For anything NBT cannot say - typically an entity that has to be initialised through its own mod's API rather than by writing tags onto it - register a SpawnCustomizer. It runs once on the live entity, after Craftics has created, positioned and tagged it.

CrafticsAPI.registerSpawnCustomizer("mymod:charizard", (world, mob, entity) -> {
    MyModApi.setSpecies(mob, "charizard");
    MyModApi.setLevel(mob, 36);
});

Both mechanisms run when both are present, NBT first, so a customizer always sees the tagged entity and can correct or extend it rather than fight it. Both apply to enemies and to summoned allies.

A customizer that throws is caught and logged. By the time it runs the mob is already spawned and placed, so letting the exception out would abandon the rest of the arena build - one enemy missing its extras beats a half-populated fight.

Attack Types

An attack type is a trait of an attack that decides how well it lands against a defender, and nothing else. It is a third idea alongside two that already exist, and keeping them apart is the point:

They are orthogonal. A weapon can be SLASHING damage - so it scales from the player's Slashing affinity - while being typed mymod:fire, so it lands hard on a grass defender and poorly on a water one. Retyping the weapon changes nothing about what the player levels to improve it.

Registering a chart

Effectiveness is authored once per attacking type as a chart of what it is good and bad against. Only the interesting matchups are written down; anything unlisted is 1.0.

CrafticsAPI.registerAttackType(AttackTypeEntry.builder("mymod:fire")
    .displayName("Fire").colorCode("§c")
    .superEffectiveAgainst("mymod:grass", "mymod:ice", "mymod:bug")
    .notVeryEffectiveAgainst("mymod:water", "mymod:rock", "mymod:fire")
    .noEffectAgainst("mymod:stone_idol")
    .build());

Typing an attack and typing a defender

A weapon declares what it is:

WeaponEntry.builder(MyItems.FLAME_FANG)
    .damageType(DamageType.SLASHING)   // scales the Slashing affinity
    .attackType("mymod:fire")          // lands as Fire
    .attackPower(9).apCost(1).range(1)
    .build();

A defender declares what it is. The key follows the same aiKey-then-entity-type rule as spawn customizers, so a single entity type can still carry per-creature typings:

CrafticsAPI.setDefendingTypes("mymod:charizard", "mymod:fire", "mymod:flying");
CrafticsAPI.setDefendingTypes("mymod:squirtle",  "mymod:water");

A defender with more than one type multiplies its way through them, so being strong against one and weak against the other cancels to 1.0. Players see a line on the hit - "It's super effective!", "It's not very effective...", "It has no effect..." - so effectiveness is legible without a wiki.

Typing works in every direction

A weapon's attackType covers the player attacking. That is one of four directions, and a chart that only applies to one of them is half a type system - a Fire enemy would hit your Water ally at full strength, and nothing would tell the player the matchup mattered.

Typing a mob's own attacks

Set it once per creature and its melee, ranged and ability damage are all typed:

CrafticsAPI.setDefaultAttackType("mymod:charizard", "mymod:fire");

A creature with a movepool overrides it per action from inside its AI, immediately before returning the action:

@Override
public EnemyAction decideAction(CombatEntity self, GridArena arena, GridPos playerPos) {
    Move move = pickMove(self);
    self.setPendingAttackType(move.typeId());     // this action only
    return new EnemyAction.MoveAndAttack(path, move.power());
}

Typing the player as a defender

The player has no aiKey to look up, so their defending types come from a provider. A function rather than a fixed list, because a player's typing usually derives from something that changes during a run:

CrafticsAPI.setPlayerDefendingTypesProvider(player -> {
    Creature active = MyModApi.activeCreatureOf(player);
    return active == null ? List.of() : active.types();
});

It is called on every hit the player takes, so keep it cheap. Returning null or an empty list means untyped, which is the default and leaves incoming damage behaving exactly as it did before typings existed.

How the multiplier is applied

A landed hit floors at 1 in every direction, matching how mob resistances already behave, so a heavily resisted attack still chips rather than silently doing nothing. A no-effect matchup is the single case that reaches zero, and immunity is absorbing - once a defender's type list zeroes the multiplier, nothing later in the list brings it back.

Effectiveness stacks with MobResistances rather than replacing it. The two answer different questions - one is keyed on DamageType, which also decides which affinity a weapon scales from, the other purely on the matchup - so an addon can use either or both.

The whole system is inert until something opts in. An untyped weapon, an unregistered type or an untyped defender all return 1.0, which is why it can sit in the damage path unconditionally without changing any existing behaviour.