prismarinejs / node-minecraft-data

Provide easy access to minecraft-data in node.js

node-minecraft-data

node-minecraft-data provides easy access to minecraft-data in node.js.

The objective of this module is to make easier to look for information in minecraft-data in node.

Features

This package allows the lookup of blocks, items, entities, etc. by name, id, etc., and for the easy lookup of other data.

Example

const minecraftData = require('minecraft-data')
// or for es6: import minecraftData from 'minecraft-data';

const mcData = minecraftData('1.19')

console.log(mcData.blocksByName['stone']) // Information for "Stone"
console.log(mcData.windows['minecraft:brewing_stand']) // Information for the "Brewing Stand" GUI
console.log(mcData.version) // Information about the current version
console.log(mcData.effectsByName['Haste']) // Information for the "Haste" effect

Documentation

• See doc/api.md
• See doc/history.md

node-minecraft-data's Issues

Typescript compilation error

Hello.

I'm using mineflayer with typescript and I'm getting this compilation error:

I also found out that changing this line:

node-minecraft-data/typings/generate-typings.js

Line 33 in 061cae0

typingString += 'export = MinecraftData'

to
typingString += 'export default MinecraftData'
should fix this.

`MinecraftData.IndexedData` misses `loginPacket` type while the value is there?

this code:

import getData from 'minecraft-data'

const data = getData('1.18.2')
console.log(data.loginPacket)

returns

{
  entityId: 227,
  isHardcore: false,
  gameMode: 0,
  previousGameMode: -1,
  worldNames: [
    'minecraft:overworld',
    'minecraft:the_nether',
    'minecraft:the_end'
  ],
  dimensionCodec: {
    type: 'compound',
    name: '',
    value: {
      'minecraft:dimension_type': [Object],
      'minecraft:worldgen/biome': [Object]
    }
  },
  dimension: {
    type: 'compound',
    name: '',
    value: {
      piglin_safe: [Object],
      natural: [Object],
      ambient_light: [Object],
      infiniburn: [Object],
      respawn_anchor_works: [Object],
      has_skylight: [Object],
      bed_works: [Object],
      effects: [Object],
      has_raids: [Object],
      logical_height: [Object],
      coordinate_scale: [Object],
      min_y: [Object],
      has_ceiling: [Object],
      ultrawarm: [Object],
      height: [Object]
    }
  },
  worldName: 'minecraft:overworld',
  hashedSeed: [ -480297713, -2128446749 ],
  maxPlayers: 20,
  viewDistance: 10,
  simulationDistance: 10,
  reducedDebugInfo: false,
  enableRespawnScreen: true,
  isDebug: false,
  isFlat: false
}

Yet typings miss the loginPacket and I get an error Property 'loginPacket' does not exist on type 'IndexedData'. trying to access it.

Recipe Schema Different from actual data

When you use the mcData.recipes[id] the data returned doesnt match the schema provided on the website.

For instance from what I can tell as of this moment, you cant get furnace recipes using mcdata.

Output from mcdata:
: Object {inShape: [[14, 14, 14], [null, 613, null], [null, 613, null]], result: Object {count: 1, id: 590}} 1: Object {inShape: [[963, 963, 963], [null, 613, null], [null, 613, null]], result: Object {count: 1, id: 590}}

Website Schema:

1.13 Release?

When is there going to be a 1.13 release for this package

`foodsByFoodPoints` and `foodsBySaturation` incorrect

foodsByFoodPoints and foodsBySaturation only show a single item with each point/saturation, not all options.

For example, foodsByFoodPoints[2] only returns:

{
  id: 1054,
  name: 'glow_berries',
  stackSize: 64,
  displayName: 'Glow Berries',
  foodPoints: 2,
  saturation: 0.4,
  effectiveQuality: 2.4,
  saturationRatio: 0.2
}

not all food with foodPoints of 2

Update to use minecraft-data for toMajor()

lib/loader.js currently gets the major version from the release version by splitting the string:

function toMajor(mcVersion)
{
  var parts=mcVersion.split(".");
  if(parts.size<=1)
    return null;
  mcVersion=parts.slice(0,2).join(".");
  return mcVersion;
}

This works for full releases, but snapshot versions can be said to resemble certain "major" versions, which won't be parsed here. Instead this mapping can be looked up using minecraft-data, after:

PrismarineJS/minecraft-data#92 Add protocol version data

protocolVersions.json array, "majorVersion" key

(may also want to keep toMajor() as a fallback)

Have a script to update mcdata and release

22:55 <rom1504> nmd-updater, it would just clone nmd, go in minecraft-data, git fetch, git checkout <the version of mcdata we're at>, npm patch, add stuff in the history.md, git commit, git push, git tag, npm publish

maybe in its own repo

kind of connected to PrismarineJS/minecraft-data-auto-updater#1

Index protocol.json

See PrismarineJS/node-minecraft-protocol#239

add to doc the new files from bedrock

Recipes type in index.d.ts are wrong

Actual type :
recipes: { [id: number]: Recipe; };

Should be :
recipes: { [id: number]: Recipe[]; };

Cannot read property 'minecraftVersion' of undefined

Seem to get this error when using https://github.com/PrismarineJS/node-minecraft-protocol

I don't really have any useful information except its happened 2-3 times?
Here is the project I am using it in, as you can see nice and simple - https://github.com/MinecraftCapes/minecraftcapes-auth

I have users from all version (1.7.10 - 1.17.1 Forge, Fabric, Vanilla) all joining the proxy.

/home/container/node_modules/minecraft-protocol/src/transforms/framing.js:67
          } else { throw e }
                   ^

TypeError: Cannot read property 'minecraftVersion' of undefined
    at toMajor (/home/container/node_modules/minecraft-data/index.js:66:27)
    at module.exports (/home/container/node_modules/minecraft-data/index.js:29:24)
    at Client.onHandshake (/home/container/node_modules/minecraft-protocol/src/server/handshake.js:12:36)
    at Object.onceWrapper (node:events:514:26)
    at Client.emit (node:events:394:28)
    at FullPacketParser.<anonymous> (/home/container/node_modules/minecraft-protocol/src/client.js:91:12)
    at FullPacketParser.emit (node:events:394:28)
    at addChunk (/home/container/node_modules/readable-stream/lib/_stream_readable.js:298:12)
    at readableAddChunk (/home/container/node_modules/readable-stream/lib/_stream_readable.js:280:11)
    at FullPacketParser.Readable.push (/home/container/node_modules/readable-stream/lib/_stream_readable.js:241:10)

Use minecraft-data as a submodule instead of a dependency

That would make minecraft-data more language independent and solve the confusing 2 version of minecraft-data in npm situation.

It would make it possible to have similar python-minecraft-data or languageX-minecraft-data repos providing easy access to minecraft data in languageX.

After update to 2.93.1 or above cant use require('minecraft-data')(XX)

Hello i'm using minecraft-data library in react application

I'm making a chest inventory viewer but after update the version 2.93.1 or above they stop of working

In the version 2.93.0 works perfect but after update 2.93.1+ seems the requires is changed

I have a simply component to load the minecraft-data

I'm rewiving the changes 2.93.0...2.93.1 but I don't see a significant changes

Note: this version works perfect in bot mineflayer based, only is not working from outside packages similar has react / javascript..

no byDisplayName index

i was hoping there would be a findItemOrBlockByDisplaName function :/

merge browser.js back in index.js

see PrismarineJS/mineflayer#356

versionsByProtocolVersion index (complement versionsByMinecraftVersion index for protocolVersions lookup)

f01605f added protocolVersions support with the versions array and versionsByMinecraftVersion index, but looking up the version data by a protocol version would be useful in some situations. Note that since protocol version has two namespaces (usesNetty: true and usesNetty: false), there is protocol version overlap, but this could be solved by using negative integers for usesNetty: false and usesNetty: true.

Proposed use case: related ot PrismarineJS/node-minecraft-protocol#330 Intra-release multi-protocol support. In node-minecraft-protocol, could allow the version options to be either:

• typeof version === 'integer': use a version by protocol version integer (versionsByProtocolVersion index)
• typeof version === 'string': use a version by minecraft release version string (versionsByMinecraftVersion index)

Both indexes would allow looking up majorVersion to map to the minecraft-data 'dataset' (1.8, 1.9...). The Minecraft release version string is more human-readable, suitable for custom client/app development, and the protocol version integer is more programmatically useful for automatically passing from the ping packet for PrismarineJS/node-minecraft-protocol#331 dynamic cross-protocol support.

This index could be used in #13 Update to use minecraft-data for toMajor(), so these would be equivalent:

   require('minecraft-data')('1.8.9')
   require('minecraft-data')(47)

(but accessing these indexes may require #14 Lookup protocol data at top-level of module?)

Modifying outgoing packets without changing node_modules?

I'm writing a bot and I need to modify every position packet (0x14 and 0x15 to be precise) but every way I found requires me to change code in node_modules (hell) and they all work half arsed and straight up don't with control state. Thank you in advance.

Not all blocks are there

Can't find any blocks like "smooth stone" and such. Says it was updated 3 days ago...

[Feature Request] Getting block tags

I want to know whether a block is a trapdoor. Minecraft uses tag #trapdoors to track all trapdoors.

Ref: https://minecraft.wiki/w/Tag

Fix GH action following GH action in ptemplate

export protocol.pds

node-minecraft-data in the browser

browserify doesn't support dynamic requires, so it's not possible to browserify node-minecraft-data.

It's necessary to find a good solution for this, so people can use modules that depend on this module in the browser.

Implement a method downloading resources at runtime

As the scale of Minecraft-Data increases, this can add unneeded size to the node_modules. It would be more efficient to download the required resources as needed at runtime.

This might be done via git, or curl'ing the raw github repo. This data can be cached for future runs, if desired.

publish compressed files ?

it would reduce the size of nmd package on disk
decompression cost at run time would probably be minimal

Provide data from minecraft jar

Something like node -e "var mcData=require('minecraft-data')('1.8'); mcData.extract();" would go in the readme.
See SpockBotMC/python-minecraft-data#8 for details

Related to PrismarineJS/minecraft-data#17

Do mineflayer's Block, Item, Recipe, RecipeItem and Biome classes belong here ?

They don't seem too specific to mineflayer, it might makes sense to put them here.

Could they be used by other projects ? for example in prismarine-server ? @wtfaremyinitials @roblabla what do you think ?

I'm talking about the block.js, item.js ,... files in https://github.com/andrewrk/mineflayer/tree/master/lib

Block instance in versions <1.13 missing properties minStateId, maxStateId and defaultState

Would adding more specific data be a valid pull request?

I was considering adding information such as item durability, block transparency, blast resistance...

So far I'm basically making pararell database where I keep any missing info I need as well as more API. But maybe merging the work would be more efficient.

Lookup protocol data at top-level of module, without specifying a dataset version?

The usage for looking up protocolVersions with node-minecraft-data seems to be slightly awkward, requiring calling the module with a supported version:

> require('minecraft-data')('1.8.9').versionsByMinecraftVersion['1.5.2']
{ minecraftVersion: '1.5.2',
  version: 61,
  usesNetty: false,
  majorVersion: '1.5' }

even though this is the same data in all datasets:

> require('minecraft-data')('1.9').versionsByMinecraftVersion['1.5.2']
{ minecraftVersion: '1.5.2',
  version: 61,
  usesNetty: false,
  majorVersion: '1.5' }

and you have to know a current dataset to lookup any version:

> require('minecraft-data')('1.5.2').versionsByMinecraftVersion['1.5.2']
TypeError: Cannot read property 'versionsByMinecraftVersion' of null

Wouldn't it be cleaner if you could lookup versions, and versionsByMinecraftVersion like this:

> require('minecraft-data').versionsByMinecraftVersion['1.5.2']

or perhaps to maintain the function-calling syntax, something like:

> require('minecraft-data')('common').versionsByMinecraftVersion['1.5.2']

(I started to make this change myself, but got stuck on building the indexes)

Find and add functions to match use cases

See PrismarineJS/minecraft-data#14 (comment)

• powerful look up by display name : see https://github.com/Darthfett/helperbot/blob/master/lib/items.js#L14 and https://github.com/PrismarineJS/minecraft-data/blob/770d8e07de1609e36904e02af644130f61aa30f5/bin/wiki_extractor/lib/find_item_object_by_name.js : actually, that should be in bots or in a "natural language for minecraft" module or something
• checking every usage of minecraft-data can be replaced properly by a use of node-minecraft-data in :
  • helperbot
  • rbot
  • mineflayer

Clean static data reference

https://github.com/PrismarineJS/node-minecraft-data/blob/master/index.js#L79 is really ridiculous.
these paths used to be automatically found but we put them statically for browserify.

That logic still makes sense. But maintaining that list manually is silly.

Instead it could at the very least be generated automatically (run a script to generate a .js)

isNewerOrEqualTo throws TypeError when comparing 2 different version types

E.g when you're trying to compare PE version with PC one
It should probably just return false instead

Put files other than index.js, browser.js and example.js in lib/

Reduce unnecessary package size

Currently, consuming the library pollutes node_modules with over 100MB of data that most of the time is never actually used.
A simple way to largely reduce this would be splitting the platforms like so:

minecraft-data@pc (Independent)
minecraft-data@bedrock (Independent)
minecraft-data (Depends on both)

itemsByName returns undefined

When I try mcData.itemsByName[/Ominous Banner/] it returns undefined. I think this is a bug.

Error with tsconfig.json in VScode

Depreciate findItemOrBlockByName

1. remove from doc
2. print a big warning on usage
3. release
4. wait a month
5. delete
6. release major version

Correct materials for Podzol & Coarse Dirt

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch [email protected] for the project I'm working on.

It seems that some of the materials for podzol and coarse_dirt were wrong.

Here is the diff that solved my problem:

diff --git a/node_modules/minecraft-data/minecraft-data/data/pc/1.13.2/blocks.json b/node_modules/minecraft-data/minecraft-data/data/pc/1.13.2/blocks.json
index ffbac66..bf429b5 100644
--- a/node_modules/minecraft-data/minecraft-data/data/pc/1.13.2/blocks.json
+++ b/node_modules/minecraft-data/minecraft-data/data/pc/1.13.2/blocks.json
@@ -280,7 +280,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 11,
     "resistance": 0.5
   },
@@ -307,7 +307,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 13,
     "resistance": 0.5
   },
diff --git a/node_modules/minecraft-data/minecraft-data/data/pc/1.13/blocks.json b/node_modules/minecraft-data/minecraft-data/data/pc/1.13/blocks.json
index 1c46f9b..2e02bbd 100644
--- a/node_modules/minecraft-data/minecraft-data/data/pc/1.13/blocks.json
+++ b/node_modules/minecraft-data/minecraft-data/data/pc/1.13/blocks.json
@@ -270,7 +270,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 11
   },
   {
@@ -296,7 +296,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 13
   },
   {
diff --git a/node_modules/minecraft-data/minecraft-data/data/pc/1.14.4/blocks.json b/node_modules/minecraft-data/minecraft-data/data/pc/1.14.4/blocks.json
index 5fe0195..a4f76dd 100644
--- a/node_modules/minecraft-data/minecraft-data/data/pc/1.14.4/blocks.json
+++ b/node_modules/minecraft-data/minecraft-data/data/pc/1.14.4/blocks.json
@@ -280,7 +280,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 11,
     "resistance": 0.5
   },
@@ -308,7 +308,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 13,
     "resistance": 0.5
   },
diff --git a/node_modules/minecraft-data/minecraft-data/data/pc/1.15.2/blocks.json b/node_modules/minecraft-data/minecraft-data/data/pc/1.15.2/blocks.json
index 010898a..4213551 100644
--- a/node_modules/minecraft-data/minecraft-data/data/pc/1.15.2/blocks.json
+++ b/node_modules/minecraft-data/minecraft-data/data/pc/1.15.2/blocks.json
@@ -280,7 +280,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 11,
     "resistance": 0.5
   },
@@ -308,7 +308,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 13,
     "resistance": 0.5
   },
diff --git a/node_modules/minecraft-data/minecraft-data/data/pc/1.16.1/blocks.json b/node_modules/minecraft-data/minecraft-data/data/pc/1.16.1/blocks.json
index 6adc40a..68aeaaf 100644
--- a/node_modules/minecraft-data/minecraft-data/data/pc/1.16.1/blocks.json
+++ b/node_modules/minecraft-data/minecraft-data/data/pc/1.16.1/blocks.json
@@ -287,7 +287,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 11,
     "resistance": 0.5
   },
@@ -315,7 +315,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 13,
     "resistance": 0.5
   },
diff --git a/node_modules/minecraft-data/minecraft-data/data/pc/1.16.2/blocks.json b/node_modules/minecraft-data/minecraft-data/data/pc/1.16.2/blocks.json
index 5c51635..a4f9a42 100644
--- a/node_modules/minecraft-data/minecraft-data/data/pc/1.16.2/blocks.json
+++ b/node_modules/minecraft-data/minecraft-data/data/pc/1.16.2/blocks.json
@@ -287,7 +287,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 11,
     "resistance": 0.5
   },
@@ -314,7 +314,7 @@
     "emitLight": 0,
     "boundingBox": "block",
     "stackSize": 64,
-    "material": "plant",
+    "material": "dirt",
     "defaultState": 13,
     "resistance": 0.5
   },

This issue body was partially generated by patch-package.

Add example on how to access data directly in the doc

there https://github.com/PrismarineJS/node-minecraft-data/blob/master/doc/api.md#minecraft-dataitemsbyname

Drops always empty

The drops field of any Block always (at least in each test I've run) returns an empty array instead of the actual drops.

Example (stone):

minecraft-data:

"drops": [
    21
],

using MinecraftData.blocks:

drops: [],

Apologies if this is an issue on my end, but from what I can tell, it is an issue with the package.

How to get data for 0.14.3

Hi
I just follow the example and modify:

const mcData=require("minecraft-data")("0.14.3")

console.log(mcData.blocksByName["stone"])
console.log(mcData.windows["minecraft:brewing_stand"])
console.log(mcData.version)
console.log(mcData.effectsByName["Haste"])

But the code not run

Please help me on how to get data for 0.14.3
From minecraft-data there is 0.14 support:

Language independent module providing minecraft data for minecraft clients, servers and libraries.

Supports

Minecraft PC version 0.30c (classic), 1.7.10, 1.8.8, 1.9 (15w40b, 1.9, 1.9.1-pre2, 1.9.2, 1.9.4), 1.10 (16w20a, 1.10-pre1, 1.10, 1.10.1, 1.10.2), 1.11 (16w35a, 1.11, 1.11.2), 1.12 (17w15a, 17w18b, 1.12-pre4, 1.12, 1.12.1, 1.12.2), 1.13 (17w50a, 1.13, 1.13.1, 1.13.2-pre1, 1.13.2-pre2, 1.13.2), 1.14 (1.14, 1.14.1, 1.14.3, 1.14.4), 1.15 (1.15, 1.15.1, 1.15.2), 1.16 (20w13b, 20w14a, 1.16-rc1, 1.16, 1.16.1, 1.16.2, 1.16.3, 1.16.4, 1.16.5), and 1.17
Minecraft PE version 0.14, 0.15 and 1.0

Thank you

Publish the `3.32.0` release to npm

You forgot to publish the update to npm

defintion of postNettyVersionsByProtocolVersion incorrect in typescript types

There is a mismatch between the type declaration and what is actually returned by postNettyVersionsByProtocolVersion

postNettyVersionsByProtocolVersion.pc[protocol]

returns an array of Versions but index-template.d.ts specifies a single version

Loot data

The types are wrong for entityLoot and blockLoot. The keys are strings, not ids.
I also noticed that entityLootByName and blockLootByName seem to be undefined.

Translate item's displayName.

Hello, is it possible to get the displayName of an item in French ? Here is the actual code:

        if(!objectPath.has(item, 'display_name') && objectPath.has(item, 'id')){
            let vanillaItem = mcData.items[item.id];

            if(vanillaItem && objectPath.has(vanillaItem, 'displayName'))
                item.display_name = vanillaItem.displayName;
        }

Question: can i use this to ping my mc SUBservers (i have proxy network with TCPShield)

Hello
can i even use this package using nodejs to ping my subservers? not the proxy server, i can already do that
i want to ping subservers which are fully portected by tcpshield, the problem is that no other nodejs package i tried specifically including in their names minecraft-status/minecraft-ping can NOT do this (probably because of TCPShield?)

can this one do? if so, how can i utilize ping method to ping and get promise (.then)?

Thanks in advance!!!

0.19.0 release: Error: Cannot find module './minecraft-data/data/common/protocolVersions'

When installing the 0.19.0 release of minecraft-data from from npm, require() fails:

tmp $ npm install minecraft-data
[email protected] node_modules/minecraft-data
tmp $ node
> require('minecraft-data')
Error: Cannot find module './minecraft-data/data/common/protocolVersions'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:289:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (/private/tmp/node_modules/minecraft-data/index.js:3:22)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Module.require (module.js:366:17)

see also https://circleci.com/gh/PrismarineJS/node-minecraft-protocol/371 - observed when updating in PrismarineJS/node-minecraft-protocol#331

using the git version of node-minecraft-data (https://github.com/PrismarineJS/node-minecraft-data/tree/4e7f910e62ea30c641a9df2170275d49bbd1edad) with npm install works locally at least on my system, so I think this is an issue with the release only