挖掘與放置

本頁說明 bot.dig、bot.placeBlock、bot.placeEntity 以及對方塊使用物品在 Bedrock 上如何工作——在 Bedrock 上， 方塊的破壞和放置都由服務器自己完成。觀測環境為 BDS 1.26.51.1（協議 2193，bedrock-protocol 3.60.1）。

服務器權威的方塊破壞

• 影響： bot.dig、bot.stopDigging、diggingCompleted、diggingAborted、bot.targetDigBlock
• Java： 客戶端發送 block_dig 開始（status 0），自己等待 digTime 毫秒，發送完成（status 2）並在本地把方塊設為空氣； 取消 = status 1。
• Bedrock： BDS 上 start_game.server_authoritative_block_breaking 為 true。方塊操作隨 player_auth_input.block_action 發送（每 tick 一個輸入）。實測行為：
  • start_break = 在方塊上按下鼠標。從這個輸入開始，BDS 每 tick 自己累加破壞進度——開始的那個 tick 也算——使用的是 它自己那份手持物品、狀態效果、是否著地和眼睛是否在水中的狀態；只要保持破壞狀態，它就會在進度達到 1 的那個輸入中 破壞方塊（含開始輸入在內的第 ceil(1/speed) 個輸入），不需要任何其他操作。它會向所有觀察者報告速度（先 level_event block_start_break，然後每 tick 一個 block_break_speed，data = 每 tick 進度 × 65535，向下取整）， 以 update_block（空氣）+ particle_destroy 報告破壞，隨後是掉落物（add_item_entity）。
  • predict_break（客戶端的“已經破壞”）從同一個輸入起才被接受；早一個輸入發送時，BDS 會回一個恢復該方塊的 update_block（而若破壞仍在保持，它仍會在下一 tick 破壞方塊）。
  • continue_break 會讓 BDS 重新開始破壞：每發送一次，它都會向所有觀察者發送 block_stop_break + block_start_break （其他玩家看到的裂紋動畫和 mineflayer 的 blockBreakProgressObserved 每 tick 都會重新開始）。crack_break 被接受，但不改變任何東西。
  • abort_break 結束破壞。stop_break 不會：一次破壞完成後，BDS 會繼續“按住”該位置，並自行破壞隨後放到那裡的下一個 方塊（即使是 /setblock 放置的）。
  • 面和視線方向都不被校驗（任意麵、看向別處、距離最遠約 7 格，都能破壞）。
  • 創造模式：僅 start_break 就會瞬間破壞（無掉落物）；僅發送 player_action creative_player_destroy_block 沒有任何 效果。
• bedboo： 在轉向之後的輸入中發送 start_break，保持破壞期間不發送任何東西；當 BDS 自己每 tick 的進度報告 （block_break_speed）顯示還差一個 tick 就完成時發送 predict_break——也就是在客戶端和服務器同步運行時，恰好在 BDS 完成破壞的那個輸入中（實測為 BDS 接受的最早輸入）；服務器落後時會更晚，但絕不提前。純客戶端的 tick 計數不夠：在負載較高 的主機上，BDS 會落後於客戶端的輸入計數並恢復方塊。BDS 不發送進度報告時，bedboo 使用自己的計數並留一個 tick 的餘量。
  • 以服務器的 update_block（空氣；含水方塊 / 冰則為液體）作為完成標誌，隨後發送 abort_break 釋放破壞狀態；攜帶它的輸入 發出後（≤ 1 tick）dig 才結束，因此調用方接下來做的任何事——在該位置放置方塊、繼續挖掘——都會在釋放之後才到達 BDS （實測：否則在 update 之後立即執行的 /setblock 會再次被 BDS 破壞）。
  • 創造模式和瞬間破壞（第一個 tick 進度 ≥ 1）：start_break + predict_break 放在同一個輸入中。
  • stopDigging / 新的挖掘 / 死亡 / 切換維度：abort_break。
  • 當 BDS 報告的被挖方塊速度與本地估算不同時，以前者替換後者，因此不一致永遠不會導致客戶端提前預測。
  • 保留上游每 350 ms 揮一次手（animate）的行為。
  • 舊式（非服務器權威）服務器：發送 start_break，每 tick 發送 crack_break，在 digTime 之後發送 stop_break + 一個 inventory_transaction break_block，並像上游一樣在本地預測方塊被破壞。BDS 始終是服務器權威的，因此無法用它測試這條路徑。

dig() 在服務器確認後完成

• 影響： bot.dig（promise 何時結束）、diggingCompleted、bot.lastDigTime
• Java： 客戶端自己的 digTime 計時器觸發時 promise resolve（方塊在本地設為空氣）。
• Bedrock： 方塊由服務器破壞；客戶端自行設為空氣只是一種猜測，服務器可能會推翻它。
• bedboo： dig 在服務器的 update_block 之後 resolve（並以空氣方塊觸發 diggingCompleted）：它在開始輸入之後 digTime − 1 tick + 往返延遲到達（在本地 BDS 上對 848 次計時挖掘的實測：相對 digTime 中位數 −21 ms，範圍 −75…+44 ms），挖掘隨釋放輸入最多晚一個 tick 結束（見 服務器權威的方塊破壞）。
  • BDS 會在大約一個 tick 內多次發送被破壞方塊的 update_block（破壞本身，以及對 predict_break / abort_break 的應答）： 等待該位置“下一次更新”的代碼應先讓這些更新過去。
  • “已破壞” = 空氣、液體（含水方塊、海帶、珊瑚扇和冰會留下水；靈魂沙 / 岩漿塊上方的氣泡柱），或少了一個蛋的海龜蛋。
  • 如果在 predict_break 之後 40 tick 內服務器都沒有任何破壞該方塊的跡象（沒有更新、沒有速度報告——仍在破壞時 BDS 每 tick 都會報告速度；例如冒險模式、受保護的方塊或教育版方塊），則像 stopDigging 一樣中止挖掘（diggingAborted， reject 信息為 Digging aborted: the server did not break <name> at <pos>）；上游無論如何都會 resolve。
  • 斷開連接也會 reject 正在進行的挖掘（Digging aborted: the connection ended；上游的計時器會讓它 resolve）。
  • bot._bedrock.digging（內部）保存最近幾次挖掘的診斷信息（開始 / 結束時間、tick 數、BDS 報告的速度、恢復次數）。

挖掘速度：Bedrock 的狀態效果係數

• 影響： bot.digTime，以及被 mineflayer-pathfinder / mineflayer-tool 直接調用的 block.digTime(...) （prismarine-block）
• Java： 急迫和潮湧能量把速度乘以 1 + 0.2 × level；挖掘疲勞乘以 0.3 / 0.09 / 0.0027 / 0.00081（等級 1–4+）。
• Bedrock（實測，level_event 數據）： 急迫 / 潮湧能量（取較高等級）乘以 (1 + 0.2 × level) × 1.2^level （I 1.44、II 2.016、III 2.7648、V 4.9766）；挖掘疲勞乘以 0.21^level（= 0.3^level × 0.7^level：I 0.21、 II 0.0441、III 0.0093、IV 0.0019、V 0.0004）。其餘部分都與 Java 公式相同，並已在 BDS 上驗證：各材質的工具倍率（來自 Bedrock 數據，包括金 12 和銅 5）、不能採集的工具其等級仍會提速（木鎬挖鐵礦石）、效率 level² + 1 僅在工具倍率大於 1 時 生效、頭盔上的水下速掘、眼睛在水中 ÷5、不在地面 ÷5（兩者同時：÷25）、canHarvest ? 30 : 100、硬度 0 = 瞬間破壞 （BDS 報告 65535 = 1.0）、ceil(1/speed) 個 tick。
• bedboo： bot.digTime 使用 lib/bedrock/dig_speed.js（結構與 prismarine-block 的 digTime 相同，但使用 Bedrock 的效果係數；沒有這些效果時，對每種方塊 × 工具 × 水中 / 空中 / 附魔組合，結果都與 prismarine-block 相同）。 prismarine-block 自己的 block.digTime 保留 Java 的效果係數（未打補丁）：在急迫或挖掘疲勞下調用它的插件成本估算會偏差 這些係數（挖掘本身是正確的，因為它等待服務器）。打過補丁的 mineflayer-pathfinder 和 mineflayer-tool 改用 bot._bedrock.digging.blockDigTime（見 mineflayer-pathfinder、 mineflayer-tool）。對每種可挖掘方塊，BDS 報告的速度都等於 bot.digTime。

創造模式：劍、三叉戟和重錘不能破壞方塊

• 影響： 創造模式下的 bot.digTime、bot.dig
• Java： 創造模式下所有方塊的 digTime 都為 0（Java 創造模式玩家同樣不能用劍破壞方塊；上游忽略這一點，服務器會恢復 方塊）。
• Bedrock（實測）： 創造模式玩家手持任意劍、三叉戟或重錘破壞方塊時，BDS 會恢復方塊；長矛、工具、其他物品和空手都能 瞬間破壞。
• bedboo： 在創造模式下手持這些物品時 digTime 為 Infinity，因此 dig 會立即以上游的 dig time for <name> is Infinity reject，而不是等待服務器。

眼部水體包括含水方塊

• 影響： bot.digTime、bot._getBlockAtEyeLevel（未改動）
• Java： 當眼部方塊是 water / flowing_water 時，上游認為眼睛在水下。
• Bedrock： 水也可能是方塊的第二層（含水方塊、海帶、海草）。
• bedboo： 眼部方塊為 water、flowing_water，或第 1 層為水的方塊（block.isWaterlogged）時眼睛在水下。不使用 bot.entity.isInWater（與上游相同）。眼睛在水下時挖掘耗時為 5 倍，BDS 的結果與此一致。

'auto' 挖掘面

• 影響： bot.targetDigFace、方塊操作所帶的面
• Java： dig(block) 在 digFace 為 'auto' 時看向方塊中心併發送面 1（頂面）。
• Bedrock： BDS 不校驗面，但原版客戶端發送的是準星下的面，而且這個面決定了其他玩家看到的敲擊粒子。
• bedboo： 'auto'（帶轉向）使用從眼睛到方塊中心的視線進入方塊時穿過的那個面（例如 bot 與方塊同高且位於其西側時為 4 = 西）。面向量、'raycast' 和 forceLook: 'ignore'（面 1）沿用上游。

工具耐久

• 影響： 挖掘後 bot.heldItem 的耐久、heldItemChanged
• Java： 服務器扣減工具耐久併發送 set_slot。
• Bedrock： 原版客戶端會在 predict_break 中附帶一個 item_stack_request mine_block { 快捷欄槽位、預測耐久、 stack id }；BDS 只在破壞完成的那個輸入中接受它（晚一個輸入就回復 status: error），然後在響應的 durability_correction 中報告耐久，而不是發送槽位。沒有這個請求時，BDS 自己扣減工具耐久，併發送帶新 Damage 的 inventory_slot。
• bedboo： 不發送 mine_block 請求（只有在服務器同步運行時，預測才會落在完成的那個輸入中，見 服務器權威的方塊破壞）；物品欄模型應用服務器的 inventory_slot（每個方塊 Damage +1，耗盡時工具消失， heldItemChanged 與 Java 的 set_slot 一致）。

挖掘空氣

• 影響： bot.dig(air)、bot.digTime(air)、registry.blocksByName.air.hardness
• Java： 空氣硬度為 0：digTime 為 0，dig 立即 resolve 並觸發 diggingCompleted。
• Bedrock： minecraft-data PR #1335 和 BDS 自己導出的方塊數據都把空氣硬度設為 -1（不可破壞）。
• bedboo： 數據覆蓋層把空氣硬度設為 0（packages/bedrock-data/scripts/tables.js BLOCK_FIXES），因此 digTime(air) 與上游一樣為 0。對世界中為空氣的方塊執行 bot.dig（包括一個已不存在的方塊的過期 Block 對象——例如門的 另一半）會立即以 diggingCompleted(air) 完成，不發送任何東西（BDS 從不報告破壞空氣）。若過期的空氣 Block 所在位置現在 已有方塊，則正常挖掘。

無法佈置或挖掘的方塊

• 影響： 整個方塊註冊表範圍內的 bot.dig、bot.digTime

• Java： 每種可挖掘的 Java 方塊都可以放置並挖掘（少數除外）。

• Bedrock： 註冊表中有 1,442 種可挖掘方塊。在 BDS 1.26.51.1 上，其中約 230 種無法放進生存模式的測試世界，或永遠不會被 破壞：

  • /setblock 拒絕的 id：教育版的 element_*、化合物和硬化玻璃，unknown / info_update / reserved6 等內部 id， 以及 BDS 1.26.51.1 不認識的 *_concrete_double_slab / *_wool_double_slab 狀態；
  • 設置後無法留在原處的方塊（珊瑚壁扇、絆線鉤、靈魂火、氣泡柱……）；
  • frosted_ice（挖掘過程中會融化）；
  • 教育版的 allow / deny / border_block（BDS 在生存模式下從不破壞它們）。

  默認朝下的附著類方塊（按鈕、物品展示框、旗幟、拉桿）只有設置在地面上（facing_direction 1）或牆上時才能留下。挖掘後 “消失” = 空氣或液體（冰、海帶、海草、珊瑚扇和海泡菜會留下水）。

• bedboo： 其餘每種方塊都在生存模式下用下列工具中最快的一種挖掘過：下界合金鎬 / 斧 / 鍬 / 鋤和剪刀（效率 V）、下界合金劍 以及空手：BDS 報告的速度均等於 bot.digTime，且 BDS 從未恢復過被挖掘的方塊。

瞬間破壞之後的進度報告

• 影響： bot._bedrock.digging.last.serverSpeedData（診斷信息）
• Java： 無對應情況（客戶端自己為挖掘計時）。
• Bedrock： 瞬間破壞之後，BDS 可能會報告取代該方塊之物的破壞進度（水源中的植物被破壞後留下的水，例如 short_dry_grass）——有時出現在破壞的 update_block 之前的那一批數據包中。
• bedboo： 瞬間破壞（開始和預測在同一個輸入中）只把瞬間級別的報告（每 tick ≥ 1：被挖方塊自己的報告）作為服務器速度； 更慢的報告只算作服務器活動。

放置協議：用 start/stop_item_use_on 包裹的 click_block

• 影響： bot._genericPlace、bot.placeBlock、bot._placeBlockWithOptions、bot.placeEntity、blockPlaced
• Java： block_place（位置、方向、手、光標位置）；無論是否放置了東西，服務器都會先為被點擊的方塊、再為面對面的方塊 回覆 block_change。
• Bedrock： 與原版客戶端一樣，點擊方塊的一個面依次為 player_action start_item_use_on（被點擊方塊、被點擊方塊 + 面、 面）→ inventory_transaction item_use click_block（手持物品在服務器上的精確副本，包括其 stack id、被點擊方塊的 runtime id、面上的點擊點、面、快捷欄槽位、手、位於眼睛高度的玩家位置、預測 success）→ 150 ms 後的 player_action stop_item_use_on（被點擊方塊 + 面）。實測應答（本地約 80–120 ms）：先是物品欄（所有窗口的 inventory_content：使用後的數量、耐久或新的 stack id），然後是一串 update_block——被點擊方塊、面對面的方塊、被點擊方塊 的下方鄰居、再次是面對面的方塊、它的上方鄰居、再次是被點擊方塊——約 20 ms 後目標位置再更新一次，並帶有 place 音效。 被拒絕時（有實體擋路、玩家自己的碰撞箱、物品不是方塊、超出世界）收到同樣的一串更新，但目標位置不變（外加一個 set_entity_data 重同步），物品欄也不變。
• bedboo： bot.placeBlock / bot._placeBlockWithOptions 是上游代碼（原樣內置）；bot._genericPlace / bot.placeEntity 保留上游的檢查、選項、轉向和事件。應答的形式與 Java 相同（先是參考方塊，再是目標位置），因此上游的 place_block.js 及其錯誤信息都無需修改（Server refused to place <item> at <pos>: the block is still <name>、 Server did not answer the placement at …、must be holding an item to place）。點擊一進入隊列 _genericPlace 就 resolve（上游：緊接在 block_place 之後）；一次點擊的 stop 會在下一次點擊的 start 之前發送（成對的操作不會交錯）。 與上游一樣，客戶端不預測放置：方塊隨服務器的更新出現。

對可交互方塊潛行放置

• 影響： bot._genericPlace 以及基於它的一切（placeBlock、placeEntity；mineflayer-pathfinder）
• Java： mineflayer 不會告訴服務器自己在潛行（generic_place.js 中的 “TODO”）；mineflayer-pathfinder 會針對它的 interactable.json（Java 名稱）自己按下潛行。
• Bedrock： 除非玩家在潛行，否則 BDS 會執行被點擊方塊的使用動作（打開箱子 / 工作臺 / 熔爐、開關門、打開告示牌編輯器……） 而不是放置；潛行按鍵隨 player_auth_input 發送，服務器必須在處理點擊之前已處理該輸入（提前一個輸入就足夠； set_entity_data 的 sneaking 即為確認）。飛行中的玩家永遠不會進入 sneaking 狀態，但輸入中的原始潛行按鍵仍然有效。
• bedboo： 當參考方塊可交互時（lib/bedrock/placement.js 的 isInteractive，Bedrock 名稱：容器、工作站、除鐵質外的 門 / 活板門 / 柵欄門、按鈕、拉桿、中繼器、比較器、告示牌、床、蛋糕、物品展示框……），_genericPlace 會按住潛行控制， 等它隨一個輸入發出（有 bot._bedrock.physics.controlsSent() 時用它，否則等下一個發出的輸入）並得到服務器確認（飛行時 不等確認），然後點擊，再鬆開它自己按下的潛行（調用方按住的潛行會保留，例如 mineflayer-pathfinder 的）。騎乘時不按任何鍵 （在 Bedrock 上潛行會下坐騎）。飛行時 bot 可能在那個 tick 內略微下降（潛行 = 下降）。這樣在生存模式下可以放置到箱子、 工作臺、熔爐、木門、站立告示牌或木桶的上面，在創造飛行中也可以對著箱子放置。

放置會等待服務器對上一次點擊的應答

• 影響： bot.placeBlock、bot._placeBlockWithOptions、bot.placeEntity，以及使用桶和船的 bot.activateItem—— 多個同時進行或緊挨著執行時
• Java： block_place 不攜帶物品：進行中的放置不會相互失效。
• Bedrock： 每次點擊都攜帶手持物品在服務器上的精確副本；每次使用後 BDS 都會給該堆疊分配新的 stack id（在它的 update_block 應答之前的 inventory_content 中），並拒絕帶舊 id 的點擊（實測：兩次放置相隔 0–30 ms → 第二次被拒絕）。
• bedboo： 點擊在放置器中串行化（lib/bedrock/placement.js）：下一次點擊要等手持物品已更新、被點擊方塊已得到應答，或 500 ms 之後才發出。依次 await 的放置（例如 mineflayer-pathfinder）從不需要等待；對多個放置使用 Promise.all 會把它們 全部放下。在某次放置尚未得到應答時發起的桶 / 船使用（activateItem → 所看向的方塊）會保留其目標和快捷欄槽位，並在其後 發出。其他物品使用（activateBlock、activateItem 的 click_air）不串行化：在放置後不 await 就立即發起時，它們仍可能 攜帶舊的 stack id。

帶有過期方塊狀態的點擊會重試

• 影響： 對服務器剛剛改變過的方塊執行 bot.placeBlock / _placeBlockWithOptions
• Java： block_place 不攜帶方塊狀態。
• Bedrock： 點擊攜帶被點擊方塊的 runtime id，BDS 會拒絕 id 與它自己對該方塊的狀態不一致的點擊。某些方塊會在相鄰方塊 更新後一個 tick 才被 BDS 改變（耕地和土徑在其上放置方塊後會變成泥土，發生在放置應答之後 50–90 ms），因此緊接著對它們的 下一次點擊會被拒絕。
• bedboo： 點擊的應答會透露服務器上被點擊方塊的狀態；若被拒絕的點擊攜帶的是另一個狀態，就用方塊當前的狀態重試一次 （generic_place.js 中對內置 place_block.js 的包裝）。其他拒絕與上游一樣 reject。改變了被點擊方塊本身的點擊絕不會被 當作過期點擊：對著可替換方塊（snow_layer、short_grass、fern、vine、seagrass……）或手持物品可以合併進去的方塊 （同種半磚 → 雙層半磚，再加一根蠟燭 / 一個海泡菜 / 一層雪 / 一片花瓣，蠟燭插到蛋糕上）點擊時，BDS 會把方塊放到被點擊的 位置，面對面的方塊保持不變——與 Java 完全相同，因此調用在一次點擊後就以上游的 Server refused reject（而不是再點一次、 在其上方放下第二個方塊）；用掉了物品的點擊也同樣不會被當作過期點擊。

手持堆疊在服務器上已變化的點擊會重試

• 影響： 在拾取物品、被給予物品（/give）或手持堆疊以其他方式增加期間執行的 bot.placeBlock / _placeBlockWithOptions（先挖後放的循環、mineflayer-pathfinder 的搭路）
• Java： block_place 不攜帶物品。
• Bedrock： 點擊攜帶手持物品在服務器上的精確副本（其 stack id）。若在點擊發出到被處理之間有拾取合併進手持堆疊，該堆疊會 先得到新的 stack id（inventory_transaction normal，然後 inventory_content），BDS 會拒絕這次點擊（實測：先挖後放的 循環中 180 次放置有 4 次；在點擊前剛執行 /give：每次都會）。
• bedboo： 放置器會記錄點擊與其應答之間手持槽位在服務器端的變化（該槽位的 inventory_transaction，或堆疊變多）； 這樣的拒絕會用服務器的副本重試一次（此時客戶端已拿到該副本）。其他拒絕與上游一樣 reject。

墊高與搭橋（mineflayer-pathfinder 搭路）

• 影響： bot._genericPlace（跳躍放置）、mineflayer-pathfinder 的 allow1by1towers 和搭橋

• Java： pathfinder 跳起，腳一離地就在腳下調用 placeBlock；點擊被拒絕會重置路徑（place_error）並重試。

• Bedrock： BDS 會拒絕與玩家服務器端碰撞箱相交的任何方塊（實測：重疊 0.01 格也會被拒絕；不會有方塊被放進玩家體內， 因此也沒有推出）。它在處理點擊之前先處理此前發出的玩家輸入，所以點擊必須跟在一個碰撞箱已離開目標位置的輸入之後。

• bedboo： 當 bot 正從目標方塊中升起，或一直在跳（按住跳躍控制）時，點擊會等待（≤ 20 個輸入）第一個碰撞箱已離開該方塊 的輸入，並緊隨其後發出；不會離開的 bot 會立即點擊，並像上游一樣收到服務器的拒絕。實測（生存模式、有重力、本地 BDS）：

  • 手動墊高 ×4（腳一離地就放置）：0 次拒絕，0 次糾正；
  • pathfinder 墊高 ×5：0 次 place_error，0 次糾正（每格約 0.45 s，點擊在腳離地後 2 tick 發出）；
  • 手動搭橋 ×4（潛行後退到邊緣，對著下方方塊的側面放置）：0 次糾正；
  • pathfinder 搭橋 ×5–6：未打補丁時有 3–4 次 0.16–0.64 格的糾正，全部來自 pathfinder 自己的 fullStop()，它在客戶端把 bot.entity.position 移到方塊中心（在 Java 上“服務器察覺不到差別”；服務器權威的 BDS 會察覺：它把 bot 糾正回去，然後 bot 繼續走）。打過補丁的 pathfinder 會跳過這次居中：0 次糾正（見 mineflayer-pathfinder）。

  在天花板下墊高另有限制：見 1×1 塔。

不能從副手放置

• 影響： bot._genericPlace / bot._placeBlockWithOptions / bot._placeEntityWithOptions 的 offhand 選項
• Java： hand: 1 放置副手物品。
• Bedrock： 副手只能放少數物品（盾牌、圖騰、箭、煙花火箭、地圖……，見 副手），玩家也從不對方塊 使用副手；用 hand: off_hand 和副手物品（或主手物品）點擊什麼都不會放置（實測，用 /replaceitem 強行把方塊放進副手）。
• bedboo： 按原版客戶端的方式發送點擊（手為 off_hand，帶副手的線上物品），服務器拒絕，placeBlock 以上游的拒絕信息 reject；保留上游對空副手的檢查。

placeEntity

• 影響： bot.placeEntity、bot._placeEntityWithOptions、entityPlaced
• Java： 點擊方塊（block_place）；船還額外發送 use_item（服務器沿視線做射線檢測）；在目標位置 2 格（船為 3 格）內按 名稱查找實體（EnderCrystal / end_crystal、boat、armor_stand、刷怪蛋對應的生物）；不支持礦車（斷言 'Unimplemented'）。
• Bedrock： 一切都是對方塊的點擊：盔甲架、末影水晶（黑曜石 / 基岩）、刷怪蛋、礦車（放在鐵軌上）和船（BDS 忽略船的 click_air；原版客戶端點擊它所瞄準的水；船也可以放在陸地上）。實體名稱：ender_crystal、boat / chest_boat （運輸船、竹筏）、armor_stand、minecart / chest_minecart / ……，刷怪蛋 villager → villager_v2、 zombie_villager → zombie_villager_v2、evoker → evocation_illager、tropical_fish → tropicalfish。和平模式下 敵對生物的刷怪蛋什麼也不會生成（蛋仍會被消耗）。
• bedboo： 使用上游代碼，另外：
  • 參考方塊為液體時，船會點擊液體的頂面（無論給出的是哪個面，船都會在其上居中生成；視線方向無關緊要，所以船永遠不會落在 bot 身上）；
  • 接受礦車（放在鐵軌上），運輸船也可以放在陸地上；
  • 使用上述 Bedrock 名稱；
  • 上游在第一個 entitySpawn 之後就停止監聽，即使那是另一個實體（之後總是在 5 s 後超時）；這裡的監聽會一直保留，直到所 放置的實體生成或超時（'Failed to place entity'，未改動）。

對方塊使用物品：桶、打火石、骨粉、煙花

• 影響： 使用這些物品時的 bot.placeBlock / bot.activateBlock / bot.activateItem
• Java： activateItem（use_item）對玩家看向的方塊使用桶或船（服務器射線檢測）；手持桶、打火石或骨粉的 placeBlock / activateBlock 作用於被點擊的方塊。
• Bedrock： BDS 會忽略桶和船的 click_air（實測：什麼也不發生）；原版客戶端點擊所看向的方塊（click_block：空桶點擊 液體源本身，裝滿的桶點擊液體後面的實心方塊，液體出現在面的另一側）。用打火石 click_block 會點火（黑曜石框架變成 portal 方塊），骨粉催熟被點擊的植物，對方塊使用煙花火箭會發射它；與 Java 一樣，未滑翔時在空中使用火箭沒有效果。
• bedboo： 手持水桶 / 岩漿桶的 placeBlock 以 blockPlaced(air, water|lava) resolve，手持打火石時以 blockPlaced(air, fire|portal) resolve；手持空桶執行 activateBlock(<液体源>) 會裝滿它。手持桶或船的 bot.activateItem 會調用 bot._bedrock.placement.useOnLookedAtBlock(item, offHand)，即這種使用在 Bedrock 上的形式：沿視線做射線檢測 （在物品可作用的地方包括液體），然後點擊。其他物品使用見 物品使用、進食與盾牌。