Skip to main content
LodeEntities ships a public addon API. If you can write a Bukkit plugin, you can extend it the way addon ecosystems grow around the big plugins: register your own effect mechanics, targeters, triggers, conditions and placeholders, listen to LodeEntities events, and drive mobs, NPCs, spawners and effects from code. Java and Kotlin both work. Most examples in this section are Java.

​
Setting up an addon

1

Add the LodeEntities jar as a compile-only dependency

There is no separate API artifact yet, so you compile against the plugin jar itself.
build.gradle.kts
2

Declare the dependency in plugin.yml

This makes your plugin enable after LodeEntities.
plugin.yml
3

Register everything in onEnable

Registrations survive /le reload, so you never need to re-register.

​
The entry point

Everything is reachable from one class: org.nexomaker.api.LodeEntitiesAPI.

​
What that makes possible

The five extension points cover the whole skill language: new mechanics, targeters, triggers, conditions and placeholders. Add mobs().contribute(...) and naturalSpawns().contribute(...) on top, and an addon can ship a complete content pack (mobs, spawn rules and new vocabulary) without shipping a single YAML file. A server owner can still override any of it by declaring the same id in their own config.

Extending the effect language

Teach the effect language new words that server owners use exactly like built-ins.

Models & animation

Attach a model to any entity, play animations, restyle bones and hook per-bone hitboxes, through the engine’s API in the same jar.

​
Stability

  • Everything under org.nexomaker.api is the supported addon surface. The types it hands out (MechanicArgs, EffectContext, MobDefinition and the rest) are stable to compile against.
  • org.nexomaker.engine.api is the model engine’s own API: models, animations, bones and hitboxes. You can call it from the same jar, but it moves at the engine’s pace.
  • Anything else is internal and may change without notice.
  • Never expect a Kotlin type in a signature: the API hands out Java-friendly types (a Map rather than a Kotlin Pair), because the Kotlin runtime is relocated inside the jar.