生態插件補丁

mineflayer 生態插件在 bedboo 上無需修改即可運行，只有 patches/ 中的少量 pnpm patch（patches/mineflayer-*.patch） 例外。本頁說明每個補丁改了什麼、為什麼改，並記錄這些插件在 Bedrock 上與 Java 表現不同之處（以及有用的變通做法）。推薦用法見 插件。觀測環境為 BDS 1.26.51.1（協議 2193）。

mineflayer-pathfinder 2.4.5 補丁

• 影響： Movements、bot.pathfinder.bestHarvestTool、goto、stop、路徑執行器（monitorMovement、fullStop、 postProcessPath）；以及基於它構建的一切（mineflayer-collectblock、mineflayer-pvp、mineflayer-tool 的箱子取工具）
• Java： 方塊名集合使用 Java 名稱；門會被挖穿（只有柵欄門能打開，上游默認關閉 canOpenDoors）；fullStop() 通過移動 bot.entity.position 讓 bot 重新居中（“服務器察覺不到差別”）；挖掘成本來自 prismarine-block 的 block.digTime，使用 工具簡化後的 NBT。
• Bedrock： 方塊名稱不同（flowing_water / flowing_lava 是獨立的方塊，web、wooden_door、fence_gate、 standing_sign、lit_furnace……——lib/interactable.json 只認識 Java 名稱）；服務器權威的移動會糾正客戶端對位置的任何 改動（重新居中會使每次搭橋產生 3–4 次 0.16–0.64 格的糾正，見 搭路）；Bedrock 物品把附魔保存在 ench 中（數字 id），且 BDS 使用 Bedrock 的急迫 / 挖掘疲勞係數（挖掘速度）。
• bedboo（補丁，新文件 lib/bedrock.js + 若干修改）：
  • 名稱：flowing_water / flowing_lava 加入 liquids 和 replaceables，flowing_lava 加入 blocksToAvoid； 充滿水的方塊（seagrass、kelp、bubble_column……）和含水方塊算作液體，後處理的路徑會在其中居中（反向移植上游 master #384）；interactable.json 加入 156 個可交互方塊的 Bedrock 名稱（與 lib/bedrock/placement.js 同一集合）， 因此 pathfinder 對著它們放置前也會潛行（潛行放置）；
  • 門和柵欄門：openable 除柵欄門外還包含可徒手打開的門（wooden_door、spruce_door……、銅門；鐵門除外）；啟用 canOpenDoors 時，關著的門會變成一次 useOne 點擊（門的上半部分不會被挖掉），開著的門 / 柵欄門（open_bit，Java 中為 open）可以通過，且不會再被點擊；門口節點取地面中心，useOne 節點不再中止路徑後處理（反向移植 master #372）； 點擊後執行器繼續行走（上游會讓 placing 保持置位，隨後讀取 undefined 的 placingBlock.y，或因缺少搭路方塊而重置路徑）。 BDS 只打開門的下半部分（上半部分的 open_bit 保持為 0）：上半部分由 bedboo 的 blockAt() 賦予打開門板的形狀 （門的兩半），因此 bot 能穿過自己打開的門走回來，而不是找不到路徑或把門挖掉；
  • fullStop() 保留上游清零水平速度的做法，但當 bot 有 bot._bedrock.physics（服務器權威移動）時跳過重新居中的瞬移。 實測：pathfinder 搭橋 0 次糾正（原為 3–4 次）；偶爾在 BDS 不接受清零速度時最多出現一次約 0.24 格的糾正（只鬆開按鍵 會讓 bot 漂出目標方塊）；
  • 挖掘成本（bestHarvestTool、safeOrBreak）：使用 item.enchants（Java 的 Enchantments 和 Bedrock 的 ench 都適用；簡化後的 NBT 中是 id，prismarine-block 從未匹配上），以及存在時使用 bot._bedrock.digging.blockDigTime （Bedrock 效果係數；否則使用 prismarine-block 的 digTime）；
  • 反向移植 master #375：空閒時調用 stop() 不再被鎖存（以前它會停掉下一個目標），goto 在搜索失敗且結果為空時以 NoPath reject，而不是 resolve。mineflayer-collectblock 的 cancelTask() 依賴這個鎖存（它在挖掘期間 pathfinder 空閒時 調用 stop()）：它的補丁現在自己處理取消（mineflayer-collectblock）；
  • lib/passableEntities.json 也列出了可穿過實體的 Bedrock 名稱（xp_orb、xp_bottle、splash_potion、 lingering_potion、fireworks_rocket、thrown_trident、fishing_hook、evocation_fang、wind_charge_projectile、 breeze_wind_charge_projectile、ender_crystal、eye_of_ender_signal、ominous_item_spawner、 wither_skull_dangerous）：只有 Java 名稱時，經驗球和彈射物被當成障礙物（產生實體成本，經驗球所在處不會墊高或搭路）；
  • detectDiggingStopped 只移除它自己的監聽器（removeAllListeners(event, fn) 會忽略 fn，把 bot 上所有其他 diggingCompleted / diggingAborted 監聽器都刪掉）；
  • 當 bot 被推離其已完成路徑的計算起點超過一格時，動態目標（GoalFollow）會重新規劃（骷髏的箭把一個 mineflayer-pvp bot 永久推出了攻擊範圍：目標本身移動的距離還不足以讓 hasChanged() 成立）；
  • 放置失敗不再讓路徑卡死（上游 2.4.5 和 master d773d15 都會卡死——master 中未合併的 PR #365 只是移動了無效判斷；任何 服務器都一樣，包括 Java）：
    • 上游：搭路方塊的 bot.equip 被拒絕後，lockEquipItem 永遠不會釋放，執行器在每個 tick 都在無效判斷之前提前返回， 再也恢復不了；被拒絕的放置會把路徑重置到同一個放置上，無限循環；stop() 等待一個永遠不會到來的節點或重置；
    • 現在裝備鎖從裝備開始一直持有到放置結束，並在任何結果下都會釋放；
    • 失敗的裝備 / 放置 / 開門點擊（equip_error、place_error、use_error），或耗時超過 placeTimeout（10 s， place_timeout）的操作，會計入對應格子：失敗次數超過 maxPlaceRetries（1）的格子會加入 bot.pathfinder.refusedPlacements，在當前目標下 Movements#getNeighbors 不會再在這些格子上規劃放置（再次設置同一個 目標對象——即調用方的重試——會保留它們；設置其他目標或 stop() 會清空）；
    • 連續 maxPlaceFailures（6）次失敗則放棄目標（path_update 'noPath'，goto 以 NoPath "… placements failed in a row" reject；除非是動態目標，否則該目標會被丟棄，之後的重置也不會讓它復活）；
    • 放置過程中的 stop() 在下一個 tick 結束；被 stop / 重置 / 新目標放棄的放置即使遲遲結束也不會改變任何東西（也不會 釋放更新的放置所持有的鎖）；放置後走回 returnPos 的過程與走向節點一樣有時限；
    • 失敗後 bot 會退回到它探出身子時所站的方塊上；當 bot 向下取整後的位置位於空隙上方時，搜索從 bot 所站的方塊開始（上游從 空隙上方的格子開始，並計劃對著其下方的空氣放置——在橋邊停下後，下一次 goto 會在這上面耗費 2 × 10 s）。

長距離搜索與部分路徑

• 影響： mineflayer-pathfinder 對 100 格以外、跨越山丘的目標執行 goto()（Java 上相同）
• Java / Bedrock： 上游行為相同：goto(GoalLookAtBlock(<90 格外的矿石>)) 以 "Took to long to decide path to goal!" reject——goto 在搜索狀態為 timeout 時就 reject，而不是沿最佳部分路徑行進；儘管 pathfinder 隨後確實會走這條部分路徑， 但走到盡頭後不會重新規劃。
• bedboo： 庫和補丁都未做改動。變通做法（倉庫自帶的 agent packages/agent 即如此）：把遠距離目標拆成每段 32 格分段行走 （GoalNearXZ 路點，某段失敗時改走側向 16 格的一段），thinkTimeout 設為 10 s；超時後等待部分路徑走完，再從那裡重新搜索； bot 30 s 沒有移動就放棄。1×1 墊高需要 bot 在所在列中居中（碰撞箱與相鄰列重疊時，跳躍會碰到那一列的天花板）：每次跳躍前 先讓 bot 居中。

穿過剛放置的門出去時找不到路徑

• 影響： bot 放置一扇木門且保持連接後，緊接著使用的 mineflayer-pathfinder（已打補丁，canOpenDoors）
• Java： 未觀察到。
• Bedrock（已觀察到，原因不明）： 一個從屋內放置了房門的 bot 對屋外的所有目標都得到 NoPath；重新加入後，pathfinder 打開了同一扇門並走了出去。bot 看到的門方塊狀態是正確的（下半部分的 open_bit、上半部分的 upper_block_bit，重新加入後 也一樣），所以原因不在世界模型；未進一步調查。
• bedboo： 未修復。變通做法：從建築佔地範圍之外放置門，並顯式地穿過門離開已完成的建築（activateBlock + 行走）；被卡住 時，打開相鄰的關著的門並穿過去。

mineflayer-pathfinder 掉進岩漿

• 影響： 在下界使用 mineflayer-pathfinder 默認設置的任何人
• Java / Bedrock： 上游行為相同：Movements.infiniteLiquidDropdownDistance（默認 true）允許路徑從任意高度落入 “液體”，而 pathfinder 的液體包括岩漿——一條下界路徑讓 bot 掉進了岩漿海（實測：在 y 26 探索時出現 "<bot> tried to swim in lava"）。
• bedboo： 庫和補丁都未做改動。變通做法：設置 infiniteLiquidDropdownDistance = false（下落限制為 maxDropDown 3）， 並把傳送門、火、岩漿塊、漿果叢……加入 blocksToAvoid。

在天花板下墊高（1×1 塔）

• 影響： mineflayer-pathfinder 的 allow1by1towers
• Java： pathfinder 跳起並在腳下放置方塊；它只清除腳上方兩格的方塊。只要客戶端聲稱自己升起了，Java 服務器就接受放置； 客戶端會自己在柱子上重新居中。
• Bedrock： BDS 拒絕與玩家服務器端碰撞箱重疊的任何方塊（搭路），而打過補丁的 pathfinder 不再 讓 bot 重新居中（那會導致糾正）。偏離中心的碰撞箱會跨到相鄰的列；那裡腳上方兩三格的方塊（例如末地島嶼在其抵達平臺上方的 底面）會截斷跳躍，每次放置都會被拒絕（實測：連續 204 次 place_error 路徑重置，bot 卡在 3 格高的柱子上）。
• bedboo： 庫未做改動。變通做法：在天花板很近的地方，去掉那些九列中任意一列在腳上方 2–3 格有方塊的墊高步驟，讓 pathfinder 改為挖出階梯（末地平臺 → 島頂約 25 s）。其他地方墊高正常（把自己挖進 1×1 豎井的 bot 會居中，能正常墊高出來）。

在下界岩漿海上搭橋

• 影響： 下界中 mineflayer-pathfinder 的搭路
• Java / Bedrock： 相同：岩漿海上的橋很危險（疣豬獸的頂撞或弩箭會把 bot 打進岩漿）。
• bedboo： 庫未做改動。變通做法：在下界，不在落差超過 4 格的地方放置搭路方塊；讓 pathfinder 改為挖穿岩石。

mineflayer-tool 1.2.0 補丁

• 影響： bot.tool.getDigTime、equipForBlock、retrieveTools 的成本排序
• Java： block.digTime(type, …, nbt.simplify(item.nbt).Enchantments, effects)。
• Bedrock： 附魔是帶數字 id 的 ench NBT；使用 Bedrock 效果係數（挖掘速度）。
• bedboo（補丁）： 使用 item.enchants + bot._bedrock.digging.blockDigTime（否則使用 prismarine-block）——估算值等於 手持該工具時的 bot.digTime，因此效率附魔會讓帶附魔的工具被選中。
  • 修復的上游 bug（與 Bedrock 無關）：物品欄中沒有可採集工具時，equipForBlock(block, { requireHarvest, getFromChest }) 會調用 retrieveTools()，而它在沒有箱子（或沒有箱子裡有工具）時不報錯直接返回，隨後 equipForBlock 再次調用自己—— 無限循環。沒有箱子時這是一條無盡的微任務鏈：事件循環被凍結，進程在約 25 s 內因內存耗盡而崩潰（例如沒有鎬時用 mineflayer-collectblock 的 collect() 採集煤礦石；它的選項是 { requireHarvest: true, getFromChest: true, maxTools: 2 }）。补丁只在有箱子时才搜索箱子，且只搜索一轮；否则（或仍然没有工具时）调用以 NoItem reject，與不帶 getFromChest 時一樣。

mineflayer-collectblock 1.6.0 補丁

• 影響： bot.collectBlock.collect(target, [options], cb)（回調形式）、它拾取的掉落物、cancelTask()
• Java / Bedrock： 兩邊存在相同的上游 bug：
  • callbackify(this.collect) 丟失了 this，因此回調形式（mineflayer 的 examples/collectblock.js）總是以 "Cannot read properties of undefined (reading 'bot')" 失敗；
  • 被挖方塊的掉落物生成在每個軸上距方塊 0.25–0.75 的隨機位置（再減去物品高度的一半）：距方塊中心最遠約 0.52 格（BDS 上 實測：0.17–0.52）。collectblock 只把距中心 0.5 以內的掉落物作為目標，因此偶爾會漏掉一個掉落物（Java 的分佈相同）；
  • 輪到某個目標方塊時它已經不存在了（mineflayer-pathfinder 會挖掉擋路的東西，例如在跟隨某根原木的掉落物時挖掉了它上方的 原木），這時會得到一個指向空氣的 GoalLookAtBlock，它永遠不會結束：搜索會跑到 5 s 超時，collect() reject（實測：採集 5 根原木的 4 次運行中有 2 次）；
  • cancelTask() 調用 bot.pathfinder.stop() 並等待任務結束。在 pathfinder 2.4.5 中，pathfinder 空閒時（挖掘期間、等待 拾取時）的 stop 會被鎖存，因此任務的下一次 goto 以 PathStopped reject，而 collect() 會吞掉這個錯誤。打過補丁的 pathfinder 不再鎖存（mineflayer-pathfinder）：取消因此丟失，cancelTask() 要等整個任務做完（實測：4 根 原木 17 s）。
• bedboo（補丁）： callbackify(this.collect).call(this, …)；採集距被挖方塊中心 0.75 以內的掉落物；在尋路前丟棄已經變化的 方塊目標；cancelTask() 還會給正在運行的任務設置標誌，任務在每一步（goto、挖掘、等待拾取、清空物品欄）之後檢查該標誌， 並像以前一樣以 PathStopped 結束——在當前步驟完成之後，與 pathfinder 2.4.5 時一樣——等待拾取則會立即結束。其他部分未打 補丁：挖掘等待服務器（完成），掉落物來自 itemDrop → GoalFollow → playerCollect / entityGone，箱子流程照常使用 openChest / deposit。

礦石搜索使用區塊數據

• 影響： 用 bot.findBlocks 查找礦石（mineflayer-collectblock 的示例也是這樣做的）
• Java / Bedrock： 相同——服務器發送完整區塊，bot 用 bot.findBlocks 定位方塊。
• bedboo： 無需改動。在下界採礦時值得了解的事實：
  • 遠古殘骸的 y 8–22 區間（大礦脈，約在 y 15）大多位於岩漿海（y ≤ 31）之下：那裡的目標常常處在開闊洞穴之下， mineflayer-pathfinder 會搭橋、墊高穿過虛空去夠它們，或者 bot 掉進岩漿。更好的做法是先在岩漿海之上搜索（y ≥ 32，小礦脈 所在處），要求殘骸被岩石包裹到 bot 所在高度（上方沒有開闊洞穴或岩漿），再退而求其次搜索 8–22 區間或挖一條直的分支礦道；
  • 尋路去礦石時，絕不破壞與液體相鄰的方塊；
  • 開採下界金礦會激怒看到這一幕的豬靈，無論是否穿著金甲（之後持弩的豬靈會一直射擊 bot）：最後再開採，且絕不在距豬靈 20 格 以內開採。

mineflayer-armor-manager 2.0.1 補丁

• 影響： playerCollect 時的自動裝備
• Java： 每件拾取的盔甲在 100 ms 後開始 equipItem；由於 Java 的窗口點擊是即時的，這些裝備操作很少重疊。
• Bedrock： 每次點擊都要等待服務器的物品堆疊響應，因此一起拾取的多件盔甲會同時裝備；它們的點擊通過共享的光標交錯進行， 把盔甲互相換來換去（實測：5 件中只有 1 件最終被裝備上）。
• bedboo（補丁）： 裝備操作依次執行（一個 promise 隊列）。getDroppedItem() 以及 Java 的盔甲槽 5–8 / 副手 45 可直接 使用；supportFeature('doesntHaveOffHandSlot') 為 false。

mineflayer-auto-eat 5.0.3 補丁

• 影響： bot.autoEat.eat()、enableAuto()
• Java： 一次進食以 bot._client 上的 entity_status 9 結束。
• Bedrock： 沒有 entity_status 數據包；BDS 向進食者發送 completed_using_item（也就是 bot.consume 等待的東西）。
• bedboo（補丁）： 進食監聽器在收到 completed_using_item 時也會完成。該插件只提供 ESM（用 await import('mineflayer-auto-eat') 加載）；registry.foods / foodsByName 來自 bedrock-data；它的 GPL-3.0 依賴 @nxg-org/mineflayer-util-plugin 原樣使用（它需要 Java 版本比較（版本比較）、 bot.version.split('.')、clickWindow、inventory.selectedItem、firstEmptyInventorySlot）。只有在簡單或更高難度下 飢餓值才會下降（和平模式下 Bedrock 永遠不會讓飢餓值下降）。
  • 修復的上游 bug（與 Bedrock 無關）：
    1. eat() 在裝備食物之前就設置進食標誌，而只在進食開始之後的路徑上清除它：裝備失敗（customEquip → false，例如同時 有窗口打開或正在換手）會讓 isEating 永遠為 true——之後每次 eat() 都拋出 Already eating!，自動模式再也不會進食 （詳情）。現在進食開始前的任何失敗（沒有食物、裝備、激活物品）都會清除該標誌；這樣的失敗仍然不觸發 任何事件（進食並未開始），與上游一致。
    2. 啟用 strictErrors（默認）時，失敗的進食（超時、物品被換走、cancelEat()）會在觸發 eatFail 之前就拋出，因此默認 選項下從不會觸發失敗事件；現在先觸發 eatFail（然後 eatFinish，然後 reject），與 strictErrors: false 時一樣。 每次失敗只觸發一次 eatFail：自己用 eat() 拋出的錯誤觸發它的代碼（針對缺失事件的變通做法）不會把一次失敗報告兩次。
  • 對無法開始的進食，自動模式在 2 s 後重試（否則失敗的裝備會在每個 tick 重複），對已失敗的進食則立即重試，與上游一致； 直接調用的 eat() 永遠不會被延後。拋出異常的 eatStart 監聽器也不會再讓標誌保持置位（該事件在進食的 try 中觸發）。

mineflayer-auto-eat 在生命值 < 14 時總是進食

• 影響： mineflayer-auto-eat 5.0.3 的 minHealth（默認 14），Java 和 Bedrock 都一樣
• Java： 同樣的選項；對普通食物而言，飽食度滿時因低生命值觸發的進食同樣是徒勞的循環。
• Bedrock： 飽食度滿的玩家無法進食（BDS 拒絕這次進食），因此僅由低生命值觸發的自動進食會每個 tick 開始一次永遠完成不了的 進食（每次 3 s 超時）。
• bedboo： 未打補丁。推薦選項：minHealth: 0、minHunger: 16（只按飢餓值進食）。

mineflayer-auto-eat 在裝備被拒後停止進食

• 影響： mineflayer-auto-eat 5.0.3 的 eat() / 其自動模式（Java 上代碼相同）
• Java / Bedrock： 相同的上游 bug：eat() 在裝備食物之前設置“正在進食”標誌，只在進食開始之後的路徑上清除它；裝備拋出 異常（其他代碼或戰鬥同時在換手、有窗口打開）會讓標誌保持置位，自動模式（physicsTick → if (!_eating) eat()）再也不會 重試（觀察到：一個 bot 在飢餓值 5、物品欄裡有 5 份熟食的情況下持續了好幾分鐘都沒進食）。
• bedboo： 已在 mineflayer-auto-eat 補丁 中修復：進食開始前的失敗會清除該標誌。作為最後手段，把“進行中” 超過 15 s 的進食重置掉仍是一個合理的安全網。

mineflayer-auto-eat 與 pathfinder 爭奪手持物品

• 影響： 啟用 mineflayer-auto-eat、在飢餓時挖掘或放置的 bot
• Java / Bedrock： 上游行為相同。只要飢餓值低於 minHunger 且攜帶可食用物品，auto-eat 就會在任意物理 tick 開始進食 （裝備食物並按住“使用”）；手持物品一變，它就以 "Item switched early" 放棄這次進食。mineflayer-pathfinder 挖掘時裝備工具、 放置時裝備方塊——下一個 tick auto-eat 又裝備回食物。路徑需要挖掘或放置方塊的飢餓 bot 兩樣都做不成（實測：一個 bot 在岩漿池 旁站了 12 分鐘，飢餓值 4，攜帶九塊腐肉，每次行走都超時）。
• bedboo： 未打補丁。變通做法：在需要挖掘或放置的任務之前，先停下來進食（pathfinder 停止時調用 auto-eat 自己的 eat()）；不要把正在進行的進食當作中斷而無限重試；給重試和搜索加上時間上限。

mineflayer-pvp 1.3.2 補丁、盾牌與攻擊時機

• 影響： bot.pvp（對苦力怕舉盾、盾牌使用、攻擊時機、followRange）
• Java： 正在引爆的苦力怕是元數據索引 16 = 1；用 activateItem(true) 舉盾；攻擊頻率遵循 Java 的武器冷卻。
• Bedrock： 正在引爆的苦力怕帶有 ignited 實體標誌；舉盾靠潛行（沒有使用動作，見 物品使用、進食與盾牌）；沒有攻擊冷卻。
• bedboo（補丁）： checkExplosion 也會讀取 metadata.flags.ignited（實測：該標誌會被設置，pvp 會舉盾）。未打補丁的 部分：
  • activateItem(true) / deactivateItem() 按住 / 鬆開潛行，因此持盾時 bot 在兩次攻擊之間以潛行速度移動；這個潛行屬於 盾牌本身，所以 pathfinder 的 clearControlStates()（每次追擊結束時、挖掘或放置前、stop() 時）不會把盾放下；
  • Java 的冷卻時機只是讓攻擊比 Bedrock 允許的略慢一點；
  • 默認 followRange 為 2 時，邊射擊邊後退的骷髏會保持在 4 格之外（GoalFollow 只在目標移動超過該範圍時才重新規劃；Java 上也一樣）：對付遠程生物請使用 bot.pvp.followRange = 1；
  • pvp 監聽的是 physicTick（mineflayer 會打印其棄用警告，與 Java 上一樣）。

運行插件時發現的核心修復

• 影響： bot.stopDigging、bot.creative.flyTo、bot.waitForChunksToLoad
• Java： 不適用（插件所依賴的庫行為）。
• Bedrock： 插件觸及了基本 API 調用不會觸及的時序。
• bedboo：
  • lib/plugins/digging.js：blockUpdate 監聽器先於挖掘自己的按位置監聽器運行；mineflayer-pathfinder 在路徑附近有任何變化 時都會停止挖掘，因此 pathfinder 的每次挖掘都以 diggingAborted（"Digging aborted"）結束，儘管方塊其實已被破壞。現在在 方塊已被破壞時調用 stopDigging 會像上游一樣完成這次挖掘（上游的 finishDigging 在本地更新之前就清除了 targetDigBlock）。新增 bot._bedrock.digging.blockDigTime(block, type, creative, inWater, notOnGround, enchantments, effects)（prismarine-block 的簽名，Bedrock 係數），供插件做成本估算。
  • lib/plugins/physics.js：創造模式 flyTo 規劃器在鬆開前進鍵後 10 tick 內絕不再次按下（BDS 在雙擊前進後會衝刺飛行）， 在連續的 flyTo 調用之間保留跳躍保護，並且當目的地高於落點時絕不會提前落地（玩家一接觸地面 BDS 就停止飛行）；見 飛行。
  • waitForChunksToLoad：在瞬移後立即於 "loaded" 時調用會超時，因為 BDS 在加入時發送的區塊列（超出其公佈的 publisher 半徑的部分）被卸載後再也不會重發；lib/plugins/blocks.js 現在會保留它們。

移植的 mineflayer 示例

• 影響： 庫的 examples/ 目錄
• Java： mineflayer 4.39.0 的 examples/（require('mineflayer')）。
• bedboo： 移植了 51 個示例文件，改為 require('bedboo')，其餘完全相同（其中硬編碼的 Java 物品 / 方塊名稱保持不變：例如 fisherman 的 fish、graffiti 的 sign 都不是 Bedrock 名稱——也不是新版 Java 名稱）。auto-eat.js 改用固定版本的 mineflayer-auto-eat 5 API（ESM import()、setOpts、enableAuto / disableAuto、eatStart / eatFinish），上游的示例 早於該 API。未移植：session.js（Java 啟動器配置文件認證）、discord.js / telegram.js（第三方機器人，沒有 Bedrock 特有 內容）、perfectShotBow.js（minecrafthawkeye，Java）、viewer/、screenshot-with-node-canvas-webgl/ （prismarine-viewer：Java 區塊）、anvil_saver/（Java Anvil 世界文件）、python/。需要 Bedrock 行為的示例：
  • BDS 拒絕玩家執行 /op；請通過服務器控制台授予 op（op 命令）；
  • bee.js（創造模式 flyTo）在 Bedrock 上是真正在飛：它的 11 段短距離飛行耗時約 15.5 s，而不是約 3 s （飛行）；
  • inventory.js：equip off-hand 只接受副手物品（例如箭），不接受泥土（副手）。