※ 引述《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 名字的物品