voxel-clientmc listens for and sends some protocol packets itself, but it really ought to only access the API in mineflayer, and have it have intimate knowledge about the packet protocol details. Some of the functionality is not exposed, so to resolve this new API would have to be written. To see the current raw packet usage, grep for _client:
mf-worker.js: self.bot._client.on('held_item_slot', function(packet) { // TODO: this really should be emitted in mineflayer
mf-worker.js: self.bot._client.on('resource_pack_send', function(packet) { // TODO: mineflayer api
mf-worker.js: self.bot._client.emit('connect');
mf-worker.js: self.bot._client.write('block_dig', {
mf-worker.js: self.bot._client.write('arm_animation', {
mf-worker.js: self.bot._client.write('block_dig', {
some functionality should live in voxel-clientmc first before it is developed & stable (such as: https://github.com/voxel/voxel-clientmc/issues/51 more control over digging), then can be PR'd to mineflayer once ready.
voxel-clientmc listens for and sends some protocol packets itself, but it really ought to only access the API in mineflayer, and have it have intimate knowledge about the packet protocol details. Some of the functionality is not exposed, so to resolve this new API would have to be written. To see the current raw packet usage, grep for _client:
some functionality should live in voxel-clientmc first before it is developed & stable (such as: https://github.com/voxel/voxel-clientmc/issues/51 more control over digging), then can be PR'd to mineflayer once ready.