PrismarineJS / minecraft-data

Language independent module providing minecraft data for minecraft clients, servers and libraries.
https://prismarinejs.github.io/minecraft-data
621 stars 215 forks source link

Smelting/Furnace data #290

Open njt1982 opened 4 years ago

njt1982 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Possible changes:

recipes.json:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 notifications@github.com 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

njt1982 commented 3 years ago

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

Pokechu22 commented 3 years ago

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

njt1982 commented 3 years ago

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

extremeheat commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

extremeheat commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 8 months ago

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