Skip to main content
NMEntitiesAPI.mobs() is the registry of every mob NMEntities knows about, plus the operations that act on live ones.

​
Lookup and spawning

spawn runs the same pipeline as /nme spawn: model, stats and +onSpawn effects. fireTrigger accepts built-in trigger names and any trigger your addon registered.

​
Finding a mob that vanished

disabled() returns the mobs that are configured but not registered, usually because their model was deleted or renamed. They are deliberately absent from ids(), all() and get() so a broken mob never reaches a menu or a spawn. This is how you find out why one disappeared.

​
Factions and threat

Every mob may belong to a faction. Relations live in factions.yml, and allies never target each other or generate threat. Threat tables are per-mob, fed by damage, and decide retargeting. See Factions & Threat for the config side.
Relations are one-way. relationBetween(a, b) need not equal relationBetween(b, a).
threatTable returns a Map rather than a list of pairs on purpose: Kotlin’s Pair is relocated inside the shaded jar, so an addon could not name the type.

​
Shipping bundled mobs

An addon can ship mob definitions from code. They merge into the registry and are not wiped when configs reload.
MobDefinition fields, in order: id, model, base, display, health, damage, armor, speed, scale, glowing, gravity, invulnerable, persistent, nameVisible, ai, silent, collidable, invisible, child, canPickUpItems, knockbackResistance, followRange, attackKnockback, faction, equipment, aging, effects. Everything after base is optional, and model may be null too — a mob with no model is the plain base entity with your stats and effects on it. Mob Fields documents what each one means and the range it accepts.
Unlike SpawnRule, MobDefinition is not @JvmOverloads. From Java you must pass every argument, null for the ones you don’t want — and the list grows as fields are added, so a Java addon has to be recompiled against each version. From Kotlin, named arguments and defaults work as usual, which is what you want here.
equipment is a MobEquipment(Map<EquipmentSlot, ItemStack> pieces, Map<EquipmentSlot, Float> dropChances) — drop chance defaults to 0, not vanilla’s ~8.5%, so a contributed boss doesn’t seed the floor with free gear. aging is a MobAging(String growsInto, long after): the id of the next stage and how many ticks alive before it grows. A server owner can still override any contributed mob by defining the same id in a Mobs/ file — your addon supplies sensible defaults, the owner has the last word.