第一百三十二章 生物的共通nbt-2

在上一章的末尾,我们发现玩家和生物其本身的nbt很多是互通的。所以,你能在生物的共通nbt中找到一些玩家身上也有的nbt。

比如:fallflying(值:布尔值)

fallflying是个布尔值,一般来说它是0。如果是1,生物(或者是说“非玩家实体”)就会像用鞘翅滑翔般滑翔起来。而如果是玩家,那么玩家当然是在滑翔时这个值才会是1,所以fallflying被用于检测一个玩家是否在滑翔。

那么这到底有什么用呢?

或许就是让非玩家实体滑翔起来吧,或者是用于服务器防飞行挂的鞘翅飞行检测,防止误判。

这是一个玩家和生物nbt互通的例子,而在生物的共通nbt中,还有很多这样的例子,比如这三个:

sleepingx(值:数值)

sleepingy(值:数值)

sleepingz(值:数值)

这三个标签并不是时时刻刻都会出现,因为这三个标签的作用是:

记录实体当前正在睡觉的床的坐标

为什么还要记录呢?直接使用实体本身的坐标不行吗?zuqi.org 葡萄小说网

肯定不行,因为mc是一个充满特性的世界。如果你哪天在mc里睡觉,没想到触发了一个特性,让你飘离床,在飞天神曲的沐浴下经过了流沙河,翻越了火焰山,到达了西天大雷音寺这样子在睡梦中完成了西天取经的十万八千里。然后你醒来了,如果游戏就是采用直接使用实体本身的坐标的话,那么——

“我是谁?我在哪?我在干什么?”

(过了一会)

这时东土大唐边境河州卫,玄奘正要离开驿馆。突然观音菩萨出现在玄奘面前,告诉他有人已经提前一步拿到了大乘佛法了。

玄奘:.........

所以mojang为了避免这种情况的发生,使用了在玩家睡觉的时候就记录床位置的方法,这样子就算玩家飘离了十万八千里再起来:

“啊~又是新的一天啊。”

“应该给自己的豪宅再升级一下了。”

(于是玩家挖了几块泥土)

“真不错。”

所以这三个标签是极其重要的。

只不过生物会睡觉吗?好像只有村民会哦。

比如现在这里有个村民,他睡在x=564,y=87,z=65这个床上,那么他这个时候的这三个值就是:

sleepingx:564,

sleepingy:87,

sleepingz:65

——————一个很不华丽的分界线———————

在上一章我们讲到,生命的最大值其实就是一个属性。如果我们要修改这个属性,该怎么办呢?

生物的共通nbt里就有这么个标签:

attributes(值:列表)

这是一个列表,所以它的值是这样的:

{attributes:[a,b,c]}

那么这些abc该填什么?

答案是属性:

{attributes:[{a属性},{b属性},{c属性}]}

既然是属性,我们就不妨复习一下一百零五章的属性修饰符:

“{attributemodifiers:[{}]}

在这个文件夹里,有这么几个文件,需要我们修改一下(记得去“*”号):

attributename*——要修改的属性id

name*——要修改的属性名字

slot*——指定生效的槽位

operation*——属性数值是怎样运算的

amount*——属性数值

uuidmost*——这个属性uuid的高位

uuidleast*——这个属性uuid的低位”

可以发现,当时讲到的属性修饰符,里面有很多个标签。

但别忘了,属性修饰符是属性的修饰符啊,我们现在才深入到属性啊,所以我们得先看看一个属性需要几个标签:

name——属性的名称

base——属性的基础值

modifiers——属性的修饰符

只有三个,看起来非常简单。实际上也非常简单,比如我们的生命最大值,它就是这样的:

{attributes:[{name:“_health“,base:20}]}

我们要修改,除了给这个属性添加修饰符,还可以直接把base值修改。

那么base可以修改到什么程度呢?

这个base值的类型是“双精度浮点型”,比我们上一章提到的“单精度浮点型”高级了一倍。

注意,这里的“高级了一倍”不是作者自己猜的,而是有实际依据的,因为:

单精度浮点型——占用空间:32位(4字节)

双精度浮点型——占用空间:64位(8字节)

占用空间增加了一倍,确实是高级了一倍。

但如果按照这样子说的话,64位系统岂不只是32位系统的两倍?

那肯定是不对的。所以我们的这两个浮点型,它们虽然占用空间是两倍的关系,但实际可储存的数值是:

单精度浮点型——取值范围:-3.4e38~3.4e38

双精度浮点型——取值范围:-1.e308~1.e308

嗯,确实,是高级了亿倍.......好像还不止

所以,其实你的生命值上限最高并不是2048,也不是,而是:

1.x3081?!

所以,你还敢说你的创世之刃是能秒杀一切的武器了吗?

剩下的modifiers就很简单了,因为我们早在第一百零五章就讲到了。只不过这里的modifiers有些不一样,它只剩下了四个参数(1.16及以上5个):

name——要修改的属性名字

operation——属性数值是怎样运算的

amount——属性数值

uuidmost——该修饰符的uuid高位

uuidleast——该修饰符的uuid低位

(1.16版本uuidmost和uuidleast合并成了uuid)

具体的用法就不再细说了,自己去一百零五章看吧。

(似乎篇幅不够,再来一点吧)

接下来的标签是:

handitems(值:列表)

handitems很容易理解,就是生物拿着的东西。又因为mc的生物都是有两只手的(你跟我说史莱姆有手?),所以handitems的列表是固定两个项目,一个主手,一个副手:

{handitems:[{主手},{副手}]}

而这个主手和副手内填的就联系到我们的物品共通标签了:

count——物品数量(值:数值)

id——物品id(值:字符串)

tag——物品的额外标签(值:复合标签——{})

具体的我就不再讲了,已经讲了很多次了,况且才4个标签(还有一个slot),非常简单,傻子都能记住。

举个例子,比如村民的主手正拿着一个面包,那么他的handitems值就是:

{handitem:[{count:1,id:“minecraft:bread“}]}

灰常简单是不是?

但如果这个村民拿着这个面包就被杀死了(哦天呐!),掉落这个面包的几率是多少呢?

虽然我们不知道几率是多少,但我们可以更改几率,这样子我们就知道了!

控制村民的手中物品掉落几率的标签是:

handdropchances

这也是个列表,也有两个项目,分别代表着主手和副手掉落物品的几率。

这个几率的值是单精度浮点型,所以如果你想更改主手和副手掉落物品的几率为78%的话,那么需要这么改:

{handdropchances:[0.78,0.78]}

这样子就可以了,还是灰常简单的。

ok这一章我们就先讲到这,我们下一章再见!

(不知不觉国庆就已经过完一半了啊.......)

现在是中午12点整,王五和赵六正坐在橡木楼梯上刷b站。突然王五像触电似的站了起来:“wo cáo?”

“发生了什么事?”赵六瞟了一下王五,继续看敖厂长的新视频。

“wo\bcào!”王五突然又叫了一声。

“哎你能不能别......”赵六话还没说完,王五又来了第三声:“wo\bcào太棒了!”

“你老是卧槽卧槽干什么啊?”赵六决定看看王五到底在看什么,于是把头伸了过去。

“wo cáo?”

“wo\bcào!”

“wo\bcào太棒了!”

只见那个视频的标题是:

《洞穴更新成了!minecraft 1.17 更新特性汇总!洞穴与峭壁更新!》

上一章目录+书架下一章