[1.14.4] Remove vanilla crafting recipes?

[Azaka7]

I'm using the 28.0.45 mdk, the rest of my mod is working fine. I'm just looking for a way to remove vanilla recipes.

 

The recipe is in iron_chestplate.json

{
  "type": "minecraft:crafting_shaped",
  "pattern": [
    "X X",
    "XXX",
    "XXX"
  ],
  "key": {
    "X": {
      "item": "minecraft:iron_ingot"
    }
  },
  "result": {
    "item": "minecraft:iron_ingot",
    "count": 8
  }
}

I have more un-recipes, but I figured I'd get just this one working first. Ideally, the output would be air, or nothing.

It was working in 25.0.100 (for 1.13.2), but after updating it doesn't. (I had a custom serializer to toggle the recipes from the config file, but now a simple override doesn't seem to work.)

 

I've tried in the following locations within src/main/resources:

assets.minecraft.recipes

assets.warforge.recipes

data.minecraft.recipes

data.warforge.recipes

 

None of them seemed to work. In all cases, the recipe crafted a chestplate, which I'm trying to disable. While in the data.warforge.recipes folder, I tried using to command to enable the recipe in-game, but the vanilla recipe still won over.

 

What am I missing? Is there a way to override vanilla recipes without a separate data pack to install?

 

EDIT:

I got recipe overrides to work by putting the recipes in data.[modid].recipes with the following solution of sorts:

 

 

So I found something. I don't have any clue how it makes any sense, other than the "warforge" ID seems to be cursed. I did a clean install of the mdk and started testing mod IDs on the example mod after putting some recipes in the right locations.

 

Other than "warforge" and "example mod", I tested "mhmod", "mjmod", "rmod", and "exampleforge", all in the clean install.

 

ALL of them were able to replace the vanilla recipes EXCEPT "warforge". I want to do more testing because so far I haven't seen a pattern.

Edited August 15, 2019 by Azaka7

[Draco18s]

I haven't messed with it in 1.14, but you should be able to write a new recipe (with the same name) that lives at data.minecraft.recipes and it'll override the vanilla one.

 

Not the same ingredients, the same name. SO to overwrite the chestplate you'd have to have a chestplate.json recipe with different ingredients/result.

[Azaka7]

The recipe is already named the same as the iron chestplate recipe (that is, iron_chestplate.json) in data.minecraft.recipes, and it isn't overriding the vanilla recipe. I tried changing the pattern, but it didn't work. When I moved one of my normal crafting recipes to data.minecraft.recipes, it still registered as a new recipe, so it's not like the game is ignoring the location. I'm thinking it might somehow be a problem with forge itself.

[Draco18s]

Could be. Open an issue on their git.

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

[Azaka7]

4 hours ago, Draco18s said:

Could be. Open an issue on their git.

 

Thanks. I did that and Lex gave it the "Forum" label, so I guess it's stuck here for now.

[Draco18s]

No, it said create a thread in Support & Bug Reports.

I'm not sure why Lex decided that that should happen, but there you go.

[LexManos]

DO NOT send people to the github issues or suggestions forum for basic shit like this.

As far as I know data packs load just fine. If they do not you need to provide exact use cases because 99% of the time, you fucked up.

Be it the json syntax.

Be it file placement.

Whatever it is, MOST of the time it's end user error.

So, if you THINK you have a bug, track it down, provide a reproduction case. And we can help you.

In this case it looks like you're throwing the recipes all over the place and not actually overriding the vanilla one.

Which of coarse wont work because there is NO sorting when it comes to recipes, the first one to hit will be the one used. So if both recipes exist in conflicting states, then it'll use the first one.

[Azaka7]

Thanks for the reply Lex. As I said in my post, it WAS working in 1.13. I understand there were changes, and I've solved them for the rest of my mod. My only problem is that after moving to 1.14.4, the recipes were no longer overriding the vanilla ones. I only started "throwing recipes all over the place" to see if the correct location had changed. Logically, the recipe should be in data/minecraft/recipes, but that doesn't seem to work.

 

You're correct that normal data packs work if installed in the world folder. My problem is that it seems like Forge isn't stacking my mod's data pack on top of vanilla recipes without installing the mod in both the mods folder AND the world folder (something that shouldn't be necessary).

 

I'll try to put together a reproduction case for the problem I'm having if I can't get it to work in the next week. That being said, I would love to see Forge implement a system where mod resources override Minecraft resources all the time, rather than just seeing which resource his first. (There was another issue with overriding a vanilla texture, which was fixed-ish be making my mod's resource pack visible and moving it over Minecraft's pack.)

[LexManos]

Forge DOES have a system where mod's are added as resource/data packs after Vanilla so they override their entries.

Again provide valid repro case and we can figure out the issue, as all our tests work just fine.

[Azaka7]

So I found something. I don't have any clue how it makes any sense, other than the "warforge" ID seems to be cursed. I did a clean install of the mdk and started testing mod IDs on the example mod after putting some recipes in the right locations.

 

Other than "warforge" and "example mod", I tested "mhmod", "mjmod", "rmod", and "exampleforge", all in the clean install.

 

ALL of them were able to replace the vanilla recipes EXCEPT "warforge". I want to do more testing because so far I haven't seen a pattern.

 

Edit:

Another mod id that doesn't work is "watforge". However, the following do work:

watercraft, warcraft, abcforge, catforge (don't judge), wipforge, airforge.

 

I'm done. Just giving up on this and changing to a new mod ID. At this point I just don't understand.

Edited August 15, 2019 by Azaka7

[Azaka7]

I found what was wrong, and it WASN'T my mod. FML Ships with the "Forge" mod, which has its own data pack resources. Among these resources are crafting recipes that make vanilla recipes use item tags to work with other mods' items. It turns out that in some (not all) cases, the Forge recipes were overriding my mod's own files that would remove vanilla crafting of armors.

 

My solution for now is to reload my mod's resources on world load. Here's my solution:

    @SubscribeEvent
    public void onServerStarting(FMLServerStartingEvent event) {
        LOGGER.info("Artimancy is unregistering it's own data pack so that Forge will reload it and override every other datapack.");
    	MinecraftServer server = event.getServer();
        server.getCommandManager().handleCommand(server.getCommandSource().withPermissionLevel(2), "datapack disable \"mod:artimancy\"");
    }

 

After disabling my mod's data pack, Forge Mod Loader is so kind as to reload them over every other data pack (namely, the Forge data pack). Ideally, I shouldn't have to do this. Ideally, FML should prefer other mods' resources over Forge's resources, since Forge is the "default" mod that ships with FML.