While using mineflayer-pathfinder, i encountered a bug which is directly related to prismarine-block.

with some blocks block.digTime() returns 0, no matter which tool is used to check. currently i noticed this with 2 different blocks: copper_ore and smooth_basalt.

Steps to reproduce:

• place copper_ore or smooth_basalt in your world
• get the block with your bot: const block = bot.blockAt(new vec3(x, y, z), false)

function checkDigTime(block) {
    const inventory = bot.inventory.items()
    console.log(block.name+": ")
    for (const tool of inventory) {
        const digTime = block.digTime(tool ? tool.type : null, false, false, false, [], [])
        console.log(`digTime: ${digTime}, tool: ${tool.name}`)
    }
}

• use the above function to loop over each item/tool of the bots inventory
• no matter which tool/item, with copper_ore and smooth_basalt the digTime is 0

Output of running the function:

smooth_basalt: 
digTime: 0, tool: netherite_shovel
digTime: 0, tool: diamond_pickaxe
digTime: 0, tool: iron_pickaxe
digTime: 0, tool: golden_pickaxe
digTime: 0, tool: netherite_pickaxe
digTime: 0, tool: netherite_axe
digTime: 0, tool: stone_pickaxe
digTime: 0, tool: wooden_pickaxe


copper_ore: 
digTime: 0, tool: netherite_shovel
digTime: 0, tool: diamond_pickaxe
digTime: 0, tool: iron_pickaxe
digTime: 0, tool: golden_pickaxe
digTime: 0, tool: netherite_pickaxe
digTime: 0, tool: netherite_axe
digTime: 0, tool: stone_pickaxe
digTime: 0, tool: wooden_pickaxe

gold_ore:  (correct digTime's)
digTime: 15000, tool: netherite_shovel
digTime: 600, tool: diamond_pickaxe
digTime: 750, tool: iron_pickaxe
digTime: 1250, tool: golden_pickaxe
digTime: 500, tool: netherite_pickaxe
digTime: 15000, tool: netherite_axe
digTime: 3750, tool: stone_pickaxe
digTime: 7500, tool: wooden_pickaxe

There could be more blocks with digTime 0, but I could only find these 2 as of now.

In cases like working with staircases or half slabs, there are many times when it extremely useful to think of blocks in the form of their type and state properties. For example, if I wanted to get a top wooden oak half slab that is waterlogged, it's not very easy to determine what the state id I need is.

You can kind of work with this by iterating between the minStateId and maxStateId and checking against all the properties, but this is not ideal.

I recommend something along the lines of Block.fromProperties(typeId, properties, biomeId)

If I do this:

const Block1_12 = require("prismarine-block")("1.12");
const Block1_13 = require("prismarine-block")("1.13.2");
const Block1_14 = require("prismarine-block")("1.14.4");

and try to instantiate a Block1_12 it will fail since the 1.14 imlp. doesn't ship block data.

https://github.com/PrismarineJS/prismarine-block/blob/master/index.js#L6

When Conduit was introduced, new status effect appeared related to it.
According to MC code, it works exactly like Haste and game pretty much uses effect with higher amplifier
currently, conduit power will not be accounted for break speed buff

bot thinks that an unenchanted diamond pickaxe mines coal ore much faster than unenchanted netherite pickaxe. The function returns 15000 for the netherite pickaxe.

It's pretty common to have conditions for calculating dig time to be changed. The vanilla behavior is to just change the digging speed without resetting the digging progress, thus an event should be added.

For things like interactive clients (p viewer) this is super important. For example, when you dig down, the dig time is calculated taking into account the fact you are currently in the air but it doesn't get changed when you fall to the ground which makes digging time desync.

Hello,

I think that the effectLevel function is not working properly (at least in 1.16.1)

 function effectLevel (effect, effects) {
    const e = effects[effectsByName[effect]]
    return e ? e.amplifier : -1
  }

Content of effects (in my case) from
https://github.com/PrismarineJS/mineflayer/blob/8f729c2f00620b3277dcebd510e5c4b278413d32/lib/plugins/digging.js#L104 :

{
  '3': { id: 3, amplifier: 1, duration: 340 },
  '10': { id: 10, amplifier: 0, duration: 340 },
  '11': { id: 11, amplifier: 0, duration: 340 }
}

Content of effectsByName

{
  Speed: { id: 1, name: 'Speed', displayName: 'Speed', type: 'good' },
  Slowness: { id: 2, name: 'Slowness', displayName: 'Slowness', type: 'bad' },
  Haste: { id: 3, name: 'Haste', displayName: 'Haste', type: 'good' },
  MiningFatigue: {
    id: 4,
    name: 'MiningFatigue',
    displayName: 'Mining Fatigue',
    type: 'bad'
  },
  Strength: { id: 5, name: 'Strength', displayName: 'Strength', type: 'good' },
  InstantHealth: {
    id: 6,
    name: 'InstantHealth',
    displayName: 'Instant Health',
    type: 'good'
  },
......

effects[effectsByName[effect]] is equal to null. It needs the id of the effect.
The fix would be effects[effectsByName[effect].id]

function effectLevel (effect, effects) {
  const e = effects[effectsByName[effect].id]	
  return e ? e.amplifier : -1
}

Bye

In which version was it changed that affected the digging speed of 1.13 and slowed down the digging speed by 1.12.2?

As wiki says

Collision box is not present for all blocks, as all non-solid blocks such as grass, signs, button, lever and torch have no collision box.

however there should be a way to break / interact with these blocks eg from prismarine viewer. I think there should be added interactionShapes property

for PrismarineJS/prismarine-web-client#96

Blocks.fromProperties can return the raw data of a block instead of an instance of the class Block. There either should be an error or the block in the default state.

code (shortened):

static fromProperties (typeId, properties, biomeId) {
  const block = typeof typeId === 'string' ? registry.blocksByName[typeId] : registry.blocks[typeId]

  if (version.type === 'pc') {
    // ...
  } else if (version.type === 'bedrock') {
    // ... tries to find state id
    return block // should be error or instantce of Block
  }
}

Block.fromProperties errors when it encounters a block that is either custom or from a future version, seeing as bedrock is getting better support for custom blocks and they are in some capacity stable Is there either a way to register custom blocks so they can be deserialized or to have a default case for unknown blocks?

TypeError: Cannot read properties of undefined (reading 'minStateId')
    at Function.fromProperties (node_modules\prismarine-block\index.js:243:34)
    at SubChunk118.loadLocalPalette (node_modules\prismarine-chunk\src\bedrock\1.3\SubChunk.js:125:30)
    at SubChunk118.loadPalettedBlocks (node_modules\prismarine-chunk\src\bedrock\1.3\SubChunk.js:97:12)
    at SubChunk118.loadPalettedBlocks (node_modules\prismarine-chunk\src\bedrock\1.18\SubChunk.js:14:18)
    at SubChunk118.decode (node_modules\prismarine-chunk\src\bedrock\1.3\SubChunk.js:81:12)
    at Chunk.newSection (node_modules\prismarine-chunk\src\bedrock\common\CommonChunkColumn.js:182:9)
    at WorldProvider.readSubChunks (node_modules\bedrock-provider\js\disk\WorldProvider.js:57:24)
    at async WorldProvider.load (node_modules\bedrock-provider\js\disk\WorldProvider.js:157:28)
    at async WorldProvider.getChunk (node_modules\bedrock-provider\js\disk\WorldProvider.js:184:16)
    at async main (bundle.js:242:16)

As said in PrismarineJS/minecraft-data#771 (comment) the legacy.json returns incorrect mapping by design, the correct mappings should be used instead.

For example lever with the state 69:0:

• Current: https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/common/legacy.json#L450 - powered=false,facing=north,face=ceiling
• Actual pre-flattening (mc assets expects it): facing=down_x,powered=false, actual post flattening: powered=false,facing=west,face=ceiling
• Expected in mc assets: https://github.com/PrismarineJS/minecraft-assets/blob/2dfeab1968765370dae0d5563b6d220c7f2cf72b/data/1.12/blocks_states.json#L1816

as you can see legacy.json has incorrect block properties for 69:0 even for a post-flattening format. There are a couple of things that I've considered to solve this issue:

• use indexes from mc-assets block states to match the block state needed to render for a block variation. Sometimes it doesn't work correctly
• regenerate the mapping file so it uses old (pre-flattening format) and the mappings are correct
• regenerate the mapping file so it still uses new (post-flattening format) and the mappings are correct & use post-flattening block states & models for render - easier to do and I think this is preferable way since it will also make scripts & anything else that expects properties in post-flattening format work.