mineflayer
mineflayer copied to clipboard
Incorrect local block information.
This is a refactor of the following issues
- https://github.com/andrewrk/mineflayer/issues/140
- https://github.com/andrewrk/mineflayer/issues/133
- https://github.com/andrewrk/mineflayer/issues/97
Currently a summary of the issues stand as:
- [ ] Falling blocks such as gravel and sand do not cause correct updates
- [x] Special cases where blocks are formed such as a cobblestone generator cause issue
- [ ] Explosions that cause a sudden amount of blocks to disappear do not work
Thinks to keep in mind
- [x] Single block updates need to be tested as working
- [ ] Multiblock updates need to be tested as working
- [ ] Confirm crops growing and fire damage work
- [x] Confirm that metadata updates work fine, a good example would be redstone
Need to test what part of this are still relevant (what works and what doesn't).
my recent experience is that breaking a door triggers a bug in mineflayer where the bot doesn't know the door is gone. the common theme seems to indicate that there's a multiblock update packet that we're not handling correctly.
@thejoshwolfe how do you test that ? I just tried to put a door between the bot and me and use forward in jumper.js, the bot correctly can't pass the door, when I destroy the door, it's able to come.
that's about what I did. I'll see if I can get a more controlled scenario to reproduce the problem.
falling blocks are entities (see http://minecraft.gamepedia.com/Data_values/Entity_IDs)
Confirm that metadata updates work fine, a good example would be redstone
This seems to make it impossible to dig redstone currently.
So, I agree all these edge cases should be handled, but it hasn't been handled until now : it is not more broken now than it was before. So I'm postponing this for the next milestone/release.
pretty sure it's related to https://github.com/andrewrk/mineflayer/issues/266 (so that means part of that is fixed ?)
see https://github.com/andrewrk/mineflayer/commit/9ee9e49c3aaa5ac04690fd57cdd55c46488b568d
I just fixed multiblock update having incorrect location in #266.
Might be nice to check if that somehow fixed explosion block update.
(imho this issue is way to big, it was better as multiple issues, but well that's how it is...)
redstone fixed
As of today, on server us.skyparty.me, digging in a cobblestone genny works exactly once for each block in the genny, and then the bot sees nothing but air, despite the blocks coming back after a short amount of time.
IS there any way to add a workaround for now? Like manually a dig.changeto.js.txt dding some kind of bot.on("packetnamehere") to manually set the block when the bot gets a block update packet?
Included is the code used for the digging
You need to wait for the block to come back before digging again.
See https://github.com/PrismarineJS/mineflayer/blob/master/doc/api.md#blockupdatex-y-z-oldblock-newblock
I'm encountering what I think is this bug when a sapling grows into a tree. The bot can't find the logs, and also tries to pathfind through them using the pathfinder
plugin. I guess, short of an actual bugfix, is there any way to force a sync between the bot and the server's world states?
There is no way except reconnecting. Feel free to look into whether there is a bug though. If you can reliably reproduce it with a minimal example that would be a good first step
On Wed, Jul 27, 2022, 02:05 jabaldwin @.***> wrote:
I'm encountering what I think is this bug when a sapling grows into a tree. The bot can't find the logs, and also tries to pathfind through them using the pathfinder plugin. I guess, short of an actual bugfix, is there any way to force a sync between the bot and the server's world states?
— Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/mineflayer/issues/178#issuecomment-1196113388, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437WH34IDOIEX6BUJGNTVWB4LJANCNFSM4AOQ7TBQ . You are receiving this because you commented.Message ID: @.***>
I did a little more experimenting and my problem seems to have been due to #2708 . The NPM command on that issue fixed it