Skip to main content

在脚本和联动中读取价值

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

  • 你已经有一套价值表，接下来想把它用在别的系统里
  • 你在写 KubeJS 商店、回收、任务、掉落、奖励或机器脚本
  • 你想把 One Enough Value 当成整个整合包的统一价格底层

可用入口​

模组在 KubeJS 里暴露了一个全局绑定：

OEV$ItemValueManager

这是最直接的读取入口。

最常用的方法​

读取最终价值​

let value = OEV$ItemValueManager.getValue(itemStack)

这是最常用的方法，因为它拿到的是最终结果。

也就是：

  • 固定基础值
  • 或配方生成值
  • 再加上命中的全部 NBT 附加值

读取基础价值​

let base = OEV$ItemValueManager.getBaseValue(itemStack)

这个方法更适合调试或做高级逻辑区分。

要注意的是：

  • 如果没有基础值，它返回的不是 0，而是未定义标记对应的数值
  • 它不会帮你加上 NBT 附加值

在 addItemValue 事件里读取基础值​

OEVEvents.addItemValue(event => {
    let oldValue = event.getItemBaseValue('minecraft:diamond')
})

适合做覆盖前检查，或者按已有预设再做修正。

场景一：做一个最简单的查询命令​

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

这个例子虽然简单，但非常实用。

在调试整合包价值体系时，随手右键输出当前手持物品价值，比只看 Tooltip 更直观。

场景二：做回收系统​

典型思路是按最终价值的一定比例返还货币、积分或其它资源。

例如：

ItemEvents.rightClicked(event => {
    let value = OEV$ItemValueManager.getValue(event.item)
    let recycle = Math.floor(value * 0.5)
    event.player.tell(`回收可得: ${recycle}`)
})

这类系统最适合用最终价值，因为它会把 NBT 附加值也一起考虑进去。

场景三：做商店或兑换系统​

如果你希望商店价格与物品价值挂钩，可以直接读取价值，再乘上你的价格系数。

常见做法：

  • 买入价 = 最终价值 × 1.2
  • 卖出价 = 最终价值 × 0.5
  • 任务需求点数 = 最终价值 ÷ 某个基数

这样你就不需要再维护第二套完全独立的价目表。

场景四：任务奖励与成本判定​

如果你想做“提交总价值达到多少即可完成”的任务，也可以遍历物品并累计 getValue 结果。

这种思路适合：

  • 通用收集任务
  • 资源上交任务
  • 自动平衡阶段成本

场景五：限制机器或配方投入门槛​

如果某个机器只允许处理一定价值以上的物品，或者你希望按输入价值决定产出倍率，也可以把 One Enough Value 当成判定基准。

这类玩法的优点是：

  • 可扩展
  • 不依赖硬编码物品列表
  • 随着整合包价值体系一起变化

为什么推荐读“最终价值”而不是自己重算​

因为 One Enough Value 已经替你做了这些事：

  • 处理固定基础值优先级
  • 处理配方自动推导
  • 处理 NBT 附加值累加
  • 处理服务端同步

如果你在脚本里另写一套逻辑重算，往往会和模组本身的最终结果产生偏差。

使用时的注意点​

1. 尽量在服务端逻辑里读取​

价值的来源是服务端计算结果，因此做真正影响玩法的联动时，最好也在服务端脚本逻辑中使用。

2. 对无定义物品要有兜底​

不是所有物品都一定有价值。

当你用它做商店、任务、机器逻辑时，建议对未定义或非正数结果做保护。

3. 调试时优先对照 Tooltip​

如果脚本里读出的值和你看到的 Tooltip 不一致，先检查：

  • 你读的是基础值还是最终值
  • 该物品是否命中了 NBT 附加值
  • 服务端是否在 /reload 后重新同步了结果

常见联动方向​

  • 商店买卖价格
  • 物品回收返还
  • 任务提交点数
  • 机器处理成本
  • 掉落奖励倍率
  • 保险、租赁、修复等经济型系统