【MCBE】服務器命令方塊系統bug合集
最近看了許多用于MCBE原版服務器使用的命令方塊系統，看得最多的就是“菜單”、“傳送”、“商店”、“防熊”。
其中有許多系統存在者bug，雖說一些bug只會給游戲體驗帶來小小的瑕疵，但有的bug甚至能夠刷物品，下面我會列舉一些常犯的錯誤，供各位腐竹、op參考。
比如說一個擺在服務器生存區入口的命令方塊，上面是一個壓力板，里面有這樣的指令
/tp@p0640(主城的坐標)
看上去毫無問題，然而玩家a某天在附近挖礦，忽然就被傳送到主城(a:？？？)
原來有一只動物路過踩到了壓力板......
/tp@p[r=5]0640
改成如上就不會出現問題了，因為這樣一來便限定了目標的范圍，確保離這個命令方塊很遠的玩家不會被莫名其妙傳送。
說通俗點就是“用中繼器延遲”，下面舉個“玩家間傳送系統”的例子。
功能:玩家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的玩家旁邊的玩家停止低頭
例子還是用剛剛的“玩家間傳送系統”，如果抬頭的玩家不止一個該怎么辦？這時就需要想辦法彌補，比如說傳送的時候用@r選取隨機一個抬頭玩家。或者改用新的思路解決問題
為什么這個算bug？因為太慢了，會出事。
命令方塊響應到比較器輸出要2gametick，比較器輸出到激活下一個命令方塊又要2gametick
這樣一來，我就可以趁判斷的時候干壞事，比如檢測箱子里有物品a就給玩家經驗，并清除箱子中物品，我可以在放進去的一瞬間再把它拿出來，這樣我就可以什么也不付出而獲得經驗。
兩種判斷條件方法解決方法就是把第二個方塊換成連鎖命令方塊緊跟在后面，設置為條件允許，總是開啟。這樣就是0延遲的瞬間處理。
有時候非要趕著輸出紅石信號也要用上面的方式setblock紅石塊。
5.用@e[name=x]指定掉落物
為什么不能這么用？因為name是物品的名字，而不是種類。
我把泥土重命名成“鉆石”可以輕而易舉欺騙命令方塊，它分辨不出是挖鉆石礦掉出來的鉆石，還是名叫“鉆石”的泥土。
更有甚者，連type=item都不加，那就可以用命名牌重命名生物或盔甲架，在一些用到kill的地方會出現很嚴重的事故。
解決方法是勸退。
解決方法是尋找替代的方案或等mojang更新。
這類bug在“物品商店”里最常見
clear@piron064
當這條命令執行成功時，并不代表玩家有64個鐵，而是代表玩家有1個以上的鐵。
這個bug不修復后果很嚴重，64鐵換1鉆石變成1鐵換1鉆石......
解決方法是改成兩條，先clear63個，再clear1個，這樣不足64鐵時第二條命令就會執行失敗。但這樣又帶來了新的bug，鐵不夠會直接消失，白白浪費。
新的解決辦法是放牌子警告玩家，或者改用testforblocks檢測容器的方法做商店
以上就是小編為大家收集的我的世界服務器命令方塊系統常見的bug合集，希望能給大家帶來幫助。(？？？)
感謝各位的耐心觀看，求按下