Hi, so for my mod, I want to remove all of the vanilla recipes for wooden tools, since I'm doing a bit of an overhaul to early-game. I've done some digging and seen that forge packages it's own mod so to override the recipes I came to the deduction that I need to place my custom "result": "minecraft:air" recipes into the data/forge/recipes folder in my mod. This works... for wooden_hoe.json, wooden_pickaxe.json, and wooden_shovel.json, however wooden_axe and wooden_sword recipes still work DESPITE their result being "minecraft:air". I've tripple checked spelling and everything. I then thought maybe it was a loading order problem, or maybe forge didn't actually implement alternate recipes for those (even though they use tags...) so I chucked them into data/minecraft/recipes. Still no dice. But I didn't think that would work. Is anyone able to tell me what I might be missing here, please?

https://github.com/MinecraftForge/MinecraftForge/issues/6287

Thanks for the reply, and as the post you linked me to has stated, I have indeed tried placing it inside of src/main/resources/data/minecraft/recipes after forge/recipes did not work. Which also didn't work.

Even then, why does it work for pickaxe, shovel and hoe, but NOT for sword or axe?

An update just to show that I have also tried the method suggested in one of the comments from the issue you linked me to. wooden_axe.json is located in src/main/resources/data/minecraft/recipes when I took this screenshot. I'm also going to try this same recipe in the forge folder, to see if it's mod ordering. I still find it unusual that wooden_pickaxe, wooden_hoe and wooden_shovel all worked perfectly the first time, when I placed them inside of forge folder. All I did was copy the vanilla recipe files, and change the result item to "minecraft:air", which imo, is all that needs to be done. Doesn't matter what the pattern or key is as long as the output is just air.

Just to further outline why this problem is confusing me, I'm uploading a gif which demonstrates that I'm not a complete git who's just put things in the wrong place or made a typo. You can see the files on the left, and I have open the problematic "wooden_axe.json" file that as you can see in the gif, is not in fact replacing the recipe output with minecraft:air. As you can see in the gif, the three files wooden_hoe, wooden_shovel and wooden_pickaxe all correctly override the vanilla recipe. They don't work. The axe, in the same location as the three tools that have correctly emptied their recipes does not. The sword, in the recommended ...data/minecraft/recipes folder also does not work, as demonstrated. If I move the three files that currently work, into the data/minecraft/recipes folder, they cease to override the recipe and instead give me the regular result.

 

From all the digging I've done, and responses to the different variations of the same question that I'm posting now that I've seen. It works for some people. Things that work for some people don't work for others, with exactly the same implementation. This should not be how code works. Honestly seeing the same variations of peoples responses being "You're dumb you put it in the wrong spot" or just "throwing files all over the place" infuriates me. I've been coding for the last 10 years, and the fact that I can't reproduce or even determine why only 3/5 of the files in THE SAME FOLDER are correctly overriding their recipes. That completely craps all over ANY suggestion of getting the directory wrong. Three files work. Two don't. All are made using the same method of replacing the result item with minecraft:air.

 

27 minutes ago, Intrepid249 said:

Thanks for the reply, and as the post you linked me to has stated, I have indeed tried placing it inside of src/main/resources/data/minecraft/recipes after forge/recipes did not work. Which also didn't work.

Even then, why does it work for pickaxe, shovel and hoe, but NOT for sword or axe?

The point of the link was to show that it is a bug that has not been addressed.

Ah. My apologies. I guess I misinterpreted that, since it just seems like the comments left it at a "Mine worked, it's a you problem"

Thank you for the link though. It did offer me to a couple of, (evidently fruitless) suggestions to try. It may well be because I'm a few versions behind whatever the latest 1.14.4 Forge release was, as I'm using the stable release. (28.2.0 or something like that)

Edited April 22, 20205 yr by Intrepid249
further information

What I do to override or get rid of default crafting recipes is create a blank json file under data.minecraft.recipes and name it the same as what minecraft calls it. I then create a new recipe under data.*yourmodname*.recipes that does what I want. 

uh... what do you mean? so like
data/minecraft/recipes/wooden_axe.json
{

}

 

then data/mymod/recipes/wooden_axe.json

{

...

"result": "minecraft:air"

So I just tried that, and likewise, either it just doesn't override the recipe, or it gives me a bunch of errors in console trying to load invalid recipes @theNightBane

15 hours ago, Intrepid249 said:

...I want to remove all of the vanilla recipes for wooden tools, since I'm doing a bit of an overhaul to early-game.

in FMLInitializationEvent, you can iterate through ForgeRegistries.RECIPES, check recipe output and remove all recipes that output items you want to remove.

 

or if you want to target specific registries ForgeRegistries.RECIPES has a remove method that takes a ResourceLocation. you need to cast it first.

 

disclaimer: answer may be inaccurate due to forge versions.

Oohhhhhhh I see. How would I check the recipe output? I haven't looked into it just yet, but if you could suggest how I might go about it, that would be a great help. Thank you for the suggestion!

Stop telling people how to do hacky things.

Forge's data pack SHOULD be directly between vanilla's and modder's so modders should be able to override anything Forge ships just like they can override vanilla.

If this is not the case, then we may need to backport the changes from 1.15.2, as I know this works on the 1.15 branch.

2 minutes ago, LexManos said:

Stop telling people how to do hacky things.

Forge's data pack SHOULD be directly between vanilla's and modder's so modders should be able to override anything Forge ships just like they can override vanilla.

If this is not the case, then we may need to backport the changes from 1.15.2, as I know this works on the 1.15 branch.

So what you're saying is, that despite my gif demonstrating that forge's datapack does not work to override vanilla for 1.14.4, that it should just work anyway? And that people should stop offering suggestions because they are trying to be helpful? Which is, after all, what forums are supposed to be for. It is a public forum for people to share their personal knowledge, in an attempt to help others. They are not devs of forge, so they are just giving the best advice, based on the experience and knowledge that they have.

 

I would rather work in 1.14.4 but honestly it's really quite frustrating how something that (from all the google searching I've done) seems to have been responded to time and time again, from about 8 months ago BY forge programmers, to be "functional" and a "user error" i.e. the modder doing something wrong, rather than a problem within Forge itself. I've seen countless posts where it seems that forge mods just step in and say "No, this works. You're just doing it wrong"

 

In this case, I would suggest updating the documentation to include a post on how to actually override the vanilla data packs, or look at my bloody gif where I think it's quite visible that it does not, in fact, work as stated.

{
  "type": "minecraft:crafting_shaped",
  "pattern": [
    "X"
  ],
  "key": {
    "X": {
      "item": "air"
    }
  },
  "result": {
    "item": "air"
  }
}

 

 

resources/data/minecraft/recipes/[XXXXX].json

 

 

I copied the JSON from the minecraft resources/data/minecraft/recipes and only included the above and it prevented me from crafting the items. Don't know if this helps, just wanted to provide a working example.

Edited April 25, 20205 yr by hoodzeay
Path mistake

Thanks hoodzeay, but I have already tried that and other variations. The way that Recipes work, I should only have to change the "result" for it to work. Everything else is basically redundant, because if the output is nothing, then it doesn't matter what the recipe is to make nothing. 0 x 1 is always going to be 0.

 

Lex, I apologise for getting aggressive toward the end of my post, however the main bulk of my point still stands. This issue has been brought up over 8 months ago, as seen here

and for a forum that is supposed to provide help, I don't agree with such help being provided in the form of "You're doing it wrong. Go do it properly". I will say that I guess I handled it poorly, but after having just read that forum page, and having you basically just tell everyone who was trying to help based on their own experience, that they need to stop teaching hacky things...... yeah I'll leave it at very poorly handled. Honestly, I understand your point of view. It's much better to learn the proper way to do something and understand it.

 

As you had stated in the linked thread above, this is such a trivial matter. And yet, 9 months on and people are still having problems. Granted, these problems may have been attended to in 1.15 but if you don't want people to explain hacky ways that they got it to work, then perhaps it might be worth updating the documentation page. (I don't mean this aggressively, it's an honest suggestion. I don't know, maybe a short two sentances on how to override vanilla data packs or something? If such a thing already exists, then I must have missed it, or maybe it's in a place that didn't seem intuitive to me)

That was the first place I went to, before even coming to the forum. All it said was how to add new recipes for my own mod, not how to override vanilla ones. There is a brief bit about how minecraft stores theirs, but it's not indicative of that being the steps to take to override them. And even then, I've shown a gif of that method working, for 3 out of 5 cases, in the same location. How do three work but two don't?

 

As you said, it's probably an oversight that was implemented on the 1.15 branch but not the 1.14 branch. I understand that it must be a lot of effort to maintain and even create forge. I wouldn't know where to start. But all I came here for, was to say "Hey, I've tried everything that *should* work, but it doesn't. Does anyone know why it doesn't work?". In terms of "hacky" methods, I would rather a "hacky" method that I need to change, than updating my branch, or even just waiting for a new patch.

 

It's come to mind, that possibly it has been implemented in the 1.14 branch already, but through oversight, the issue log mentioned earlier before about this matter https://github.com/MinecraftForge/MinecraftForge/issues/6287 is still marked as "open". I say this, as I'm using the "recommended" build for 1.14.4, rather than the latest. So I guess that's something I'm going to try next, is just updating the MDK to a more recent build. As you said, it "should" be working...

 

I guess my main issue that I had was, that I had asked a question, because I didn't understand something, and it felt like the response was "But it's so easy, you're doing it wrong, just go do it right". Like, I'd listed in my posts everything I'd tried, which was everything that had been suggested as working. And I guess I misinterpreted what you were saying as well. Anyway, thank you for the help, and hopefully I/we can figure out what's wrong with it or at least how to get it working. I should state that I don't really intend to release the mod to curseforge, as it's just a personal project I want to work on, so if I have to do something hacky to get it to work, I don't mind that. No, it is not the best practice, but at this point, if it works, it works. I'm frustrated enough at such a simple thing being so confoundedly complicated, especially after 8 or so months of other people also having the problem, and yet no one can decide on a definitive answer to what the problem actually is! That's also the main reason why I recorded the gif. Was just because so many people were going "despite the lovely post you wrote about everything you did to troubleshoot it, including trying it in the minecraft data directory like I am now suggesting, I'm going to say that you're clearly doing it wrong, because putting it in the minecraft directory worked for me"

 

Yes, I know 99% of problems are because of a typo in a json file, or the wrong location. Whatever. As a matter of fact I had a problem with one of my json files earlier where I'd typed "item": "minecraft:generated" for a model instead of "parent": "item/generated"

 

What bothers me is that I know this is not the case, yet if the developers are saying it's such a trivial thing, then why does it only partially (and in some aspects not at all) work?

Which, yes, you did answer in your post and like I said, it may have just been an oversight.

Edited April 25, 20205 yr by Intrepid249
rephrasing things

On 4/24/2020 at 6:20 PM, LexManos said:

Stop telling people how to do hacky things.

Forge's data pack SHOULD be directly between vanilla's and modder's so modders should be able to override anything Forge ships just like they can override vanilla.

If this is not the case, then we may need to backport the changes from 1.15.2, as I know this works on the 1.15 branch.

Unfortunately, it DOESN'T work in the latest 1.15.2 mdk (forge-1.15.2-31.1.50-mdk). As it stands, the issue IS on the github at https://github.com/MinecraftForge/MinecraftForge/issues/6287 although it's labeled for 1.14.4. If you want me to create a new issue on the github for 1.15.2, I'd be happy to. I know you'll ask for a reproduction case. Do a clean install of the mdk, add the package "data.minecraft.recipes" in src/main/resources. In the package, create "diamond_chestplate.json" with the contents:

{
  "type": "minecraft:crafting_shaped",
  "pattern": [
    "X X",
    "XXX",
    "XXX"
  ],
  "key": {
    "X": {
      "tag": "forge:gems/diamond"
    }
  },
  "result": {
    "item": "minecraft:air"
  }
}

 

The recipe does NOT override Forge's own diamond_chestplate.json. The override DOES work if you disable the datapack "mod:examplemod" in game (where forge re-enables it).

 

Until the issue is resolved, I don't see why we shouldn't resort to "hacky things" while waiting on a fix, especially if they're straightforward and fix the problem at hand.

I agree. Especially as I'm not intending (though depending on how it goes I might) on releasing the mod to the public curseforge directories. It is for personal use, for a stream. So I'm perfectly fine with any method that works reliably, though I am still interested in learning how to do it properly. If I were to release it publicly, I would definitely strive to use the proper methods, so then that way, if people combine it with other mods and things, then there's a reduced chance of things interfering with each other (though compatibility is very situation-dependant)

 

@Azaka7 thanks for your post. The things you've stated have been said before, though somewhat separate and not as cohesive and easy to understand. I'll try disabling the examplemod datapack and see if that solves my problem (though I've never disabled datapacks before... so guess I'll have to look that one up)

https://github.com/minecraftforge/minecraftforge/commit/746d702058b03d2c098f17b14bc78b4b42cc7dc0

Now you all can stop with your damn hacks and instead use a fixed version.

I don't know when it degraded but it WAS working.

And next time, why don't you guys actually HELP out and figure out the damn issue instead of spreading hack fixes.