CoreLib Actions

Prerequisite: EmakiAttribute is enabled; its startup registers attribute, resource, tag, and sync stages with the CoreLib action registry. Each stage's ID, parameters, and usage examples are listed below. Pick a stage from the table below, copy an example into any config node that accepts a CoreLib pipeline (Forge/Strengthen/Cooking/Skills/Item action lists, CoreLib pipeline templates, or pipelines triggered by other plugins through the CoreLib pipeline engine), then verify with the outputs reported on success

NOTE

Only the stages registered by EmakiAttribute are listed here; CoreLib's own message, command, economy, and item stages are documented in CoreLib Actions. Current stage IDs use only the canonical names below; historical aliases are no longer registered. The old attributedamage is now written attribute_damage; the other stage IDs are unchanged

Which entity is affected comes from the source: use self for the caster, or player_by_name for a named player

Stage ID reference

Stage ID	Purpose	Target requirement
attribute_damage	Applies attribute-typed custom damage to the target	REQUIRED_ENTITY
attribute_add	Adds a timed attribute modifier to the target	REQUIRED_ENTITY
attribute_set	Sets a timed attribute modifier on the target	REQUIRED_ENTITY
attribute_remove	Clears every timed modifier inside the target's effect_id group	REQUIRED_ENTITY
attribute_resource_add	Adds to one of the target's resources	REQUIRED_ENTITY
attribute_resource_set	Sets one of the target's resources	REQUIRED_ENTITY
attribute_resource_remove	Removes from one of the target's resources	REQUIRED_ENTITY
attribute_resource_consume	Consumes one of the target's resources	REQUIRED_ENTITY
attribute_tag_add	Adds timed attribute modifiers in bulk by tag	REQUIRED_ENTITY
attribute_tag_remove	Removes timed attribute modifiers by tag	REQUIRED_ENTITY
attribute_tag_clear	Clears timed attribute modifiers by tag	REQUIRED_ENTITY
attribute_sync	Recomputes attribute and resource state for the target or everyone online	OPTIONAL
attribute_refresh	Drops attribute caches, then recomputes for the target or everyone online	OPTIONAL

Apart from the two sync stages, attribute_damage and the resource stages accept only player targets; the timed-attribute and tag stages accept any living entity (including non-player mobs) and skip non-living targets. attribute_damage declares REQUIRED_ENTITY, but the implementation only handles Player: a non-player living target is skipped with not_player and takes no damage

Upgrade notes: timed attribute behaviour changes

Two changes are visible to existing configuration:

1. The tag entry point no longer produces composite effect IDs. attribute_tag_add effect_prefix=poison used to write separate unrelated top-level records such as poison:physical_attack and poison:movement_speed; they now all join a single poison effect group. Configuration that deleted one composite ID such as poison:physical_attack no longer matches and must use attribute_remove effect_id=poison instead. Conversely, attribute_remove effect_id=poison — which previously removed nothing — now works
2. Multi-group SET on the same attribute now has a defined winner. It used to depend on internal hash-map iteration order, so the same configuration could produce different results and could change as the map grew. The last write now wins (highest internal monotonic revision), and repeated runs are stable. /ea trace marks the losing entry as overridden by a higher revision

Single-attribute configuration is unaffected and behaves exactly as before

attribute_damage

Applies one Attribute damage instance to the target. Unlike CoreLib's built-in damage, this stage routes through EmakiAttribute, so the module's damage types, resistances, and combat snapshot all apply

Parameter	Type	Required	Default	Description
amount	DOUBLE	Yes	—	Base damage
type	STRING	No	""	Damage type ID. Empty uses EmakiAttribute's default damage type
cause	STRING	No	CUSTOM	Bukkit EntityDamageEvent.DamageCause, such as CUSTOM, MAGIC, or ENTITY_ATTACK

actions:
  - 'self | attribute_damage amount=25 type=physical cause=CUSTOM'
  - 'looking_at range=15 | attribute_damage amount=40 type=spell cause=MAGIC'

An unrecognised cause fails with INVALID_CONFIG rather than silently damaging with the wrong cause; a blank value means CUSTOM. Damage refused by the module's rules fails with REJECTED. On success the stage reports damage_type

Timed attribute modifiers

effect_id identifies an effect group, not a single effect. Several attributes can share one effect_id: they coexist instead of overwriting each other, and attribute_remove clears the whole group at once. attribute_add and attribute_set decide whether that attribute's entry inside the group adds or overwrites, which is why they are separate stages rather than one stage with a mode argument

actions:
  - 'self | attribute_add effect_id=buff_strength attribute=physical_attack value=10 duration_ticks=200t'
  - 'self | attribute_add effect_id=buff_strength attribute=physical_crit_rate value=5 duration_ticks=200t'
  - 'self | attribute_remove effect_id=buff_strength'

Both attribute_add calls above land in one group, and attribute_remove clears both attributes

attribute_add / attribute_set

Both stages take the same arguments

Argument	Type	Required	Default	Description
effect_id	STRING	Yes	—	Effect group id; reusing one id groups several attributes together
attribute	STRING	Yes	—	Attribute ID; an unregistered id fails with INVALID_CONFIG
value	DOUBLE	Yes	—	Modifier value; NaN and ±Inf fail with INVALID_CONFIG
duration_ticks	DURATION	Yes	—	Duration; accepts 20t, 1s, 1000ms; a bare number is ticks
stack_mode	STRING	No	the attribute's temporary_stack_mode	How to combine with an existing entry for the same attribute in that group: REPLACE overwrites, STACK adds value and remaining duration. An undeclared value fails with INVALID_CONFIG

actions:
  - 'self | attribute_add effect_id=forge_bonus attribute=physical_attack value=12 duration_ticks=10s'
  - 'self | attribute_set effect_id=arena_buff attribute=physical_attack value=30 duration_ticks=200t'
  - 'self | attribute_add effect_id=forge_bonus attribute=physical_attack value=3 duration_ticks=10s stack_mode=STACK'

attribute_remove

Argument	Type	Required	Default	Description
effect_id	STRING	Yes	—	Effect group id to clear; every attribute in that group is removed

actions:
  - 'self | attribute_remove effect_id=arena_buff'

All three stages normalise effect_id and attribute as IDs. A blank effect_id fails with INVALID_CONFIG; a non-living target is skipped with not_living_entity (non-player mobs are supported). When the target carries no such group the stage is skipped rather than successful. On success they report effect_id, attribute, value, duration_ticks, status, affected_count, existed, and remaining_ticks, where status is one of APPLIED / REPLACED / STACKED / REMOVED

Resources

The four resource stages modify a player's current resource value through EmakiAttribute's resource sync boundary. They share one parameter set

Parameter	Type	Required	Default	Description
resource	STRING	Yes	—	Resource ID, such as health or mana
amount	DOUBLE	Yes	—	Operation amount

Stage ID	Arithmetic
attribute_resource_add	current + amount
attribute_resource_set	set to amount
attribute_resource_remove	current - amount, floored at 0
attribute_resource_consume	identical to attribute_resource_remove

attribute_resource_consume and attribute_resource_remove compute the same value. Both IDs are kept because existing configuration refers to them by name; they share one implementation

The final value is still clamped by the resource definition's sync rules, so add cannot exceed the maximum

actions:
  - 'self | attribute_resource_add resource=mana amount=10'
  - 'self | attribute_resource_set resource=health amount=20'
  - 'self | attribute_resource_remove resource=health amount=5'
  - 'self | attribute_resource_consume resource=mana amount=20'

resource is normalised as an ID; an unloaded resource fails with INVALID_CONFIG. On success the stage reports resource, operation, amount, old_value, new_value, and current_max

Tag-addressed timed modifiers

A tag names a group of attributes configured together, so one call can apply a whole buff without listing its parts

attribute_tag_add

Parameter	Type	Required	Default	Description
tag	STRING	Yes	—	Attribute tag, case-insensitive
value	DOUBLE	Yes	—	Modifier value applied to every matching attribute
duration_ticks	DURATION	Yes	—	How long the modifiers last
effect_prefix	STRING	No	tag:<tag>	Effect group id that every matched attribute joins. Empty uses tag:<tag>
stack_mode	STRING	No	""	Stack mode: REPLACE or STACK. Blank uses each attribute's own temporary_stack_mode; an unrecognised value fails with INVALID_CONFIG

actions:
  - 'self | attribute_tag_add tag=DEBUFF value=-5 duration_ticks=5s effect_prefix=poison stack_mode=REPLACE'

Every attribute matched above lands in the single poison group, so attribute_remove effect_id=poison clears the whole set

attribute_tag_remove / attribute_tag_clear

Parameter	Type	Required	Default	Description
tag	STRING	Yes	—	Attribute tag whose timed modifiers should be removed

actions:
  - 'self | attribute_tag_remove tag=DEBUFF'
  - 'self | attribute_tag_clear tag=BUFF'

These two behave identically: both remove by tag. The duplication is carried over from the previous implementation. Deciding what clear was meant to do (drop every tag, presumably) would change behaviour that existing configuration may depend on, so it was left alone

A blank tag fails with INVALID_CONFIG; when no attribute carries the tag, or the target has no matching effect, the stage is skipped rather than reported successful. All three stages report tag, effect_id, status, and count (how many attributes were matched and processed) on success

Sync

Both stages take a single parameter; they differ in its default and in whether caches are dropped

Stage ID	Parameter	Type	Default	Description
attribute_sync	all	BOOLEAN	false	Recomputes values without dropping caches. Defaults to the target only
attribute_refresh	all	BOOLEAN	true	Drops the module's caches, then recomputes. This is the stage to run after editing attribute configuration. Defaults to every online player

actions:
  # Sync yourself only
  - 'self | attribute_sync'
  # Sync every online player; no target needed, so the source can be omitted
  - 'attribute_sync all=true'
  # After a config change: drop caches and recompute server-wide
  - 'attribute_refresh'
  # Drop caches and recompute for yourself only
  - 'self | attribute_refresh all=false'

Both declare OPTIONAL rather than REQUIRED_ENTITY, because all=true needs no target at all; the per-target path checks for a player itself and skips when there is none

These are also the only stages in this module whose thread domain depends on their arguments: all=true walks the online-player list and runs on the server-global domain, while all=false touches a single entity. When all is written as a placeholder it cannot be read during planning, so the stage's own default decides the domain, which means attribute_refresh is planned as global

On success the stage reports all, plus player when all=false

Notes

• Apart from attribute_sync all=true and attribute_refresh all=true, every stage listed here needs a player target
• To add or clear timed modifiers on a mob directly from a MythicMobs skill, use emaki_attribute_add, emaki_attribute_remove, emaki_attribute_add_tag, and emaki_attribute_clear_tag from MythicMobs Integration. Those are MythicMobs mechanics, not the CoreLib stages listed here
• duration_ticks is parsed as CoreLib DURATION: 20t, 1s, and 1000ms all work, and a plain number is ticks
• When the relevant service is not ready, the stage fails with MISSING_CONTEXT rather than skipping silently