目錄

重要外掛列表與簡介

如果還有人記得我之前 PO 的尋找道具欄位 index 的文章，我在這邊鄭重地跟大家說

「binary search 已死，有事燒紙」

現在只要用 Inventory[{Slot:目標欄位}] 就可以抓出目標欄位來存取了，雖然之前那篇文章的方法可以用變數指定我要取得哪個欄位，但是那個效率跟這個完全不同等級啊！而且現在這個方式只要寫個 40 個 if 的 function 就也能透過變數來存取特定欄位了

狗才慢慢找，汪！

簡單來說就是讓玩家自己輸入特定內容，然後用 title 或 tellraw 顯示出來的功能

其實很久以前就有想過怎麼設計廣播系統最好，但是以前要抓玩家輸入的內容，唯一的方式就是命名，而不論命名生怪蛋還是命名牌，都必須消耗一個等級。然後 minecraft 又一直沒有判斷使用鐵砧的方式，所以都克服不了這個問題

然而現在 JSON 格式新增了 nbt 這個 component，也就是說不用再侷限於玩家將生物改名的這種文字輸入。那除了命名之外，玩家能輸入進遊戲的內容是什麼呢？

最簡單，也最方便的東西就是：書

只要給玩家一本書和羽毛筆，讓玩家自己把內容寫在書的第一頁，還能把書名當成標題

而且書本還能有另一個重要的用途，那就是可以抓到玩家的名字這個字串 (後面會用到)

簡單把對應的 nbt 路徑寫進 tellraw 跟 title 中，就可以輕鬆達成效果

由於書本內頁的內容也是 json 格式，記得讀取的時候要加上 interpret 這個標籤

data modify 應用

非動態的生物仇恨設定很久以前就出現了，透過召喚雪球或雞蛋帶有指定 UUID 來攻擊目標，嘗試將目標仇恨值轉移到指定的 UUID 上，但是 UUID 是事前就先寫死的，沒辦法在執行時才指定目標。

動態生物仇恨設定則可以在執行階段才指定 @p 之類作為仇恨的目標

1.13 出現 execute store 的時候我就很想做這個東西了，但是礙於用 data get 取得的數值會暫存為 int 類型，沒辦法完整儲存 UUID 這種 long 的數值，所以只能作罷。然而現在 data modify 跳過了暫存數值這個步驟，可以直接把項目搬移到新的目標位置，所以終於可以實現動態生物仇恨設定了

執行的概念很簡單，讓要轉移仇恨的目標召喚一個雪球，然後將指定仇恨目標的 UUIDLeast 與 UUIDMost 分別設定給該雪球的 owner.L 以及 owner.M 就完成了

這東西概念上更簡單了，只要把玩家的名字寫入頭顱的 SkullOwner 就行了

問題來了，玩家的名字並沒有寫在 nbt 標籤當中，要怎麼取得玩家的名字？還記得上面說書還有一個重要功能嗎，就是用書來取得玩家的名字

至於要怎麼讓玩家心甘情願寫一本書......

開場給玩家要求寫簽名檔，不然不給開始遊戲好了

有了這個功能，終於可以做出真正的鏡子了呢

這裡是哪裡？我是誰？

嘛，概念其實跟上一個應用一樣，反正玩家名字不會重複，只要把箱子的 Lock 標籤設定成玩家的名字，然後給玩家命名成自己名字的道具就行了

不過這個功能其實相對不太實用，因為這種東西的特性是可以無限擴充，無論多少玩家都能自動生成屬於自己的箱子，但這種箱子通常應該是要集中於一個小區域的，這時候無限擴充性就被區域內能放置的箱子數量限制了

要比較實用的話大概就是用在生存類的地圖，讓玩家可以隨時隨地召喚或收起箱子，又不用擔心朋友搶你東西之類的

附魔萃取應該算是滿知名的模組功能，可以把附魔萃取存到書本上

我當初在類模組就很想做了，不過當初沒有這麼強大的功能只好作罷。到了 1.13 出現了 execute store，我想說終於可以實現了。結果附魔的 id 活生生從數字被改成字串，我了個去

不過現在 data modify 出來，終於可以實現以前的夢想了

執行概念是讓玩家把指定道具放在指定欄位，然後把要萃取附魔的道具 Enchantments 存到書本的 StoredEnchantments 中，再把道具上的 Enchantments 清除並把書本改成附魔書就完成了

設計時可以自己決定是要把所有附魔一次萃取出來還是一個一個萃取，並且可以加上一些判定條件，像是指定欄位的道具必須存在附魔，以及後面放的必須是普通的書之類的

然後能夠從裝備萃取附魔，同理也能強制把附魔書上的附魔加在道具上，這樣就能讓玩家獲得同時有散射跟穿透的弩弓了呢！因為概念是一樣的，這部分我就不詳細介紹了

另外就是 Lore 編輯器的功能，這東西是我看到的影片裡面的內容，詳見 5:59

概念上跟附魔萃取很類似，所以一起在這邊提出來。個人認為是滿方便的一個功能

(這部影片在簡介 18w43a 的內容，有些部分比我這篇文章詳細，有興趣可以看完)

這東西應該也滿多人研究過的，不過普遍脫離不了召喚漏斗，然後把道具集中在漏斗上面。不過這做法最大的缺點就是漏斗傳輸速度很慢，掉落物數量一多就要很久才能收集完，而且通常體積都有點大

現在 data modify 出來之後，就不用再慢慢用漏斗收集物品了，可以直接把道具資料儲存起來。那問題來了，儲存在哪邊是最方便的？直覺來講就是箱子了。但是箱子有一個問題，箱子的欄位最多只有 27 格，但玩家身上最多有 41 個欄位，用箱子儲存 27 格道具之後新的道具就寫不進去了。

那有什麼東西是可以儲存道具資料，而且沒有數量上限的呢？有一個，那就是村民交易

只要召喚一隻村民，把掉落物寫進村民販賣的物品，交易上限一次，收購的東西設定成很廉價的道具，玩家就能輕鬆找這個村民把自己的道具拿回來了，不要的東西還可以隨他去，蒸蚌

一些相關的設定都是很有彈性的，像是要不要給村民無敵再用其他方式刪除他，或是可以在交易第一頁設定成取得收購物品的方便設定，就看各自使用時的需求了

那有沒有其他方式可以達成我們要的效果，我覺得翻頁翻得心很累。

有！只是相對就比較複雜

上面提過虛擬 nbt 已經是儲存資料非常方便的功能了，我們把它搬出來用

現在不要召喚村民了，我們召喚盔甲架，可以頭上戴一個可愛的箱子，並且不讓玩家拿下來或放東西上去，因為是盔甲架所以不太需要擔心被怪物攻擊的問題。記得虛擬 nbt 只能寫在道具類的 tag 中，所以我們就把它寫在頭上的箱子裡吧

跟把資料寫進村民交易的動作差不多，只是現在是把掉落物資料寫進盔甲架頭上箱子的虛擬 nbt 裡，這裡就取名叫 DeathCollecting 吧，類型設定為 list

把資料全部寫進去以後，要怎麼讓玩家拿回來才是重點。首先玩家想拿回掉落物就會把盔甲架打掉，打掉以後箱子就會掉出來。我們要在箱子被玩家撿走之前把道具「還原」出來，就像附魔可以萃取也可以反過來嵌入，道具資料可以存進虛擬標籤，也可以被還原成一般道具

還原的方式其實很簡單，只要依序召喚道具，把虛擬標籤中的資料寫入那個道具中，再把虛擬標籤內的資料移除，直到虛擬標籤被清空後清掉那個箱子道具即可

如何，雖然製作上多一道手續，但是對玩家來說是不是方便的多了？

不知道還有沒有人記得我之前發過一篇關於 UUID 的文章

沒錯又是我

在那篇文章中我有提到讓玩家看道具詳細資料的方式，原理是利用玩家死亡時會看到擊殺者使用武器的詳細訊息。但是每次玩家要看都必須要把玩家幹掉一次，實在細思極恐。而且每個拍賣欄位都必須召喚一個實體來對應 UUID (當然現在也可以用上面提到的動態生物仇恨轉移模式來節省實體數量，但是還是免不了要殺人，柯南都想來這邊拍一集了)，管理上非常不方便

那現在我們有什麼方式可以讓玩家看到道具的資料呢？沒錯就是上面才剛提到的村民交易

玩家登錄商品只要把道具資料寫進村民交易內容，輕鬆又愜意。不過村民基本上僅限於查看商品資料用，畢竟玩家如果跟村民買東西，登錄商品的玩家是拿不到錢的 (如果你想做判定哪個商品賣出去，給對應玩家增加錢也是可以啦，但是超麻煩)，還是把購買的動作獨立出來就好

不過如果要做成一個完整的，操作上沒有什麼問題的拍賣系統，還是需要處理很多細節的。像是玩家要知道自己要購買的物品是哪個編號、商品下架時要怎麼取回等等

這些東西我就不一一細說了，畢竟每個人的需求可能有些不同，而且我都已經介紹這麼多了，工具都放在那裡，如果你真的想做出一些創新的東西，就試著思考怎麼運用吧

虛擬 nbt list 實現 index 索引

看完上面這麼多內容，你可能已經蠢蠢欲動想要動手做點什麼了。各種功能的概念製作上都滿容易的，最大的問題往往是如何讓「操作流程」是順暢、沒有問題的

那你可能會遇到一個很大的問題就是，你要讀取某個資料的時候，你可能會需要根據編號去存取 list 中特定位置的資料，但是上面也提過：list 的 iterator 是沒辦法輸入變數的。這時候難道只能舉雙手投降嗎？NO！

我說過虛擬 nbt 的 list 已經是很方便的資料儲存型態，它可以當成 stack 或 queue 來使用。這樣說你可能還沒什麼想法，不過！

「一個 list 不夠，不會用兩個嗎？」

只要開一個 temp list，當我們要讀取某個編號的項目的時候，依序把 list 的第一個項目搬到 temp list 的最後面，並把我們的編號變數減 1，直到編號變數歸 0 時 list 的第一個項目就是我們要存取的項目了。當執行完我們要的運算之後，再將 temp list 中的內容一口氣 prepend 到原本的 list 中就大功告成了

不過這個做法是不建議大量使用的，尤其是 list 中的項目數量非常多的時候，運算會消耗大量的資源，建議用在不會常常需要更新的資料中。至於如果確定項目數量不會超過特定值，也可以考慮直接把所有可能的狀況一次寫進去做一一對應就好，這樣也能用上面說的新 nbt 存取模式 [{指定編號}] 來存取內容，方便許多

如果你對這個東西可以做什麼還沒什麼概念的話，那想想上面說的套用玩家頭顱吧。如果你在多人的狀況下突然想要取得某個玩家的頭顱，你總不可能每次都要求玩家先寫一本書或隨身帶著自己的書才能繼續玩吧？那如果你只有一開始儲存玩家的名字，之後你要存取的時候該怎麼知道要存取哪個資料呢？

或是你也可以想想看是不是能做到讓每個玩家都有自己的雲端道具欄呢？以往資料儲存在計分板的時候只要玩家離線就沒辦法更新他的資料，現在是不是能有解決方案呢？

就像我文章後面的部分大量提出各種問題，指令的學習需要的不只是穩固的知識基礎，更重要的是怎麼善用各種工具組合出我們想要的效果，因此我這篇文章沒有把詳細一條一條指令範例打出來 (絕對不是因為我懶喔)，只有自己想過得出來的結果才是自己的。

隨著一個一個更新，開放讓製作者能修改的內容越來越多，雖然功能越來越強大，但學習成本也越來越高。不知不覺我也玩指令玩了 5 年多了，有種自己已經老了的感覺呢。現在重心也漸漸從 minecraft 上轉移到其他地方了，研究就研究到這邊，至於怎麼讓這些新的功能發光發熱，就看各位能給它賦予什麼生命力了，期待各位精彩的表現！