/nme effect start. Server owners write them in YAML without knowing or caring that an addon provides them.
The five extension points
Together they make full-stack extensions possible. An RPG addon can fire its own
~onCast trigger, gate a branch on holding[SWORD], pick victims with @lowestHealth[16], hit them with its shout mechanic and print <rpg.tier> in the message, all in a server owner’s ordinary YAML.
Registration rules
- Built-in names always win. If an addon registers a word with the same name as a built-in, the built-in is used. Pick distinct names.
- Registrations survive
/nme reload. Register once at plugin enable; no re-registration hooks needed. - Load order never matters. Configs referencing addon-provided words are re-parsed automatically after the addon registers them. If NMEntities boots before your addon enables, you’ll see one parse warning for the unknown word at boot, and it self-heals the moment the addon registers. That warning is normal, not a bug to chase.
For server owners
If you’re not writing an addon yourself, the takeaway is simply: installing an addon can give your effect configs new words. The addon’s own docs tell you which. A boot-time warning about an unknown mechanic that disappears once all plugins are enabled is the load-order behavior described above, safe to ignore.For developers
Registration goes throughorg.nexomaker.api.NMEntitiesAPI. The developer guide (API.md, shipped with the plugin) has complete, compilable examples for each of the five extension points, including attribute parsing so your mechanic can take {key=value} blocks like the built-ins.
