For the complete documentation index, see llms.txt. This page is also available as Markdown.

πŸ’»Developer API

EnchantmentReform exposes registries for custom abilities, Power Conditions, Power Modifiers, MatchItem/MatchEntity rules, and triggers.

Register extensions after EnchantmentReform has enabled. Add a hard dependency when your plugin cannot function without the API:

depend:
  - EnchantmentReform

Dependency coordinates

The source modules use:

<dependency>
    <groupId>cn.superiormc.enchantmentreform</groupId>
    <artifactId>core</artifactId>
    <version>${enchantmentreform.version}</version>
    <scope>provided</scope>
</dependency>

Use the matching release artifact or install the matching source version into your development repository. Do not compile against a different EnchantmentReform/server generation than production.

Registry key normalization

Ability, condition, and modifier string registries convert keys to lowercase and replace - with _. my-ability and my_ability therefore resolve to the same key. Duplicate normalized keys are rejected.

Accessing the plugin

The static instance is assigned during onEnable; never access it before EnchantmentReform has enabled.

Custom ability

Returning true requests cancellation of the current cancellable trigger. The base class handles common conditions, chance, cooldown, usage count, dynamic values, selectors, and location helpers.

Custom Power Condition

The base condition applies common inversion such as not: true after onMatch returns.

Custom Power Modifier

The modifier base evaluates common conditions, random chance, and cooldown before onApply.

Custom match rules

  • Extend AbstractMatchItemRule and implement matching against ObjectSingleMatchItem.

  • Extend AbstractMatchEntityRule and implement matching against ObjectSingleMatchEntity.

  • configNotContains must return true when the rule's configuration key is absent.

  • MatchEntityFormat receives a LivingEntity, optional player, and optional PowerContext.

Manual trigger

A manual trigger exposes a namespaced power section without adapting a Bukkit event.

For a plugin named MyPlugin, use the trigger's namespaced key:

TriggerData.builder(owner) requires an owner. Source, skill, target, block, location, movement locations, Bukkit event, item/slot, tick, and typed extras are optional.

Event-backed trigger

Advanced integrations may extend AbstractTrigger<E>, provide a unique key/configuration key, declare supported TriggerEventType values, and register it:

Always call unregisterAll(plugin) during disable.

Lifecycle cleanup

Custom implementations may override cleanup hooks such as:

Store UUIDs instead of retaining unloaded Bukkit entities. Cleanup is type-wide and should not depend on one temporary YAML section instance.

Compatibility guidance

  • Use scheduler-safe entity/block operations for Folia.

  • Validate required context entities, events, items, blocks, and results before mutation.

  • Do not assume Paper-only events exist on Spigot.

  • Keep published type IDs stable because administrator YAML depends on them.

  • Avoid replacing built-in keys.

  • Recompile and retest against every supported EnchantmentReform/server generation.

Last updated