3,417
个编辑
→最后： // Edit via Wikiplus
（// Edit via Wikiplus） |
（→最后： // Edit via Wikiplus） |
||
| （未显示同一用户的3个中间版本） | |||
| 第39行： | 第39行： | ||
== 具体应用 == | == 具体应用 == | ||
=== NBTTagCompound == | === NBTTagCompound === | ||
NBTTagCompound的底层实现，实际上是依托于一个非静态HashMap<String, NBTBase>字段 —— 这就是为何Minecraft要把某些常用的类型进行封装，毕竟设定成HashMap<String, Object>总不合适吧？ | NBTTagCompound的底层实现，实际上是依托于一个非静态HashMap<String, NBTBase>字段 —— 这就是为何Minecraft要把某些常用的类型进行封装，毕竟设定成HashMap<String, Object>总不合适吧？ | ||
| 第46行： | 第46行： | ||
此外，该类还有诸多好用的方法，如hasKey、removeTag等等。 | 此外，该类还有诸多好用的方法，如hasKey、removeTag等等。 | ||
== NBTTagList == | === NBTTagList === | ||
NBTTagList的使用很简单，它本质上就是对ArrayList<NBTBase>的简单封装，我们可以通过appendTag、removeTag这两个方法来完成对某个NBTTagList中保存的NBTBase对象的增添或移除。 | NBTTagList的使用很简单，它本质上就是对ArrayList<NBTBase>的简单封装，我们可以通过appendTag、removeTag这两个方法来完成对某个NBTTagList中保存的NBTBase对象的增添或移除。 | ||
== 实例 == | 另外，NBTTagList类实现了Iterable<NBTBase>接口，这意味着我们可以用foreach循环来便捷地遍历一个NBTTagList。 | ||
=== 实例 === | |||
前文说过，ItemStack的信息实际上是以NBT格式存储的。比如一把附魔了耐久三的满耐久钻石镐，其字符串形式的NBT标签应该是这样的： | 前文说过，ItemStack的信息实际上是以NBT格式存储的。比如一把附魔了耐久三的满耐久钻石镐，其字符串形式的NBT标签应该是这样的： | ||
| 第75行： | 第77行： | ||
== 最后 == | == 最后 == | ||
# | # 对NBT对象的构造一定要发生于逻辑服务端正在运行的时候，否则逻辑客户端肯定会抛NPE并崩游戏。且只有ItemStack的NBT是会自动双端同步的，其他地方的NBT若想完成同步，需要手写双端通信的代码，有的基于覆写若干方法，还有的基于Forge提供的双端通信系统。 | ||
# NBTTagCompound中存储的额外信息，如果不是给Minecraft原版的代码用的，而是为你自己的Mod的逻辑用的，那么存储的额外信息所对应的NBTBase对象，所对应的键名，'''并无特别要求'''。那为什么存储附魔信息的必须是一个NBTTagList，并存于ItemStack的附加NBT中，对应的键名必须为“ench”呢？因为这是Minecraft原版读取ItemStack中附魔信息的相关代码所决定的。如果你放进NBT中的信息是给你自己的Mod用的，那键名任你取，就没有什么要求了。不过你还是最好以你的ModName为名称开个子标签，再写入你自己的数据，这是为了防止别的模组也向该NBT中添加额外数据，且键名发生冲突的情况。 | # NBTTagCompound中存储的额外信息，如果不是给Minecraft原版的代码用的，而是为你自己的Mod的逻辑用的，那么存储的额外信息所对应的NBTBase对象，所对应的键名，'''并无特别要求'''。那为什么存储附魔信息的必须是一个NBTTagList，并存于ItemStack的附加NBT中，对应的键名必须为“ench”呢？因为这是Minecraft原版读取ItemStack中附魔信息的相关代码所决定的。如果你放进NBT中的信息是给你自己的Mod用的，那键名任你取，就没有什么要求了。不过你还是最好以你的ModName为名称开个子标签，再写入你自己的数据，这是为了防止别的模组也向该NBT中添加额外数据，且键名发生冲突的情况。 | ||
== 注释与外部链接 == | |||