[討論]「BUD的原因-假說」(1.01版)

看板Minecraft (當個創世神)作者 (連作者也不會修的BUG)時間13年前 (2013/01/28 21:19), 編輯推噓4(4010)
留言14則, 5人參與, 最新討論串1/1
一、前言:BUD是連麥塊的作者自己都不知道怎麼修的BUG,所以本篇全是毫無根據 的亂解釋,到底對不對,除非等到麥塊的作者修好BUD才知道。 二、第一個問題:如圖甲,紅石線為什麼可以下樓梯傳遞亮訊號? http://i.imgur.com/Javsw0W.png
第二個問題:如圖乙,紅石線下樓梯時為什麼會被方塊斷路? http://i.imgur.com/c7cYBy9.png
第三個問題:如圖丙,紅石線為什麼可以上樓梯傳遞亮訊號? http://i.imgur.com/bFh9NFg.png
第四個問題:如圖丁,紅石線上樓梯時為什麼會被方塊斷路? http://i.imgur.com/N1niiZx.png
第五個問題:如圖戊,紅石線為什麼可以下樓梯傳遞暗訊號? http://i.imgur.com/wGSresS.png
第六個問題:如圖己,紅石線為什麼可以上樓梯傳遞暗訊號? http://i.imgur.com/HC2u0dY.png
第七個問題:以程式設計師編寫程式碼的角度, 程式流程圖要如何寫才能達成全部的目標? 看起來好像很簡單的問題,但是我嘗試了很多種方法最後都會 產生矛盾,成功的只有下面這種! 三、假說一:當方格更新時,用極快的速度讓東南西北上下6個方格更新, 並且訊號改變的時間很短暫約0.05秒, 利用這短暫的訊號變更使得所有關聯的方格進行更新 舉例1:從甲變成乙時,更新周圍6個方格,更新到下面紅石線a時, 檢查斜上角東西南北4個方格,發現右邊有一個A充能紅石線, 所以讓下方的a紅石線充能但只有0.05秒然後就熄掉, 然後更新下方的a紅石線發現上面被擋住, 所以切斷和右邊的A紅石線的連線然後變暗, 然後a更新左邊b變成暗,然後更新左邊c變成暗............. 舉例2:從乙變成甲時,更新周圍6個方格,更新到下面紅石線a時, 檢查斜上角東西南北4個方格,發現右邊有一個A充能紅石線, 所以讓下方的a紅石線充能但只有0.05秒然後就熄掉, 然後更新下方的a紅石線發現上面沒被擋住, 所以接通和右邊的A紅石線的連線然後變亮, 然後a更新左邊的b紅石線變亮,然後再更新左邊的紅石線c變亮.... 舉例3:從丙變成丁時,更新周圍6個方格,更新到下面紅石線a時, 檢查斜上角東西南北4個方格,發現右邊有一個A充能紅石線, 所以讓下方的a紅石線充能但只有0.05秒然後就熄掉, 然後更新下方的a紅石線發現上面被擋住, 所以切斷和右邊的A紅石線的連線, 更新右邊的A紅石線發現來源被切斷所以變暗, 然後A再更新右邊的B紅石線變暗, 然後B再更新右邊的C紅石線變暗...... 舉例4:從丁變成丙時,更新周圍6個方格,更新到下面紅石線a時, 檢查斜上角東西南北4個方格,發現右邊有一個A充能紅石線, 所以讓下方的a紅石線充能但只有0.05秒然後就熄掉, 然後更新下方的a紅石線發現上面沒被擋住, 所以接通和右邊的A紅石線的連線, 更新右邊的A紅石線發現來源被接通所以變亮, 然後A再更新右邊的B紅石線變亮, 然後B再更新右邊的C紅石線變亮...... 舉例5:從甲變成戊時,更新A紅石線變暗,然後更新X空氣, 更新周圍6個方格,更新到下面紅石線a時, 檢查斜上角東西南北4個方格,發現4個都是沒充能紅石線, 所以讓下方的a紅石線沒充能但只有0.05秒然後就又充能, 然後更新下方的a紅石線發現來源A變暗所以更新a變暗, 然後又更新b.......... 舉例6:從丙變成己時,更新a紅石方格變暗,然後更新X空氣, 更新周圍6個方格,更新到下面紅石線a時, 檢查斜上角東西南北4個方格,發現有1個A充能紅石線, 所以讓下方的a紅石線亮但只有0.05秒然後就又變暗, 然後更新右邊的A紅石線發現來源a變暗所以更新A變暗, 然後又更新b.......... 四、假說二:只有活塞不小心使用到了紅石線的部份程式碼,其他機關沒有 但是1:活塞不會像紅石線檢查斜角方向有無接通 但是2:活塞遇到極短暫的訊號(0.05秒)只能做出第一個反應, 第二個反應就來不及做出來,所以就卡住了。 BUD的情況:(術語請参見上一篇文章「BUD的原理」) BUD的機制甲:當方格B更新時,更新周圍6個方格,更新到活塞時, 檢查斜上角東西南北4個方格,發現方塊A有一個充能, 所以讓下方的活塞充能但只有0.05秒然後就熄掉, 但是活塞遇到極短暫的訊號(0.05秒)只能做出第一個反應伸長, 第二個反應縮回就來不及做出來,所以就保持伸長。 BUD的機制乙:當方格B更新時,更新周圍6個方格,更新到活塞時, 檢查斜上角東西南北4個方格,發現方格A都沒充能, 所以讓下方的活塞沒充能但只有0.05秒然後就充能, 但是活塞遇到極短暫的訊號(0.05秒)只能做出第一個反應縮回, 第二個反應伸長就來不及做出來,所以就保持縮短。 五、後言:BUD是連麥塊的作者自己都不知道怎麼修的BUG,所以本篇全是毫無根據 的亂解釋,到底對不對,除非等到麥塊的作者修好BUD才知道。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.64.69.53

01/28 22:41, , 1F
0.05秒其實應該可以再精準估計到到0.007秒以內
01/28 22:41, 1F

01/28 22:42, , 2F
1tick = 0.05秒
01/28 22:42, 2F

01/28 22:58, , 3F
本篇預設是紅石刻0.1秒來解釋
01/28 22:58, 3F

01/28 23:03, , 4F
然後方塊更新花費時間其實應該從0.05秒改成0.007秒以內
01/28 23:03, 4F

01/28 23:22, , 5F
方案一:假設 然後實驗 方案二:看程式碼比較實際
01/28 23:22, 5F

01/28 23:22, , 6F
結果都是腦子燒掉..
01/28 23:22, 6F

01/28 23:54, , 7F
請問程式碼要去哪看呀? 0. 0a
01/28 23:54, 7F

01/29 00:05, , 8F
用Minecraft Coder Pack decompile
01/29 00:05, 8F

01/29 01:21, , 9F
看別人寫的程式是種痛苦
01/29 01:21, 9F

01/29 02:14, , 10F
不過最少mcp decompile還蠻好懂得 如果是自己寫的
01/29 02:14, 10F

01/29 02:14, , 11F
可能幾天後自己都看不懂了
01/29 02:14, 11F

01/29 09:14, , 12F
痛苦 可是是最精準的
01/29 09:14, 12F

01/29 09:17, , 13F
因為都寫死在那邊了咩 總比亂猜準 w
01/29 09:17, 13F
※ 編輯: volition 來自: 61.64.69.53 (01/30 10:51)

01/30 10:53, , 14F
避免誤解,所以把方塊修改成方格
01/30 10:53, 14F
文章代碼(AID): #1H1dhhSY (Minecraft)
文章代碼(AID): #1H1dhhSY (Minecraft)