Smelting/Furnace data

[njt1982]

Hi,

Maybe I'm missing something here...

Is there any data about how things like Iron Ore gets turns into Iron Ingots? It's obviously not a crafting recipe...

[njt1982]

Have raised this in Burger too as it seems to be missing "upstream"... https://github.com/mcdevs/Burger/issues/35

Seems to be intentionally excluded... https://github.com/mcdevs/Burger/blob/fdff962aeb1aa0351fc222e005af3fa9248345fb/burger/toppings/recipes.py#L136

[rom1504]

Yeah basically we would need to check if these recipes could fit in the same format. If they do we could add them there. We would probably need to tag them though

[njt1982]

I'd be inclined to put them in a smelting.json (or similar). They have different structures; in/out/timing. There is no shape, no "count":

{
  "type": "minecraft:smelting",
  "ingredient": {
    "item": "minecraft:iron_ore"
  },
  "result": "minecraft:iron_ingot",
  "experience": 0.7,
  "cookingtime": 200
}

Thats the raw data from the iron_ingot.json in the minecraft server.jar

[rom1504]

Sounds good to me. If you're interested by this, feel free to propose changes in the pipeline so we can have that :

• In burger to have a recipe type option
• In burger extractor to put the recipe in the right format
• In minecraft data to define a good schema and put the data (at least for the last version)
• In node-minecraft-data to expose that data
• In prismarine-recipe to use that data
• In mineflayer to actually implement these recipes

Before doing all this though, could you please check how many recipes that is ? If it's just 2 or 3, we could maybe do something different

[njt1982]

Hi,

Based on https://github.com/mcdevs/Burger/issues/35 it's ~50 recipes for smelting. But @Pokechu22 raised an interesting point about smokers and blast furnaces too. They also made this suggestion:

It might be easier for minecraft-data to use the data generator system (or directly extracting the JSON files from the minecart jar) themselves, and bundle it into their own recipes.json or equivalent, rather than that data first being put into burger and then put into minecraft-data.

[rom1504]

I'm fine with that. Won't change too much the process I described above.

Feel free to work on it then. Probably worth it to do all types of recipes and not only smelting

[extremeheat]

If there's any agreed-upon structure for storing the recipes, I can get the ball rolling and implement the missing data for Java and Bedrock. For Java the data can be pretty easily extracted from the datapacks, possibly with changes to Burger or a separate script to just extract the data.

For Bedrock, the process is mostly the same, and the data is available for download on minecraft.net. (Some data seems to be missing from here though, so extracting from the app binary may be required, as I have here)

Maybe we can get some parity between Java and Bedrock, so here's the differences between the two:

minecraft:acacia_stairs

Java:

{
  "type": "crafting_shaped",
  "group": "wooden_stairs",
  "pattern": [
    "#  ",
    "## ",
    "###"
  ],
  "key": {
    "#": {
      "item": "minecraft:acacia_planks"
    }
  },
  "result": {
    "item": "minecraft:acacia_stairs",
    "count": 4
  }
}

Bedrock:

"minecraft:recipe_shaped": {
    "description": {
    "identifier": "minecraft:acacia_stairs"
    },

    
    "tags": [ "crafting_table" ],
    "group": "wooden_stairs",
    "pattern": [
      "#  ",
      "## ",
      "###"
    ],
    "key": {
      "#": {
        "item": "minecraft:planks",
        "data": 4
      }
    },
    "result": {
      "item": "minecraft:acacia_stairs",
      "count": 4
    }
  }

minecraft:glass

Java:

{
  "type": "smelting",
  "ingredient": {
    "tag": "minecraft:sand"
  },
  "result": "minecraft:glass",
  "experience": 0.1,
  "cookingtime": 200
}

Bedrock: (extracted from binary)

{
            "block": "furnace",
            "input": {
                "id": 12,
                "damage": -1
            },
            "output": {
                "id": 20
            }
}

[TheDudeFromCI]

Usually, the MC-Data isn't a direct copy of the raw JSON files, but more of a pre-parsed version of it, so we wouldn't have to worry about differences between versions.

I also think it would be a good idea to add canUseInSmoker and canUseInBlastFurnace tags.

[extremeheat]

Possible changes:

recipes.json:

• add new "block" property to indicate where the recipe is usable (e.g. crafting table, furnace, brewing stand, etc)
• switch from "inShape" to "pattern" so more data can be attached like metadata to each ingredient (bedrock still uses it)

Switching from "inShape" -> "pattern" is a breaking change, so possibly it could only be done on the bedrock side.

or we could add new files for each container, although this could be cumbersome.

As far as the blast/smoker furnaces, I'm not exactly sure how they're implemented but I'll look into it.

[TheDudeFromCI]

I don't believe any changes need to be made to the recipes.json. Smelting data should be in a separate file completely. The current format for recipes.json works well for the information that it targets. Lastly, we should not use separate formats for Bedrock and Java, as this puts much more weight on end-users to write handlers for them since they would need to learn a separate format for each version. There should be a uniform format for all Minecraft versions and platforms.

Smelting data can all be in a single file, so no need to make a new file per container. Just specify the smoker and blast furnace tags, there. This should be pretty compact, too. It's also worth noting that fuel data should be added, though that can be in a different file.

[rom1504]

another source of data that could be useful https://raw.githubusercontent.com/PrismarineJS/prismarine-packet-dumper/fixtures/packets/from-server/declare_recipes/1.parsed the server directly send us the recipe in recent versions

[extremeheat]

Yeah, I was thinking about fetching them from the network. On Java I don’t think it matters over the network vs. data pack, but on bedrock it seems that extracting from binary or loading from the network is the way to go. Not sure if there’s any existing automated tool to extract from the network, but I can create one over the weekend if not.

[rom1504]

The data is available with burger, with data extractors or through the network yes https://github.com/PrismarineJS/prismarine-packet-dumper/blob/fixtures/packets/from-server/declare_recipes/1.parsed

On Thu, Aug 20, 2020, 13:12 extremeheat [email protected] wrote:

Yeah, I was thinking about fetching them from the network. On Java I don’t think it matters over the network vs. data pack, but on bedrock it seems that extracting from binary or loading from the network is the way to go. Not sure if there’s any existing automated tool to extract from the network, but I can create one over the weekend if not.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/minecraft-data/issues/290#issuecomment-677538266, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437TY2HXWMOFSOFMRCXDSBUALTANCNFSM4NPL5CYQ .

[njt1982]

That 1.parsed looks super handy... What package would be used to convert that into smelting.json?

I've been looking at Burger Burger Extractor... not sure that works with this packer-dumper format?

[Karang]

I think only filtering recipes for type === "minecraft:blasting" || type === "minecraft:smelting" and saving that to a smelting.json ? Unless we want to keep all recipes in recipes.json ?

[njt1982]

I'm having issues just getting the burger extractor to work! 😉

(master) % node src/index.js ../Burger/output.json 1.16.2

 > Make sure to have the latest version of minecraft-data installed

  Data extraction started
    Extracting biome data
    Extracting block data
    Extracting entity data
    Extracting item data
    Extracting recipe data
 > Error extracting data TypeError: Cannot read property 'biome' of undefined
TypeError: Cannot read property 'biome' of undefined
    at Promise (/Users/nthompson/Desktop/burger/burger-extractor/src/extractors/biomes.js:13:27)
    at new Promise (<anonymous>)
    at module.exports (/Users/nthompson/Desktop/burger/burger-extractor/src/extractors/biomes.js:8:51)
    at Promise.all.extractors.map.extractor (/Users/nthompson/Desktop/burger/burger-extractor/src/index.js:63:49)
    at Array.map (<anonymous>)
    at run (/Users/nthompson/Desktop/burger/burger-extractor/src/index.js:63:32)
    at Object.<anonymous> (/Users/nthompson/Desktop/burger/burger-extractor/src/index.js:77:1)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)

[Pokechu22]

Burger isn't able to extract biomes in 1.16 currently, so no biome data is generated.

[njt1982]

Thanks @Pokechu22 - so should I use 1.15.x?

[Pokechu22]

For now, yes, though probably the burger extractor should be modified to not die if any single part of the data is missing.

[njt1982]

ah cool - yes, it worked against a 1.15.2 extraction.

[extremeheat]

Going to vote in favor of keeping the recipes in one place, especially if the types of recipes increases in the future. Right now there's different sets of smelting recipes (normal, blast, smoking, campfire), stonecutter recipies, and crafting tables (see protocol). Bedrock notably also has potion recipes. Internally and over the network they're all stored together, so splitting it up into separate JSON files could lead to problems down the road if new crafting methods get introduced later down the line. The server will need to load all the recipes at once anyways so it can send them down to the client.

[njt1982]

I think I agree... From a UX point of view, I was surprised to not find any "recipes" for iron_ore in recipes.json; it's where I expected them to be (although that was before I'd considered some of the points here about the various crafting table types).

[njt1982]

Not sure if there’s any existing automated tool to extract from the network, but I can create one over the weekend if not.

@extremeheat So it sounds like there is no existing tool to parse that 1.parsed file?

[njt1982]

It looks like that 1.parsed would replace the need to extract from Burger?

[extremeheat]

Not that I'm aware of, no. I wrote my own extractor for the datapacks, I might try to merge it into Burger. Or we can just grab them over the network like rom mentioned. Not sure what the consensus is on where to get the data, but feel free to write the parser if you want.

[rom1504]

about where to put recipes, try to figure out how the schema would look like with the new recipes. If changes are minimal it makes sense to put it in the same file

[Pokechu22]

As I mentioned in mcdevs/Burger#35 I'd rather not have more recipe types in burger (I'm actually somewhat tempted to remove the current recipe extractor), since it adds a lot of size to the generated data but requires very little non-trivial code to extract from a datapack. That adds up a fair bit over snapshots and I think it's part of the reason why it takes so long for data to be available on github pages now.

[nickelpro]

I'm not super familiar with the generator system but if it's available from there we can just use that rather than going through burger. If it's not available through generators we can write a one-off Jawa script to extract the json. It would just be a copy paste of what the current recipe topping is doing now, but if Pokechu want's recipes out it's not hard to maintain.

That said, Pokechu why not just not run the recipe topping for your snapshots?

[Synthetic-Dev]

dump: Is there any update on this? It has been 3 years!