Minecraft有BUG吗其中有许多系统存在者bug，虽说一些bug只会给游戏体验带来小小的瑕疵，但有的bug甚至能够刷物品，下面偶会列举一些常犯的错误，供各位腐竹、op参考。
1.目标选择器不加范围
比如说一个摆在服务器生存区入口的命令方块，上面是一个压力板，里面有这样的指令
/tp@p0640(主城的坐标)
看上去毫无问题，然而玩家a某天在附近挖矿，忽然就被传送到主城(a:？？？)
原来有一只动物路过踩到了压力板……
/tp@p[r=5]0640
改成如上就不会出现问题了，因为这样一来便限定了目标的范围，确保离这个命令方块很远的玩家不会被莫名其妙传送。
2.所有玩家共同计算延迟
说通俗点就是“用中继器延迟”，下面举个“玩家间传送系统”的例子。
功能:玩家a低头，玩家b抬头，三秒后将a传送到b的位置。
实现起来非常简单，用teatfor指令探测低头玩家和抬头玩家，连接与门，输出端接一串中继器，最后是一个命令方块，将所有低头玩家传送至抬头玩家。
玩家间传送系统(有bug)找两个人测试一下，正常运行，看样子应该没有bug了吧？
错了，当延时2.9秒后，玩家c忽然低头，或许他只是想挖脚下的矿，但却被瞬间传送到玩家b的位置。
问题出在哪里？中继器只有一串，因此这个延迟并不代表a传送的延迟，而是代表整个系统的延迟，相当于a和c“共享”了一个计时器。
解决方法是创建两个用来传送延迟的计分板dt和tt，为每个玩家单独计算延迟。
以下①②③④反复执行，每gametick循环一次
①为所有低头玩家增加dt的分数，抬头玩家同理
②把所有没有低头的玩家dt的分数设为，抬头玩家同理
③把所有dt分数大于60的玩家tp到tt分数大于60的玩家玩家
④用tp让所有在tt分数大于60的玩家旁边的玩家停止低头
3.目标数量不确定
例子还是用刚刚的“玩家间传送系统”，如果抬头的玩家不止一个该怎么办？这时就需要想办法弥补，比如说传送的时候用@r选取随机一个抬头玩家。或者改用新的思路解决问题
4.用比较器做条件判断
为什么这个算bug？因为太慢了，会出事。
命令方块响应到比较器输出要2gametick，比较器输出到激活下一个命令方块又要2gametick
这样一来，偶就可以趁判断的时候干坏事，比如检测箱子里有物品a就给玩家经验，并清除箱子中物品，偶可以在放进去的一瞬间再把它拿出来，这样偶就可以什么也不付出而获得经验。
两种判断条件方法解决方法就是把第二个方块换成连锁命令方块紧跟在后面，设置为条件允许，总是开启。这样就是0延迟的瞬间处理。
有时候非要赶着输出红石信号也要用上面的方式setblock红石块。
5.用@e[name=x]指定掉落物
为什么不能这么用？因为name是物品的名字，而不是种类。
偶把泥土重命名成“钻石”可以轻而易举欺骗命令方块，它分辨不出是挖钻石矿掉出来的钻石，还是名叫“钻石”的泥土。
更有甚者，连type=item都不加，那就可以用命名牌重命名生物或盔甲架，在一些用到kill的地方会出现很严重的事故。
解决方法是劝退。
解决方法是寻找替代的方案或等mojang更新。
6.靠clear检测背包内物品数量
这类bug在“物品商店”里最常见
clear@piron064
当这条命令执行成功时，并不代表玩家有64个铁，而是代表玩家有1个以上的铁。
这个bug不修复后果很严重，64铁换1钻石变成1铁换1钻石……
解决方法是改成两条，先clear63个，再clear1个，这样不足64铁时第二条命令就会执行失败。但这样又带来了新的bug，铁不够会直接消失，白白浪费。
新的解决办法是放牌子警告玩家，或者改用testforblocks检测容器的方法做商店
以上就是小编为大家收集的偶的世界服务器命令方块系统常见的bug合集，希望能给大家带来帮助。(？？？)
感谢各位的耐心观看，求按下