CoreLib 动作

EmakiCooking 注册到 CoreLib 的动作段及其参数, 失败行为与使用前提如下

前置条件: EmakiCooking 启用后, 营养值, 阈值复查和配方奖励段 (段就是动作管道里的一节) 已自动追加到 CoreLib 动作注册表, 直接引用即可. 这些段可以用在其他模块的动作列表, CoreLib 管道模板, 或者第三方通过 CoreLib 管道引擎触发的管道里

NOTE

下列段由 EmakiCooking 注册; CoreLib 自带通用段见 CoreLib 动作系统. 当前段 ID 只使用下表中的规范名, 不再提供历史别名入口. 旧的 emakicookingaddnutrition 现在写作 cooking_add_nutrition, 其余同理

段 ID

七个段的目标要求都是 REQUIRED_ENTITY, 非玩家目标会跳过

段 ID	操作	说明
`cooking_add_nutrition`	增加营养值	增加指定营养类型当前值
`cooking_remove_nutrition`	扣除营养值	扣除指定营养类型当前值
`cooking_set_nutrition`	设置营养值	设置指定营养类型当前值
`cooking_clear_nutrition`	清空营养值	将指定类型或全部类型设为各自 `min`
`cooking_reset_nutrition`	重置营养值	将指定类型或全部类型设为各自 `default`
`cooking_recheck_nutrition_threshold`	复查阈值	重新评估目标玩家的单项与组合营养阈值
`cooking_run_recipe_reward`	执行配方奖励	通过 CookingRewardService 执行已加载配方的某个结果分支

"作用于谁"由 source 决定, 不再有 target 参数: 作用于执行者自己写 self, 指定玩家用 player_by_name

营养增减与设置

cooking_add_nutrition, cooking_remove_nutrition, cooking_set_nutrition 共用同一组参数

参数	类型	必填	默认值	说明
`type`	STRING	是	—	营养类型 ID
`amount`	EXPRESSION	是	—	营养数值, 可写 CoreLib 表达式

yaml

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 写成表达式
  - 'self | cooking_add_nutrition type=satiety amount=%var.base%*1.5'

成功时输出 type, old_value, new_value. type 写成空白会在运行时以 INVALID_CONFIG 失败; 营养服务拒绝这次操作时以 REJECTED 失败并带上原因

清空与重置营养

cooking_clear_nutrition 把营养值设为对应类型的 min; cooking_reset_nutrition 设为对应类型的 default. 两者的区别是: 一个把玩家饿到底, 一个把玩家还原到中性状态

参数	类型	必填	默认值	说明
`type`	STRING	否	`""`	营养类型 ID; 为空时处理全部已注册类型

yaml

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

type 指向未注册的类型时以 INVALID_CONFIG 失败; 没有任何已注册类型时跳过. 遇到第一个失败的类型就停止, 不会留下改了一半的营养记录

阈值复查

cooking_recheck_nutrition_threshold 重新评估目标玩家的营养阈值. 无参数

yaml

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

营养系统未启用或该玩家还没有缓存记录时按跳过处理, 这两种情况都不算故障

配方奖励

cooking_run_recipe_reward 会查找已加载配方, 并通过 CookingRewardService 的统一出口发放产物, 执行结果动作. 它不会临时构造新配方; recipe 必须已经由对应工位加载器加载

参数	类型	必填	默认值	说明
`recipe`	STRING	是	—	配方 ID
`station`	STRING	否	`""`	工位 (世界里用来做菜的那块方块) 的目录名; 为空时遍历所有工位加载器
`outcome`	STRING	否	`success`	结果名或路径, 如 `success`, `perfect`, `result.success`. 不含 `.` 时自动补成 `result.<名字>`
`drop_result`	BOOLEAN	否	`false`	是否把产物掉落在目标位置, 而不是进入背包
`include_outputs`	BOOLEAN	否	`true`	是否发放结果分支中的 `outputs`
`include_actions`	BOOLEAN	否	`true`	是否执行结果分支中的 `actions`
`phase`	STRING	否	`""`	记录在嵌套动作上的阶段名; 为空时自动生成为 `cooking.action.recipe.<配方 ID>`

yaml

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'

recipe 为空, station 不是已知工位, 配方查不到, 都会以 INVALID_CONFIG 失败. 结果分支既没有 outputs 也没有 actions (或两个开关都关掉) 时按跳过处理. 成功时输出 recipe, station, outcome, outputs, actions, target

奖励链是异步且不等待结果的, 所以这个段成功只代表发放已提交, 不代表已完成. 嵌套的配方动作运行在这个段没有构建的上下文里, 管道的上下文声明检查不会延伸进去

使用提示

amount 声明为 EXPRESSION, 参数文本里的占位符会先被渲染再交给表达式引擎求值, 所以 %var.*%, 模块写入的上下文占位符与 PlaceholderAPI 占位符都能直接参与运算
营养服务或配方奖励服务未就绪时, 对应段以 MISSING_CONTEXT 失败而不是不报错地跳过
嵌套配方动作可见的占位符包括 recipe_id, recipe_name, station_type, 以及带 cooking_ 前缀的同名写法和 cooking_outcome

CoreLib 动作 ​

段 ID ​

营养增减与设置 ​

清空与重置营养 ​

阈值复查 ​

配方奖励 ​

使用提示 ​

CoreLib 动作

段 ID

营养增减与设置

清空与重置营养

阈值复查

配方奖励

使用提示