EmakiMobs

EmakiMobs turns a mob roster into configuration: define an id, a vanilla entity type and the components, Emaki attributes, action pipelines, loot and spawn rules that should accompany it. The same definitions can power hand-spawned tests, natural replacements, autonomous schedules, threat tables and boss bars — from a common mob to a multi-phase boss, without writing a Java class. The first start releases five example mob definitions, four loot tables and two spawn rules, and /emakimobs reload applies your edits immediately.

01 Core Features

Each YAML file defines a stable mob id, a vanilla entity type, display data, components and experience reward.

• Vanilla component mapping: Configure health, movement, attack, equipment, names, persistence, visibility, variants and other supported entity fields without writing a new mob class.
• EmakiAttribute contributions: The ea_attributes section can provide EmakiAttribute values to a managed mob when the optional integration is installed.
• Action-driven mob behaviour: The actions section connects spawn, damage, target, kill, death, transform, teleport, explode, shoot and fixed health-threshold triggers to the CoreLib action pipeline.
• Target selection and locking: Optional target_selector definitions score nearby players from equipment, attributes, expressions or threat data; lock_target can keep a selected target for a configured interval.
• Natural and autonomous spawning: Use natural rules for controlled replacement of vanilla spawn events or autonomous rules for interval, player-follow, in-game-day and cron schedules.
• Configurable loot tables: A loot_tables/<mob_id>.yml file alone enables drops for that mob — its mob_id does the linking, so no loot key exists in the mob definition — with weighted pools carrying entry conditions, counts, looting adjustments and vanilla, item or EmakiItem drops.
• Dual-backend model rendering and animation: model.api in config.yml switches between ModelEngine and BetterModel with auto detection, a per-mob model: node names the blueprint with optional api, scale, animations, keyframes and lod overrides, level-of-detail tiers are chosen by distance to the nearest player, and the mob_play_animation, mob_stop_animation and mob_set_model action stages drive model animations from mob actions; without either backend installed the mobs simply run without models.
• Threat tables and boss bars: Track damage and healing threat with range and decay settings, and show a configurable Paper boss bar to nearby players.
• In-game definition editor: /emakimobs edit opens a graphical editor: with no id it opens the definition browser, with an id it opens that definition's paged editor — components, action triggers, threat, boss bar, model and target-lock settings, plus loot tables, spawn rules and target selectors — and saving writes the YAML straight back to disk.
• Reload runs the pre-check first: /emakimobs reload runs the configuration pre-check before committing a new snapshot and reports issues by severity; a rejected candidate keeps the running snapshot, so a bad file never takes effect

02 Feature Overview

Mob definitions and components

• Put one definition in mobs/*.yml with id, type, components and optional ea_attributes, actions, threat, boss_bar, target_selector and model settings.
• components maps supported vanilla entity properties and equipment; unsupported component keys are ignored, so spelling should be checked against the component reference.
• An id matching a vanilla EntityType enables type override for naturally spawned entities of that type; use a distinct id when the effect should be limited to dedicated spawn rules.
• The per-mob model: node requires a blueprint and can set api, scale, animations, keyframes and per-mob lod; the model: block in config.yml selects the backend through api (auto prefers ModelEngine then BetterModel), sets view_distance, the lod.near/mid/far distance tiers and the transition blend lengths.
• target_selectors.yml ships named selectors such as nearest and gear_hunter, scheduled by snapshot_interval_ticks and snapshot_players_per_tick, and selectors can carry inline filter predicates; a mob's target_selector references one by name.
• Use /emakimobs spawn <mob_id>, /emakimobs info <mob_id> and /emakimobs list while developing definitions, and the admin-gated /emakimobs kill <mob_id> [radius] removes managed mobs.

Spawning and drops

• spawn_rules/*.yml accepts type: natural and type: autonomous; autonomous rules support interval, player_follow, day_interval and cron triggers.
• Filter by world, biome, structure, Y range, light, time of day, distance, nearby/global caps and count ranges.
• loot_tables/<mob_id>.yml alone enables drops for that mob: combine weighted entries, chance and condition gates, count functions, vanilla materials, configured item ids and EmakiItem drops, with no key needed in the mob definition.
• Run /emakimobs reload after editing definitions, loot tables or spawn rules; the precheck reports blocking configuration problems before the new snapshot is committed.

Combat and integration

• actions can target self, target, killer, victim and attacker, enabling messages, particles, effects, damage, sounds and summon_mob sequences.
• Fixed threshold triggers (90, 75, 50, 25, 10) fire once per managed entity and can drive multi-phase boss behaviour.
• Install EmakiAttribute for ea_attributes, EmakiSkills for action-pipeline integrations exposed by Skills, and EmakiItem for custom-item loot entries.
• Threat and boss-bar state is cleaned with the managed entity lifecycle; reload keeps the current runtime snapshot when a candidate configuration is rejected

03 In-Game Views

04 Command Output

Listing every mob definition with the vanilla entity type behind it:

> emakimobs list
[ EmakiMobs ] Mob definitions page 1/1, 5 total:
[ EmakiMobs ] - bone_lord  (minecraft:skeleton)
[ EmakiMobs ] - elite_zombie  (minecraft:zombie)
[ EmakiMobs ] - example_zombie  (minecraft:zombie)
[ EmakiMobs ] - jungle_stalker  (minecraft:creeper)
[ EmakiMobs ] - zombie  (minecraft:zombie)

05 Quick Start

1. Place EmakiCoreLib and EmakiMobs in plugins/; add EmakiAttribute, EmakiSkills or EmakiItem only for the integrations you use. The first start also releases example data — five mob definitions, four loot tables and two spawn rules — to copy from.
2. Create a definition under mobs/, starting with id, type and components; use ea_attributes and actions for current integration keys.
3. Add a loot_tables/<mob_id>.yml file and, if the mob should spawn automatically, a spawn_rules/*.yml rule using natural or autonomous.
4. Run /emakimobs reload, read the precheck output, then test with /emakimobs spawn <mob_id> and /emakimobs info <mob_id>.
5. Add optional target selection, threat or boss-bar settings only after the base definition and drops behave as expected

06 Compatibility and Dependencies

Item	Details
Runtime baseline	Java 25, Paper 1.21.8 or newer
Required dependency	EmakiCoreLib
Main command and aliases	/emakimobs, /emobs
Key permissions	emakimobs.use, emakimobs.spawn, emakimobs.reload, emakimobs.list, emakimobs.info, emakimobs.count, emakimobs.debug, emakimobs.admin
Main configuration entries	config.yml (with its model: block), mobs/ (per-mob model:), loot_tables/, spawn_rules/, target_selectors.yml, lang/

Optional integrations, each used only when installed:

• EmakiAttribute: reads ea_attributes
• EmakiSkills: enables the related action-pipeline integration
• EmakiItem: provides configured-item drops
• PlaceholderAPI: available for configured condition/context integrations
• ModelEngine or BetterModel: renders models — model.api picks one with auto detection, and without either the mobs run with no model