第119章掉落物的NBT下

众所周知，使用/give指令会让你获得一个指定的物品。

比如/give@scommand_block就是让你获得一个命令方块。

但你知道你是怎么获得这个命令方块的吗？

在你按下运行建的那一刻，这条指令会被后台的java虚拟机进行处理，然后在你的位置生成一个命令方块掉落物。

在生成的那一刻，这个命令方块就会被捡起，所以在java版运行give获得物品会有一个捡起的动画（基岩版没有动画，所以不容易被发现）。

但如果在生成的那一刻没有被捡起（比如你的背包满了），那么这个命令方块就会凭空消失。

那么这个掉落物的属性是什么呢？

pickupdelay值肯定为0，age值很有可能是6000。

这里符合上面的属性。

但此时又有一个新的问题出现了：如果是在服务器中，你站在茫茫人海，但这个掉落物仍然被你精准地捡起了，这是为什么呢？（说实话还没等你捡起你家宽带以及你的电脑就要主机火苗万丈高了）

因为掉落物的nbt还有一个非必填项目：owner

owner值决定了这个掉落物可以被哪个玩家捡起，具体是这样的：

{owner:{uuidmost:，uuidleast:}（1.16版本以下）

{owner:}（1.16版本）

而这里的uuidmost和uuidleast就是这名玩家的uuid高位以及uuid低位。

估计有些人到现在都还搞不清楚uuid。

那么uuid下一章讲。

那么1.16版本填什么东西？

还是uuid啊，只不过是1.16版本的uuid，之前有一章有提到（忘记哪一章了）。

但问题来了，怎么获取那些玩家的uuid呢？

算了，继续讲吧。

假设你在矿洞挖矿，刚刚挖到8颗钻石，你很兴奋，然后听到后面有一个........

“嘶～～～”

你转头一看：“creeper？”

“booooom！”

恭喜你，你的钻石成为了一个掉落物。

这颗钻石掉落物的nbt也值得研究。

这个nbt除了上一章所说的，还有一个你从未见过的nbt值：

thrower——这个物品本来是谁的

和owner一样，这个填的也是uuid。

这个uuid在这里代表着这个物品本来归这个玩家的。

然后这名玩家把这个物品以某种形式丢掉了（比如做个520礼物给心上人？记得520还没过去几天）。

当然，你也可以在生成的时候编辑这个uuid，然后伪造一起掉落物盗窃案。

（张三：“阿嚏——完蛋了，会不会被抓去隔离。”）

但好像这也没什么用啊？

ok这一章就到这里了，下一章就讲一下uuid到底是怎么个回事。

easecation真tm好——唉，好像作业还没做唉。