Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bot.dig doesn't fail even if physically impossible #3494

Open
1 task done
tabbry opened this issue Oct 31, 2024 · 2 comments
Open
1 task done

bot.dig doesn't fail even if physically impossible #3494

tabbry opened this issue Oct 31, 2024 · 2 comments
Labels
possible bug Stage1 just created by someone new to the project, we don't know yet if it deserves an implementation / a f

Comments

@tabbry
Copy link

tabbry commented Oct 31, 2024

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

Versions

  • mineflayer: 4.22.0
  • server: vanilla 1.20.6
  • node: 20.13.1

Detailed description of a problem

Invoking dig on the bot for a block, even when not physically possible, triggers the mining animation. However the "mining-texture" is not visible (expected), the block doesn't break (expected) and the digging command completes as if it was successful (unexpected).

Cases where this happens:

  • Block is within spawn protected area, defined by server properties. Example: spawn-protection=16
  • Bot is in game mode which doesn't allow it to break blocks: (spectator and usually adventure)

What did you try yet?

Using the examples/digger.js to isolate the problem and invoke dig for a block within and outside the spawn protected area.

Your current code

bot.dig(block).then(() => {
    // Invoked, even if not really successful.
    this.bot.chat(`Successfully digged block`)
}).catch(err => {
    // Not invoked, despite the fact that it was not successful.
    this.bot.chat(`Digging aborted block`)
})

Expected behavior

When digging fails (no matter the circumstances), it should throw an exception and thus follow the catch path and it should trigger the diggingAborted event.

Additional context

  • Also applies to analogous use of try catch blocks.
  • Also applies to analogous use of bot.canDigBlock(block)
  • For spawn protection: Does not apply when the bot is in the op list, as this effectively ignores the spawn protection. (/op BOT to add the bot to op list, /deop BOT to remove.)
@tabbry tabbry added possible bug Stage1 just created by someone new to the project, we don't know yet if it deserves an implementation / a f labels Oct 31, 2024
@u9g
Copy link
Member

u9g commented Nov 11, 2024

We don't really have a way to know whether digs will fail unless we try and it just comes back after a few ticks to my knowledge.

@Pix3lPirat3
Copy link
Contributor

I am curious if listening for "Acknowledge Block Change" packet would work, however I'm not fully grasping what it is, maybe someone else could correct me if it wouldn't work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possible bug Stage1 just created by someone new to the project, we don't know yet if it deserves an implementation / a f
Projects
None yet
Development

No branches or pull requests

3 participants