mineflayer icon indicating copy to clipboard operation
mineflayer copied to clipboard

Bot digging 2 times when using a tool in 1.21.4

Open ErneTalu opened this issue 8 months ago • 2 comments

  • [x] The FAQ doesn't contain a resolution to my issue

Versions

  • mineflayer: 4.26
  • server: vanilla / 1.21.4
  • node: v20.16.0

Detailed description of a problem

When the bot mines a block with tool, it cancels digging at block's last health. Then the bot starts breaking again, but very slowly, as if it were using its hand. But there's nothing wrong if it's just use is hand, it breaks normally.

What did you try yet?

I tried all of pickaxes to stone , axe to wood and shovel to dirt. But all restarted digging again instead of hand

Your current code


/*
const Vec3 = require('vec3');

module.exports = function (bot, owner) {
  return {
    start: () => {
      dig(bot);
    }
  }
};

async function dig(bot)
{
  let blockPosition = bot.entity.position.offset(0, -1, 0);
  let block = bot.blockAt(blockPosition);

  let promise = bot.dig(block);
  await promise;
  bot.chat("Dug.");
}

*/


Expected behavior

Block should be break normally once with tools

Additional context

Forget about module exports, they have no relevance about this error

ErneTalu avatar Mar 23 '25 20:03 ErneTalu

Now I tried it with 1.16.5 and it works well. But 1.21.4 dig is broke rn

ErneTalu avatar Mar 24 '25 17:03 ErneTalu

I have the same bug. It is broken on 1.21.4 too and works fine on 1.16.5

0leg2281337 avatar Mar 26 '25 14:03 0leg2281337

I also encountered this issue (at Minecraft version 1.21.4). After testing different Minecraft versions, I found it works fine in 1.20.4 but breaks starting from 1.20.5 .

I observed that when digging a block, cracks appear but don't complete the digging process, then the cracks suddenly disappear. It appears as if you're digging halfway and then release the left mouse button.

After waiting for a period of time, the block gets destroyed without showing any cracks.

My speculation is that although the client correctly calculates the digging time, it sends the finish signal too early, causing the server to stop the crack animation prematurely.

However, the server's calculation of block destruction and crack animation display are handled by different threads, so the block continues to be destroyed at the normal time.

I'm not familiar with Minecraft's source code, so it's difficult for me to investigate the real root cause. I hope this issue can be fixed as soon as possible. Thanks to all the project maintainers for their efforts!

ChangingSelf avatar Sep 12 '25 14:09 ChangingSelf

What is the tool and can you provide the code to replicate ? This maybe fixed when we port over some logic to proper modern tag system

Ref https://github.com/PrismarineJS/minecraft-data-generator/issues/55

extremeheat avatar Sep 13 '25 21:09 extremeheat

What is the tool and can you provide the code to replicate ? This maybe fixed when we port over some logic to proper modern tag system这个工具是什么,你能提供代码来复现吗?这可能在我们将一些逻辑移植到现代标签系统后得到修复

Ref PrismarineJS/minecraft-data-generator#55

I initially discovered it in this project maicraft-mcp-server (Minecraft 1.21.4 Fabric Server on linux; mineflayer v4.30.0; node v18.18.0),and I recreated a small demo to reproduce this issue (Minecraft 1.21.4 Fabric local client with LAN on windows 11;The latest mineflayer v4.33.0; node v18.18.0):

const mineflayer = require('mineflayer')

const bot = mineflayer.createBot({
  host: 'localhost',
  username: 'demoBot',
  port: 25565,
  auth: 'offline',
})

bot.on('chat', async (username, message) => {
  console.log(`<${username}> ${message}`)
  if (message.toLowerCase() === 'dig') {
    await bot.chat('start test dig...')
    let blockPosition = bot.entity.position.offset(0, -1, 0);
    let block = bot.blockAt(blockPosition);
    if (block) {
      await bot.dig(block);
    }
    await bot.chat('end test dig...')
  }
})

Below is a video I recorded using this demo. Initially discovered on copper_ore, blocks like stone that existed in earlier versions don't seem to have this issue, or perhaps their hardness values aren't that high.

https://github.com/user-attachments/assets/53139c3c-e6fe-40a2-9c0e-698b64651581

ChangingSelf avatar Sep 14 '25 00:09 ChangingSelf

bump

kotleni avatar Oct 05 '25 13:10 kotleni

bumping this

mcgamer48ft avatar Oct 12 '25 12:10 mcgamer48ft