食欲：营养

食欲

Minecraft 让你可以靠一组牛排永远活下去。《食欲》这个模组注意到了这一点。

你吃的每一顿饭都会被归类到食物组中，每个食物组会随着你的游玩而消耗，忽视某一组会开始让你付出代价。这里没有繁琐的任务条：一个饮食正常、多样化的玩家几乎不会注意到这个模组的存在。只有那些一周只吃一种作物的玩家才会发现其影响。

它的功能

• 食物组。 默认有五个——水果、蔬菜、谷物、蛋白质和糖类。每个组的满值都以其自身的标准为参照，因此整合包可以决定蛋白质的“满”值与谷物的“满”值不同，而玩家无需知道这一点。
• 餐食会填充它们所属的食物组， 并根据食物的营养价值加权。允许某一组超过其标准值，最高可达到可配置的上限，并可选递减收益。
• 食物组会消耗，可通过活动、时间或两者共同消耗。两个调节旋钮即可涵盖战斗整合包和几乎不移动的空岛整合包。
• 短缺会带来代价。 随着食物组见底，属性惩罚会逐渐显现；当它几乎耗尽时，一个状态效果会被激活。仅限惩罚——完美的饮食不会提供奖励，因为奖励会将正常状态重新定义为缺陷，并把模组变成对某项属性的无谓刷取。
• HUD 上的饮食玫瑰图 可同时显示均衡度和营养度，看起来像是游戏的一部分，而不是贴在游戏上的图表。
• 饥饿感本身可调整—— 包括疲劳速率、被动消耗、饱和度上限——并且可以在完全关闭饮食系统的情况下工作，如果你只是为了调整饥饿感而来。

模组食物已为你分类

这是最需要花时间做好的部分，也是《食欲》区别于手工维护的逐模组配置列表的地方。

一个物品会通过一个从确定到推测的链条来解析。第一个给出答案的层级将完全胜出；层级之间绝不混合，因为一个费心对某物进行分类的整合包，其意图是明确的。

1. 整合包通过《食欲》的数据映射表明确指定的内容。 覆盖以下所有规则。
2. 物品标签。 常见的 c:foods/* 标签可以在无需编写任何内容的情况下对大多数原材料进行分类。标为腐烂或有毒的食物可以填饱玩家，但无法提供营养。
3. 配方。 没有标签的食物可以通过追溯其配方到已分类的原料来解析——这就是汉堡包、一盘饺子或一碗炒饭如何被分类的，这些食物没有任何模组为其打标签，因为没有单一标签能准确描述它们。
4. 一个可配置的回退方案 用于处理剩余物品：要么平均分配，要么不给予任何营养。

在一个围绕十一个食物模组（农夫乐事及其附属、作物田园、水产养殖、煲汤锅）构建的整合包中，765 种食物中有 664 种无需任何配置即可分类，其中大部分由配方完成：461 种来自配方，199 种来自标签。在一个包含 306 个模组的厨房水槽式整合包中，这个数字是 290 种中的 199 种。限制其数字的并非解析过程，而是那些既不给食物打标签、也不为其提供配方的模组，任何推理都无法解读在代码中组装的菜肴。

分类器所做的每个判断都是可检视的。/appetite why—— 对每个玩家开放，不仅仅是管理员——会报告是哪个层级认领了该物品以及它匹配到了什么，因为一个无法被检视的猜测与一个错误是无法区分的。

短缺带来的代价

默认值刻意设置得较为温和，并且每一项都由数据包定义，而非硬编码：

食物组	当它偏低时	当它几乎耗尽时
水果	移动速度 −15%	—
蔬菜	最大生命值 −20%	—
谷物	方块破坏速度 −25%	挖掘疲劳
蛋白质	攻击伤害 −25%	虚弱
糖类	—	—

糖类故意不设惩罚：没有人需要糖果来保持健康，并且一个没有惩罚的组可以告诉整合包作者，惩罚是按组设定的，而非强制性的。

属性惩罚是渐变的—— 它们从阈值处的零开始逐渐显现，到组完全耗尽时达到最大值——所以不会有突然的跌落悬崖，并且一旦饮食恢复，它们会立即消失。效果应用时没有粒子效果，只保留图标：一个持续存在且不断喷洒粒子的状态效果，玩起来是无法忍受的。

给整合包作者

一切都是数据。食物组、什么算作什么食物，以及短缺会造成什么影响，都是数据包文件，而非代码。

• 自带你自己的食物组。 可以是三个或八个，而不是默认的五个——包括颜色、图标、标准值、消耗速率和惩罚。
• 纠正任何分类，可以使用以物品 ID 或标签为键的数据映射条目。一个留空的条目意味着“可食用，但不是食物”，这就是如何将一个装饰性饮品完全排除的方式。
• 一次分类整个整合包。 /appetite export unmatched 会遍历所有注册的食物物品，并将那些链条不得不猜测的物品写入一个文件，该文件已采用你需要纠正的格式。修正权重，将其放入你的整合包，完成。/appetite export 会写出所有物品，包括猜测结果。

存储库中有一份面向整合包和模组作者的完整参考资料，涵盖了所有字段、双方的每个配置选项，以及附加组件可以基于其构建的 Java API。

命令

命令	使用者	功能
/appetite get	任何人，用于自身	显示玩家的饮食情况
/appetite why	任何人	解释一个物品是如何被分类的
/appetite set、add、reset	管理员	调整玩家的饮食
/appetite export [unmatched]	管理员	将组成情况写为数据映射
/appetite hunger、exhaustion	管理员	设置原版饥饿值，用于测试

坦诚的局限性

• 输出为列表而非单一物品堆叠的配方无法被读取——游戏只暴露一个结果，这类配方的结果留空。切菜板式配方就是这种方式工作的。
• 从放置的方块中提供的食物，如果其可食用物品没有自己的配方，则同样无法处理。
• 一个在代码中组装其菜肴、既没有标签也没有配方可读的模组，完全无法被推断。

这三种情况都会落入配置的回退方案，而它们也正是导出功能存在的意义。

兼容性与许可证

客户端和服务器端都需要安装：服务器端掌握饮食数据，客户端仅负责绘制。可以安全地添加到现有世界。

《食欲》是对食物组概念的独立、洁净室实现。它不与其他任何饮食模组共享代码、资源或配置，并在 Mozilla Public License 2.0 下发布——任何人都可以使用、分叉、再分发和捆绑它，包括用于商业整合包，同时对《食欲》自身文件的修改保持开源。仅依赖其 API 的代码不受影响，可以使用任何许可证。

欢迎在 GitHub 上提交错误报告和拉取请求。