※ 引述《lulanee (吃我的原质拉(掏)》之铭言：
: ※ 引述《hfs (快乐!移民日本!梦想成真!)》之铭言：
: : nbt data.meta data.ore dictionary差别?
: : 常常看dw20的mod spotlight会介绍到这三种东西.
: : 但是我不懂nbt data.meta data.ore dictionary这三个属性有什么差异.
: : 是指一个方块的三种不同的特性吗?
: : 谢谢.
: meta data:
: meta data = damage value
: 物品或方块的第二id
: 方块只有4 bits, 只能存值 0~15
: 物品则可以塞0~65535
: 官方通常用meta data来表示同一种方块不同显示方式
: ex:
: 木头跟羊毛方块用meta data来抓贴图, 用来显示出不同颜色的方块
: 熔炉用meta data来表示方块的朝向(东南西北), 然后依照朝向画上贴图
: 可以存的资讯量少, 尤其是方块只有0~15可以用
: mod一般也只是把meta用来储存方块朝向或者颜色之类的
: 要存大量额外资料就要用nbt data
这东西其实可以统称 data value
对于方块的 DV, 官方从 1.8 开始新增了所谓的 block state
预计是要取代单纯 4-bit 资料值的方式
改用类似 NBT 的方式来做描述性的储存
一来指令使用方便, 二来变化性可以更多
三来可以防止一些利用方块的 DV 值改变再换掉方块
以达成更改其他另一些方块的 DV 值的 bug
(最近的例子是利用金压力板射箭的 bug, 已经在 1.7.6 被修掉了:
https://www.youtube.com/watch?v=KpGyRrH5OpQ )
1.8 目前还是两者共存的方式, 在 F3 画面的右边可以看到你正看向的方块的 state
也因为只有 4-bit 16 种变化, 有些后来新增的变化就不得不另外用个 ID
最好的例子就是现在的六种木头:
木板只有六种状况, 所以只需要一个 ID 5
新木半砖有上半下半两种, 所以也是一个 ID 126 全包
原木有四种状况 (三轴摆法跟六面都是树皮的), 4-bit 不够用了
所以在原来的原木 ID 17 之外, 最新的两种 (相思木跟黑橡木) 是 ID 162
阶梯则更复杂了, 四个方向跟正放反放一共八种状况, 所以六种木头阶梯是六个 ID:
橡木 53, 杉木 134, 桦木 135, 丛林木 136, 相思木 163, 黑橡木 164
有时候方块的 DV 不只控制显示方式, 还跟环境的互动有关
例如红石火把, 技术上它是存在火把所在的那一格
而它插在哪一面上则是使用 DV 储存, 这就关系到它是吃旁边哪个方块的充电程度了
又例如门, 门的开关及面向也是使用 DV, 这会影响所有 mob 判断能不能走过这一格
物品的 data value 则是在早期这个值被称做 damage value (损害值) 的原因
(也因此才有 DV 这个简写, 这样两边都解释的通)
这是由于对有耐久度的物品, 这个值是用来储存物品被使用的次数
不过因为有 16-bit 可以用, 所以一些变化比较多的东西会利用它来存
例如药水, 所有的药水的 ID 都是 373, 而是什么药水则由它的 DV 决定
16-bit 里面有一些 bit 还会拿来做类似旗标的标记
像是第 14 bit (16384) 用来标记是否可投掷
所以投掷药水都是大于 16384 的 DV 等等
这里可以看到因为空间比较大所以不会像上面木头的例子用这么多 ID
不过药水算是一个比较杂的例子, 一般这种程度的东西多半都是直接用 NBT 存了
药水因为是早期进入游戏的东西所以才是使用这种方式
这个值在游戏里可以按 F3+H 来显示, 它会跟着 ID 显示在名字后面
: nbt data:
: 额外附加于物品或者方块的资料
: mod想要额外存什么东西都是写进nbt data
: 只有meta跟nbt才会被写进硬盘, 其他变量只要服务器重开机就没了
: 除非另外写个存资料的方法
: nbt大小似乎不限, 不过塞太大(超过几百mb)会让官方内建nbt的封包读写方法出包
NBT 这个词在 1.7 开始有一个类似但不太一样的意义
在这之前由于 NBT 单纯是个二进制储存方式
一些外部 NBT 编辑程式或 mod 也都是照着这个储存方式去显示资料的
但在 1.7 开始有些指令可以附上一些资料去指定指令效果的细节
这个资料格式最终还是去更改物品或方块的 NBT 资料
但在指令上的格式是类似 JSON 的格式
因此有人会称这个指令上的 JSON 资料为 NBT 资料
基本上如果不是太挑剔的人的话这一点混用其实无伤大雅就是
(而且说实话, 它确实是在描述一个 NBT 资料
只有在少数 1.8 的新指令里它才是一般的 JSON)
关于读取问题
其实现在麦块绝大多数的资料在磁盘上都是存成二进制 NBT 格式 (太大的还会压缩)
最大宗的就是整个世界的地形
所以其实没用太凶的话是不用担心会炸掉就是
(相对的, 所谓 chunk error 基本上就是读炸了的后果...)
: ore/liquid dictionary:
: forge为了让矿物共通做出来的东西
: mod在ore dictionary登录矿物时会塞一条识别名称
: 所有用同一个名称的矿物, 在配方处理时会被当成同一种矿物
: 可以到forge wiki查目前有哪些mod用了什么名字登录矿物
: 识别名称的命名规则wiki有写
: 可以登录的除了矿物, 还包含木头, 楼梯, 半砖, 染料等
: 同样的液体也有dictionary, 不过目前登录的液体种类很少
最早这东西的动机确实是矿物共通
(同样是 Tin, forge wiki 上就列了至少八个 mod 有 Tin
如果其中一些 mod 一起用的话这个 mod 的 Tin 不能用在别的 mod 实在令人很囧)
不过到现在, 只要 mod 里有什么东西想看成一样或是可取代性的
就可以在 ore dictionary 里塞名称
像 Pam's Harvestcraft 就用的很凶:
那里所有食物都在 ore dictionary 里有不只一个名字
其中有几个会是类似类别的名字 (例如所有肉类、所有菜类等等)
这样需要任意某类别食物的配方可以使用这个名字一把抓
一些万用食物 (例如 Tofu) 会登记一串它能取代的食材名
这样可以达成用这些食材的配方也可以使用 Tofu
不过就算有了这机制, 如果 mod 配方没写好的话事情还是很难搞
MFR 为此有一个机器叫 Unifier 可以转换有同样 ore dictionary 名字的物品