CoreLib Actions

EmakiLevel registers 8 stages in the CoreLib action system: what each stage does, which parameters it accepts, and how to write it into an action pipeline. Confirm the stage ID in the table below, then copy a parameterized example directly

Prerequisite: EmakiLevel must be enabled for the stages to register in the CoreLib action registry. Once registered, they can be used by other module action lists, such as cooking completion, forge results, strengthen stages, skill rewards, or CoreLib pipeline templates

NOTE

The stages below are those registered by EmakiLevel. CoreLib built-in stages are documented in CoreLib Actions. Current stage IDs use only the canonical names below; historical aliases are no longer registered. The old emakileveladdexp is now written level_add_exp, the others follow the same rule, and the old emakilevellevelup is now level_up

Stage IDs

Shared constraint: all eight stages declare REQUIRED_ENTITY, and non-player targets are skipped

Stage ID	Operation	Uses amount
level_add_exp	Add exp	Yes
level_set_exp	Set exp	Yes
level_remove_exp	Remove exp	Yes
level_add_level	Add levels	Yes
level_set_level	Set levels	Yes
level_remove_level	Remove levels	Yes
level_reset	Reset one level type	No
level_up	Manually level up one type	No

Parameters

All eight stages accept these parameters:

Parameter	Type	Required	Default	Description
type	STRING	Yes	—	Level type ID, such as main, combat, or mining
amount	EXPRESSION	No	0	Experience or level amount. Plain numbers and CoreLib expressions are accepted. Level operations round this value to an integer
reason	STRING	No	action	Audit reason passed to the level service

level_add_exp accepts two more:

Parameter	Type	Required	Default	Description
auto_upgrade	BOOLEAN	No	true	Whether to level up automatically when the threshold is crossed
silent	BOOLEAN	No	false	Whether to suppress the level-up feedback

Parameter constraints: level_reset and level_up ignore the value of amount, but still declare the parameter, so passing it is not reported as an unknown argument. auto_upgrade and silent are declared only on level_add_exp; writing them on another stage is an unknown-argument error at load time

Target selection: which player is affected comes from the source, so there is no target parameter any more: use self for the caster, or player_by_name for a named player

Examples

actions:
  # Add 50 main exp to yourself
  - 'self | level_add_exp type=main amount=50 reason=forge_reward'

  # Add 1 combat level to yourself
  - 'self | level_add_level type=combat amount=1 reason=boss_reward'

  # Add exp without auto level-up and without feedback
  - 'self | level_add_exp type=main amount=10 auto_upgrade=false silent=true'

  # Set mining exp for a named player
  - 'player_by_name name=PlayerName | level_set_exp type=mining amount=200 reason=admin_adjust'

  # Reset the main level type
  - 'player_by_name name=PlayerName | level_reset type=main reason=admin_reset'

  # Run one manual level-up through the level system
  - 'player_by_name name=PlayerName | level_up type=main'

  # amount as an expression
  - 'self | level_add_exp type=main amount=%var.base%*2+10'

Notes

Troubleshooting and verification:

• amount is declared as EXPRESSION. Placeholders in the argument text are rendered before the expression is evaluated, so %var.*%, context placeholders written by the calling module, and PlaceholderAPI placeholders can all take part in the arithmetic
• Level operations (level_add_level, level_set_level, level_remove_level) round amount to an integer
• Failure handling: when the level service declines the operation, the stage fails with REJECTED and reports the service's reason
• Verification: on success the stage reports type, old_level, new_level, old_exp, new_exp, and amount, so the debug output shows the state before and after