prismarinejs / prismarine-block

Represent a minecraft block with its associated data

prismarine-block

Represent a minecraft block with its associated data

Usage

const registry = require('prismarine-registry')('1.8')
const Block = require('prismarine-block')(registry)

const stoneBlock = new Block(registry.blocksByName.stone, registry.biomesByName.plains, /* meta */ 0)

console.log(stoneBlock)

// can you harvest stone with an iron pickaxe?
console.log(stoneBlock.canHarvest(257))

// how many milliseconds does it takes in usual conditions? (on ground, not in water and not in creative mode)
console.log(stoneBlock.digTime(257))

API

See doc/API.md

History

1.17.1

• Export Block class declaration (#91) (thanks @IceTank)
• Bump standard from 16.0.4 to 17.1.0 (#83) (thanks @dependabot[bot])
• use nmd supportFeature (#60) (thanks @u9g)
• Add command gh workflow allowing to use release command in comments (#90) (thanks @rom1504)

1.17.0

• Support for multi-sided signs (thanks @PondWader)

1.16.3

• really

1.16.2

• correct

1.16.1

• fix mcdata dep

1.15.0

• Effect names were normalized
• Metadata to 0 by default

1.14.1

• Legacy version fixes

1.14.0

• Add .stateId, .fromProperties, .getProps for all versions

1.13.1

• Change blockEntity version handling

1.13.0

• Add sign block entity implementation

1.12.0

• Updated to support prismarine-registry. To use, instead of passing a string to prismarine-biome's default function export, pass an instance of prismarine-registry.
• block entity support

1.11.0

• support bedrock

1.10.3

• use normalized enchant rather than custom format (@u9g #41)

1.10.2

• remove debug code

1.10.1

• Fix ternary operator for bedrock name check

1.10.0

• 1.17.0 support (thanks @Archengius and @the9g)

1.9.0

• added block.getProperties() type definitions.
• added instant breaking support
• added Block.fromProperties() constructor.

1.8.0

• Efficiency fix on versions below 1.13

1.7.3

• Fix effectLevel not working in digTime. (@Naomi-alt)

1.7.2

• add testing for shapes, make it more robust to missing data

1.7.1

• fix canHarvest when no harvestTools required (thanks @Garfield100)

1.7.0

• Add getProperties (thanks @Karang)

1.6.0

• Add enchantments and effects to dig time computation (thanks @Karang)

1.5.1

• Make Block.fromStateId work for all versions

1.5.0

• Fix block metadata for 1.13+

1.4.0

• add block shapes (thanks @Karang)

1.3.0

• add typescript definitions (thanks @IdanHo)

1.2.0

• Prevent data from being shared to avoid conflicts across multiple versions (thanks @hornta)

1.1.1

• use the minStateId if passing the blockType

1.1.0

• add block state id feature (for >= 1.13)

1.0.1

• bump mcdata

1.0.0

• bump dependencies

0.1.0

• Import from mineflayer

prismarine-block's Issues

Blocks.fromProperties not always returns a Block

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
  }
}

effectLevel is not working

prismarine-block/index.js

Line 129 in a5171e6

const e = effects[effectsByName[effect]]

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

Add block dig time recalculation

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.

Get block stateId from properties (1.13+)

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)

loading multiple versions overriding each other

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

block.digTime() returns 0 on some blocks no matter with which tool.

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.

block.digTime function does not recognize netherite tools

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

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

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

Add block interaction shapes

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

Use correct mapping file to map variants to properties for all pre-flattening versions

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.

fromProperties fails on future/custom blocks

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)

block.digTime does not correctly handle Conduit Power status effect

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