Minecraftforge: Recipes with damaged ingredients are broken

[fscan]

4472 broke recipes with damaged ingredients as it's not checking the magic meta value (32767) for ignoring damage.

[liach]

See https://github.com/MinecraftForge/MinecraftForge/pull/4449#issuecomment-342743511. That vanilla handling just brought too many inconveniences.

[williewillus]

+1 this is affecting Botania

[LexManos]

This is actually intention from Mojang's end. Wild cards are essentially removed by Mojang in favor of explicitly listing all sub-items. We hack it in for OreDict items, But the vanilla reader has an explicit check for items with subitems. Which is what Botania should be doing. Tho i'm not sure of what his recipe is intending...

At the end of the day, The things still filter through Ingredient.apply, so it should still work.
Can you supply a example recipe json that doesn't work?

[capnkirok]

Here's an example recipe, @LexManos

{ "type": "animania:cutting_recipe", "ingredients": [ { "item": "animania:carving_knife", "data": 32767 }, { "item": "animania:friesian_cheese_wheel" } ], "result": { "item": "animania:friesian_cheese_wedge", "data": 0, "count": 4 }, "group": "cheese_cutting" }

[fscan]

The patch also seems to break recipes with undamageable ingredients with fixed meta values on multiplayer. Reverting to the old _match_ implementation in an overridden _ShapelessOreRecipe_ restores the functionality.

[LexManos]

Explain better, and post the json for recipes that are not working. We need test data. I'm currently trying to make one that matches @capnkirok 's but he uses custom items so its annoying.

[williewillus]

here's one from botania (result was botania item, replaced with diamond. first ingredient was botania item, replaced with dirt)

{
  "result": {
    "item": "minecraft:diamond"
  },
  "ingredients": [
    {
      "item": "minecraft:dirt",
      "data": 0
    },
    {
      "item": "minecraft:dye",
      "data": 32767
    },
    {
      "item": "minecraft:dye",
      "data": 32767
    },
    {
      "item": "minecraft:dye",
      "data": 32767
    },
    {
      "item": "minecraft:dye",
      "data": 32767
    }
  ],
  "type": "minecraft:crafting_shapeless"
}

broken in >= 2532, works <= 2532. The recipe should be dirt + any 4 vanilla dyes => diamond

[fscan]

Ok, so i tried to do some more testing to reproduce it with vanilla stuff. While not exactly reproducing my problem, there seems to be some weird stuff going on that may have the same cause:

{
    "type": "forge:ore_shapeless",
    "result": {
       "item": "minecraft:stone",
       "data": 0
    },
    "ingredients": [
        {
            "item": "#modid:someWool"
        },
        {
            "item": "#modid:someWool"
        }
    ]
}

_constants.json:

[
   {
        "name": "modid:someWool",
        "ingredient": [
            {
                "item": "minecraft:wool",
                "data": 1
            },
            {
                "item": "minecraft:wool",
                "data": 2
            }           
        ]
   }
]

With the current build i can use ANY wool to craft the item. Before the PR was applied only the specified colors work.

[LexManos]

So, i've talked to Grum about this and basically he says its intended to use a custom recipe for 'tool' like objects.
I've gone ahead and added in a fix for the normal wildcards not working for items with sub-types. Similar to what I do with OreIngredients. Where it expands the wildcard at init time.

However this doesn't solve the tool issue.
We still need to create a seperate slower max fill implementation that supports arbitrary Ingredients.
We also need to decide on a marker for an Ingredient that DOES NOT follow the normal Ingredient contract of knowing all of it's possible values.
The problem is that the GuideBook needs to know all possible values so it that it can search a player's inventory {or any other large inventory} quickly enough to not lag the server to death checking the several thousand recipes a modded instance can have.
So if we can decide a way to mark Ingredients as 'not searchable' then we can skip displaying those recipes in the GuideBook and not have to worry about the performance. As then the only time it would match up is in the crafting grid which is only 9 items so MUCH less to search through.

Thoughts?

Side Note: I was going to push out a RB until this was discovered, so it'd be nice to get something in place so I can make a RB.

[fscan]

Ok, i think i found the root of my issue (other then the tool thing). The ore_dict recipes don't work as constants. This works in single player. In multiplayer it works before 2532, but not after (including 2544)

{
    "type": "forge:ore_shapeless",
    "result": {
       "item": "minecraft:stone",
       "data": 0
    },
    "ingredients": [
        {
            "item": "#forge:some_ore"
        },
        {
            "item": "#forge:some_ore"
        }
    ]
}

_constants.json

    {
        "name": "forge:some_ore",
        "ingredient": [
            {
                "type": "forge:ore_dict",
                "ore": "oreDiamond"
            },
            {
                "type": "forge:ore_dict",
                "ore": "oreIron"
            }           
        ]
    }

[ghost]

This was fixed in Forge 14.23.0.2542.

[fscan]

Did you test? Like i wrote, i still have the problems on 2544. Also the wool recipe i posted earlier is still broken.

[ghost]

I tested Quark’s wool recipe several times. It worked in 2542 but not in 2541.

Maybe your issue is a different one. I don’t know.

[Xilef11]

I still have that issue with Forge >= 2542, but only on dedicated servers...

recipes (with custom items replaced by diamonds)

{
  "result": {
    "item": "minecraft:diamond",
    "data": 0,
    "count": 8
  },
  "ingredients": [
    {
      "item": "minecraft:coal",
      "data": 0
    },
    [
        {
            "type": "forge:ore_dict",
            "ore": "treeSapling"
        },
        {
            "type": "forge:ore_dict",
            "ore": "treeLeaves"
        },
        {
            "item": "minecraft:wheat_seeds"
        },
        {
          "item": "minecraft:tallgrass",
          "data": 32767
        }
    ],
    [
        {
            "type": "forge:ore_dict",
            "ore": "treeSapling"
        },
        {
            "type": "forge:ore_dict",
            "ore": "treeLeaves"
        },
        {
            "item": "minecraft:wheat_seeds"
        },
        {
          "item": "minecraft:tallgrass",
          "data": 32767
        }
    ]
  ],
  "type": "forge:ore_shapeless"
}

{
  "result": {
    "item": "minecraft:diamond",
    "data": 0
  },
  "ingredients": [
    [
        {
          "item": "minecraft:red_flower",
          "data": 32767
        },
        {
          "item": "minecraft:yellow_flower",
          "data": 32767
        },
        {
          "item": "minecraft:tallgrass",
          "data": 32767
        },
        {
          "type": "forge:ore_dict",
          "ore" : "treeLeaves"
        },
        {
          "type": "forge:ore_dict",
          "ore": "treeSapling"
        }
    ],
    {
      "item": "minecraft:diamond"
    }
  ],
  "type": "forge:ore_shapeless"
}

[LexManos]

Try and lower the complexity of the recipe. And if you're getting it only on dedicated servers then most likely case is that something is your ore list is not the same between client and server. What exact items and meta are you using?
Try a recipe without mixing both wildcards and ores. Some basic debugging because I can't seem to reproduce the issue.

[Xiaminou]

So that's why some of my recipes stopped working.
I can confirm that it's not been fixed by 2542 for my dedicated server. I downgraded it to 2531 and it works again.
I am however connecting with a client that's on 2544 and although I haven't tested if the recipes were broken between 2531-2541 I can confirm that what was broken (when I used 2532+) on my dedicated server is not on my client (using 2544).

[Xilef11]

Here's a simplified version, using only oredict:

{
  "result": {
    "item": "minecraft:diamond",
    "data": 0
  },
  "ingredients": [
    [
        {
          "type": "forge:ore_dict",
          "ore" : "treeLeaves"
        },
        {
          "type": "forge:ore_dict",
          "ore": "treeSapling"
        }
    ],
    {
      "item": "minecraft:diamond"
    }
  ],
  "type": "forge:ore_shapeless"
}

I tested it with both Oak and Spruce leaves, neither work.

For the metadata version:

{
  "result": {
    "item": "minecraft:diamond",
    "data": 0
  },
  "ingredients": [
    [
        {
          "item": "minecraft:red_flower",
          "data": 32767
        },
        {
          "item": "minecraft:yellow_flower",
          "data": 32767
        }
    ],
    {
      "item": "minecraft:diamond"
    }
  ],
  "type": "forge:ore_shapeless"
}

I tested with a poppy and it looks like it works (I also tried changing the type to "minecraft:crafting_shapeless"). The output slot sometimes does not show the result, but clicking on it gives the item (although, keep in mind I'm running both the client and server from the dev environment on my 5YO laptop, so that might just be performance issues...)

[fscan]

Did a little bit of debugging.
CompoundIngredient#getValidItemStacksPacked is annotated with @SideOnly(Side.CLIENT). So on the server side the RecipePickerdoes not find all ingredients.

[LexManos]

Did a little bit of debugging.

https://github.com/MinecraftForge/MinecraftForge/commit/836be2e3a0d83d3ae54fec37c1da9332acc4d2b3 Thanks. This still doesn't address how to identify ingredients as non RecipeBook compatible. Or the custom MF implementation.

[fscan]

Thanks, this fixes our most pressing issues. For damageable items i implemented a custom recipe (actually using the old forge implementation of match). It works, but i don't know enough about the matter to say if this the optimal solution or what a better solution would look like.

[LexManos]

It works, but it doesn't solve the issue of a single input matching multiple ingredients. Honestly like I said there doesnt seem to be any simple way to solve it without adding a ;this ingredient doesnt work with guidebook'

[bs2609]

Linking MC-122108 in case it's relevant.

[LexManos]

That commit should of solved this issue:

{
  "type": "minecraft:crafting_shapeless",
  "ingredients": [
    {
      "item": "tool",
      "data": 32767
    },
    {
      "item": "minecraft:stone",
      "data": 32767
    },
    {
      "item": "minecraft:stone",
      "data": 0
    }
  ],
  "result": {
    "item": "minecraft:wool",
    "data": 0
  }
}

{
  "type": "minecraft:crafting_shapeless",
  "ingredients": [
    {
      "item": "minecraft:bow",
      "data": 32767
    }
  ],
  "result": {
    "item": "minecraft:wool",
    "data": 9
  }
}

And it should be able to auto-detect normal shapeless recipes for 'damageable' items. If not let me know EXACT cases.

It would also be nice if someone had a NBT ingredient test. As this should use the same matching for those as they are not 'simple' ingredients. Simple ingredients are defined as ingredients that map to a known item/metadata set.

Gunna give this 24 hours, and if nobody has reported anything, gunna make a Recommended release of Forge containing this fix. So if you have issues SPEAK UP

[fscan]

Nice, this seems to fix it.
Fyi, the recipe i posted in https://github.com/MinecraftForge/MinecraftForge/issues/4516#issuecomment-344087211 still has issues (can use any wool instead of specified ones). Sample without constants :

{
    "type": "minecraft:crafting_shapeless",
    "result": {
       "item": "minecraft:stone",
       "data": 0
    },
    "ingredients": [
       [
            {
                "item": "minecraft:wool",
                "data": 1
            },
            {
                "item": "minecraft:wool",
                "data": 2
            }           
        ],
        [
            {
                "item": "minecraft:wool",
                "data": 1
            },
            {
                "item": "minecraft:wool",
                "data": 2
            }           
        ]
    ]
}

Interestingly, if i cut it down to only 1 ingredient it works as expected.