CoreLib Actions

The action stages EmakiCooking registers with CoreLib are listed below, together with each stage's parameters, failure behavior, and usage prerequisites. Prerequisite: with EmakiCooking enabled, the nutrition, threshold recheck, and recipe reward stages (a stage is one segment of an action pipeline) are already appended to the CoreLib action registry; reference them directly. They can be used by other module action lists, CoreLib pipeline templates, or pipelines triggered by third parties through the CoreLib pipeline engine

NOTE

The stages below are those registered by EmakiCooking. 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 emakicookingaddnutrition is now written cooking_add_nutrition, and the others follow the same rule

Stage IDs

All seven stages declare REQUIRED_ENTITY, and non-player targets are skipped

Stage ID	Operation	Description
cooking_add_nutrition	Add nutrition	Increases one nutrition type's current value
cooking_remove_nutrition	Remove nutrition	Decreases one nutrition type's current value
cooking_set_nutrition	Set nutrition	Sets one nutrition type's current value
cooking_clear_nutrition	Clear nutrition	Sets one type, or every type, to its own min
cooking_reset_nutrition	Reset nutrition	Sets one type, or every type, to its own default
cooking_recheck_nutrition_threshold	Recheck thresholds	Re-evaluates the target's single and combination nutrition thresholds
cooking_run_recipe_reward	Run recipe reward	Delivers one outcome branch of a loaded recipe through CookingRewardService

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

Adding, removing, and setting nutrition

cooking_add_nutrition, cooking_remove_nutrition, and cooking_set_nutrition share one parameter set

Parameter	Type	Required	Default	Description
type	STRING	Yes	—	Nutrition type ID
amount	EXPRESSION	Yes	—	Nutrition amount, may be a CoreLib expression

actions:
  - 'self | cooking_add_nutrition type=satiety amount=5'
  - 'self | cooking_remove_nutrition type=hydration amount=3'
  - 'player_by_name name=PlayerName | cooking_set_nutrition type=hydration amount=80'
  # amount as an expression
  - 'self | cooking_add_nutrition type=satiety amount=%var.base%*1.5'

On success the stage reports type, old_value, and new_value. A blank type fails at runtime with INVALID_CONFIG; when the nutrition service declines the operation, the stage fails with REJECTED and reports the reason

Clearing and resetting nutrition

cooking_clear_nutrition sets values to each type's min; cooking_reset_nutrition sets them to each type's default. The difference is semantic: one starves the player, the other returns them to a neutral state

Parameter	Type	Required	Default	Description
type	STRING	No	""	Nutrition type ID. Empty covers every registered type

actions:
  - 'self | cooking_clear_nutrition type=hydration'
  - 'player_by_name name=PlayerName | cooking_reset_nutrition'

An unregistered type fails with INVALID_CONFIG; having no registered types at all is skipped. The stage stops at the first type that fails, so it does not leave the nutrition record half-written

Threshold recheck

cooking_recheck_nutrition_threshold re-evaluates the target's nutrition thresholds. It has no parameters

actions:
  - 'self | cooking_recheck_nutrition_threshold'
  - 'player_by_name name=PlayerName | cooking_recheck_nutrition_threshold'

A disabled nutrition system or a player without a cached record is treated as skipped; neither is a fault

Recipe reward

cooking_run_recipe_reward looks up a loaded recipe and delivers its outputs and outcome actions through CookingRewardService's single exit point. It does not build a recipe on the fly; recipe must already be loaded by the matching station loader

Parameter	Type	Required	Default	Description
recipe	STRING	Yes	—	Recipe ID
station	STRING	No	""	Station folder name. Empty searches every station loader
outcome	STRING	No	success	Outcome name or path, such as success, perfect, or result.success. A value without . is expanded to result.<name>
drop_result	BOOLEAN	No	false	Drop outputs at the target instead of giving them
include_outputs	BOOLEAN	No	true	Whether to deliver the outcome branch's outputs
include_actions	BOOLEAN	No	true	Whether to execute the outcome branch's actions
phase	STRING	No	""	Phase name recorded for the nested actions. Empty generates cooking.action.recipe.<recipe id>

actions:
  - 'player_by_name name=PlayerName | cooking_run_recipe_reward recipe=apple_pie station=oven outcome=success'
  - 'self | cooking_run_recipe_reward recipe=tea outcome=result.perfect drop_result=true include_actions=false'

A blank recipe, an unknown station, or a recipe that cannot be found all fail with INVALID_CONFIG. An outcome branch with neither outputs nor actions (or with both switches turned off) is skipped. On success the stage reports recipe, station, outcome, outputs, actions, and target

The reward chain is asynchronous and fire-and-forget, so success from this stage means the delivery was submitted, not that it finished. The nested recipe actions run against a context this stage does not build, so the pipeline's declared-context checking does not extend into them

Notes

• 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
• When the nutrition service or the recipe reward service is not ready, the stage fails with MISSING_CONTEXT rather than skipping silently
• Placeholders visible to nested recipe actions include recipe_id, recipe_name, and station_type, plus the same names with a cooking_ prefix and cooking_outcome