Skip to main content

常见问题与排错

这篇文档对应的使用场景是：

  • 你写了脚本但没有生效
  • Tooltip 不显示
  • 某个物品的价值和你预期不一致
  • 自动配方推导没跑出来，或者跑出来的值不合理

先记住一个排错原则​

One Enough Value 的结果不是“看到哪里坏了就只查哪里”。

它是一条完整链路：

  1. KubeJS 脚本加载
  2. 服务端读取标签与配方
  3. 模组计算基础值、配方值、附加值
  4. 服务端同步给客户端
  5. 客户端 Tooltip 显示最终值

任意一环出问题，最后都会表现成“看不到值”或“值不对”。

问题一：Tooltip 没显示​

优先按下面顺序检查。

1. 是否开启了高级提示​

默认 Tooltip 只有在 F3 + H 开启后才会显示。

2. 物品最终价值是否大于 0​

源码中的显示条件是：

  • 价值必须大于 0

所以这些情况都不会显示：

  • 没有定义价值
  • 最终价值是 0
  • 最终价值是负数

3. 客户端配置是否关闭了 Tooltip​

检查 addValueTooltip 是否仍为 true。

4. 是否完成了服务端同步​

如果你刚改完脚本但没重载，客户端看到的仍可能是旧数据。

问题二：脚本改了但没效果​

1. 脚本位置错了​

One Enough Value 的主要事件是服务端事件，应写在 kubejs/server_scripts。

2. 没有执行 /reload​

修改脚本后通常需要重载，让服务端重新计算并同步价值。

3. KubeJS 脚本本身报错​

如果脚本加载失败，对应的价值注册自然不会生效。

4. 你改的是基础值，但配方结果或附加值让最终显示看起来没变​

要先区分你关注的是：

  • 基础值
  • 生成值
  • 最终值

问题三：移除了基础价值，物品还是有值​

这是最常见误判之一。

原因通常是：

  • 你移除了固定基础值
  • 但这个物品仍然存在已处理配方
  • 所以模组重新生成了配方价值

如果你的目标是让它彻底不再显示价值，更稳妥的方法是直接设置基础值为 0。

问题四：某个物品应该能自动推导，但没有值​

优先检查：

1. 上游原料有没有值​

只要上游缺一环，整条链可能都推不出来。

2. 配方类型是否已注册处理器​

默认只处理：

  • crafting
  • smelting
  • blasting
  • smoking

其它类型要你自己扩展。

3. 配方是否属于特殊输出结构​

多输出、动态输出、特殊容器输出都可能不适配默认逻辑。

4. 是否存在循环依赖或复杂图结构​

如果配方之间互相依赖，最终结果可能不会像你脑中手算得那么直接。

问题五：同一个物品的价值比预期低​

优先考虑是不是命中了“更便宜的配方路径”。

因为模组默认采用最低成本方案。

这本身不是 bug，而是设计行为。

如果你不想让某条便宜配方影响价格，有几种做法：

  • 给该物品设固定基础值
  • 单独移除或改写相关配方处理逻辑
  • 用自定义处理器覆盖默认行为

问题六：NBT 附加值结果不对​

通常从这几个方向检查：

1. 你的 NBT 条件是不是写得太宽或太窄​

太宽会误伤，太窄会匹配不到。

2. 你是否忘了附加值会叠加​

只要命中多条规则，它们会全部相加。

3. 你观察的是基础值，而不是最终值​

附加值只会体现在最终值里。

推荐排错顺序​

如果你现在碰到一个具体物品值不对，建议按这个顺序查：

  1. Tooltip 是否显示。
  2. F3 + H 是否开启。
  3. 该物品是否有固定基础值。
  4. 是否命中 NBT 附加值。
  5. 是否存在更便宜的配方路径。
  6. 该配方类型是否已处理。
  7. /reload 后是否重新同步。

实用调试技巧​

最实用的做法是写一个临时脚本，直接输出手持物品的最终值。

ItemEvents.rightClicked(event => {
    event.player.tell(`当前物品价值: ${OEV$ItemValueManager.getValue(event.item)}`)
})

这样你可以把“Tooltip 有没有显示”和“服务端实际算出来多少”这两件事分开看。

最后判断标准​

如果你已经确认：

  • 脚本加载正常
  • /reload 正常执行
  • 原料有值
  • 配方类型已处理
  • NBT 条件没写错

但结果仍然不符合设计预期，那么问题往往不在“有没有算”，而在“默认规则不适合你的场景”。

这时应该回到 自定义配方处理逻辑，把规则显式写出来，而不是继续和默认推导硬碰硬。