存数据的性能排序：玩家>方块实体>实体>marker>storage。 (把大于号理解为消耗排序)

marker得是固定UUID才能体现出来优势。 

存物品的话，如果量少，可以考虑固定位置的唱片机。 

storage存数据也是层数越少越好。 

任何遍历方块的方法都是得和实体绑定。 

根据数字形式的uuid找实体：把uuid给固定uuid的物品的Thrower标签，然后as xxx on origin。 

优化性能的大头就是优化nbt、选择器和实体数量。 

@a比@e[type=player]性能好，但是后者可用于只搜寻活着的玩家。 虽然如此，也不要高频太大量使用@a。

选择器里只有distance、dxdydz、limt、type这四种条件是优化选择器性能。 

把多个实体类型写进一个tags里然后使用[type=#xxx]比多个[type=xxx]好。 

千万不要写[nbt=]这种条件，如有需求请换成if data。 

操作记分版永远是性能最好的。像return、记分版、单层storage、if item、if block这类命令消耗是最低的，一种优化数据包的方法就是把高消耗的判断转化为记分版数值的判定。 

记分版里#开头的虚拟玩家性能比较好。 

展示实体的矩阵分解消耗很大没必要别用。 

函数宏的消耗大头是命令解析，所以优化方法是缩短宏命令的长度。 

二分是一种思想，数据包里最好的是四叉树。 

记分版虚拟玩家是用哈希值索引的，速度非常快，所以记分版数量再多也不影响单条计分板命令的消耗。 

获取列表长度，data get list比if data list[]好。 

nbt是二进制格式，snbt是字符串。但讨论nbt一般都是认为是在讨论snbt。 

data get一个值会进行向下取整然后把范围限制在int内，但是execute store result +倍率不会。所以execute store +data get的本质是int乘double。 

一个tick里更新的顺序固定为：世界边界>函数>实体>方块实体>玩家。 

所以函数、命令方块和玩家执行的命令的更新时序都不一样，因此产生不同效果也很正常。 

每个维度是先后更新的，顺序为主世界>下界>末地。也就是说把主世界里的单刻的任务都执行完了才更新下界。 

所以用数据包处理夸维度的东西都很麻烦。 

以及，进度的更新是伴随着事件立即触发的，所以不同进度的时序很不确定。

粒子会给每个能"看见"它的玩家发一个包，这里的看没看见是由产生粒子的算法决定的，就算玩家把粒子特效关了还是会产生发包，所以大量的粒子都非常吃服务器下行。 

玩家跑图产生的发包吃的是服务器上行。 

粒子同时吃服务端的计算、客户端的渲染、服务器的下行。 

Java版的随机数生成器是LCG方法(线性同余发生器)。

战利品表的数值提供器里的随机器的随机长度是2147483709（比random命令长一些），但上限只能是2147483583 。 

MC里double上限的精确值是1.7976931348623157E308。 数值部分最多保留17位。

MC里double的绝对值最小值是4.9E-324。 

mcfunction是一门专属于Minecraft的图灵完备的命令行类解释型脚本语言。  

自从函数宏、return命令的加入它就不再完全是打包的命令方块了。  

 有什么是数据包可以做到的而命令方块做不到的呢？ 比如我让一只羊去一个未加载区块放一个方块再回来。 

不推荐命令方块的原因： 命令方块受制于区块加载 而且命令方块本身是方块实体，处理命令方块里的命令的同时还要处理命令方块本身的数据。这在命令方块较多的时候有明显的感觉。 两千条命令放在函数里就是一瞬间，放在命令方块里那就是卡服山。 

红石还带有红石刻和光照的计算更卡了，红石高频+命令方块就是卡服神器。 红石因为没有方向，所以你看上去闪了一下的红石实际上是反反复复来回更新了很多次。红石线本身有15个等级，所以一个红石线至少会更新15次。 

为什么现如今不推荐用低版本做地图？   

mod比数据包强是显然的，但除非你愿意定制，否则你用现成的mod做地图在大多数情况下实现效果是不如数据包的。 太低的版本（比如1.7.10）只能靠mod。 

但是mod多了会有很多棘手的问题： 

1.mod的冲突  

2.mod太多了产生各种化学反应各种奇妙的bug  

3.性能不好优化  

4.风格不统一看着太花了  

5.mod用多了给人一种廉价感，而且东西太多新人入坑还要先学学你加的mod怎么用。 

大多数人想用mod其实是喜欢一些比较"便利"的mod(比如NPCmod)和一些比较实用的mod(比如枪械)。 其实NPCmod用起来你会发现这玩意儿除了有图形界面啥都不如数据包，枪械这种，最新版数据包的物品除了ID都能定义了，各大数据包作者做出来的枪械效果也都不错，没必要死磕着mod不放。我们不是说不让用mod，我们是更倾向于选择一些对开发友好的mod(比如地毯mod、ysm等)。

  一句话：mod的优势体现在定制mod。 

 而且自定义NPC(下称NPC)本身带有许多设置项，你放一个NPC看一下他的nbt就会发现他的每一项设置都有存在nbt里的默认值。而用NPC的作者通常都不会一次性使用全部功能，然而mc解析nbt时会把一个实体的初级nbt都解析一遍，一个NPC有一堆默认值，这导致几乎每个NPC都会带来一些地图作者本身不需要的额外的性能消耗，然而NPCmod为了保证NPC正常运行这些数据又必须要存在。所以现在非常不推荐NPC（除非你善于用它自带的脚本）。