-
Notifications
You must be signed in to change notification settings - Fork 14
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
Block mining updates #11
Comments
This probably requires GH-10 Client positioning, since the server won't let clients mine any arbitrary block (must be within a certain radius?) |
I think the radius is 6 blocks. |
yup, from http://wiki.vg/Protocol#Player_Digging:
for now, testing with /tp webuser-1 player to position the web client where it can legitimately mine blocks. mineflayer has a digging API: https://github.com/andrewrk/mineflayer/blob/427eb934e0ccb391f7af01e3186a65be57fd10c7/lib/plugins/digging.js#L13 - implements dig(block,cb) and stopDigging(), experimenting with forwarding from voxel-reach 'stop mining' / 'stop mining' events. |
Added showing server-side block destroy animations (from other players) as of 26891ae, some progress on client block digging. Calling from voxel-reach start mining event: self.digStart = function(event) {
var block = self.bot.blockAt(vec3Object(event.position[0], event.position[1], event.position[2]));
if (!block) return;
self.bot.dig(block, function(err) {
console.log('dig:',err);
}); but the digging is interrupted: start mining Object {voxel: Array[3], adjacent: Array[3], side: "top", sub: Array[2], normal: Array[3]…} |
Updating voxel-use for usedBlock event
sounds like you are doing something before digging is over (it takes some time) |
Yeah I have my own logic on the client-side for block 'hardness' = mining time, I think it is shorter than the server expects which may be causing these conflicts. |
if you need that time, you may want to use that function https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/digging.js#L91 |
Since have changed to use mineflayer dig() API: self.digStart = function(event) {
var block = self.bot.blockAt(vec3Object(event.position[0], event.position[1], event.position[2]));
if (!block) return;
self.bot.dig(block, function(err) {
console.log('dig:',err);
}); I think this was working in ~1.8.3, but am encountering issues with 1.8.9 (after the nmp 0.16 update + various other updates #16), the client looks like it continues digging: the client (voxel.js side) logs start mining / stop mining events and shows the (client-side) block break animation, but something wrong with the interaction with mineflayer digging |
start/stop mining (voxel.js, or more specifically voxel-mine events) is seemingly triggered repeatedly - this is for holding down the left mouse button once:
|
Actually this works (able to mine blocks, pickup the item drops, and place blocks), the failure I was seeing was caused by the client being located in the spawn area and not having permission to mine (fixed by /op webuser-1). Still could handle this failure case better. |
Mining is implement as: start mining, causes mineflayer to dig(), which itself handles continuously mining until the block is broken. So you only need to tap left-click once on a block, and it will be mined (after waiting a while). Should really switch to lower-level API, maybe using packets directly, to properly translate the start/stop mining events to MC. |
http://wiki.vg/Protocol#Player_Digging packet: 0=started digging, 1=canceled, 2=finished mineflayer digging: https://github.com/PrismarineJS/mineflayer/blob/master/lib/plugins/digging.js - sends block_dig with status=0 (start digging), arm_animation every 350 ms (seems to go on too long? at least here), then block_dig with status=2 (finished) after waiting block digTime |
Bugs in current implementation (unclear if in mineflayer or voxel-clientmc): arm swings continuously, sometimes hits PrismarineJS/mineflayer#305 TypeError: Cannot read property 'position' of null in lib/plugins/digging.js:72 location: bot.targetDigBlock.position |
Since block mining updates are sent, closing this issue as written, but new issue for improving the behavior: #51 |
Send mined blocks to the server
The text was updated successfully, but these errors were encountered: