| Mod | Recipe ID | Type | Status | Actions |
|---|
Build a new recipe
| Mod | Loot Table ID | Category | Status | Actions |
|---|
Pending changes
Datapack settings
What this tool actually does
Fabric doesn't need a compiled mod to override another mod's recipes or loot tables — vanilla's own datapack system already does that: if a datapack loaded after a mod's built-in data defines a file at the exact same path (e.g. data/minecraft/recipe/diamond_sword.json), the later one wins. This tool scans every jar in your mods folder, lets you browse/edit/remove/add those files with a UI, and packages the result into a ready-to-use datapack — no Java, no compiling, no Fabric API needed.
Removing a recipe
Vanilla has no "delete" instruction for a single recipe file. The standard trick (used by most recipe-removal datapacks) is to overwrite the file with an empty JSON object {}. Minecraft fails to parse it as a recipe, logs a harmless warning, and simply never registers it — so it disappears from crafting and the recipe book. This tool does that automatically when you hit "Remove".
Restricting where things spawn/drop (loot tables)
Loot tables support a minecraft:location_check condition that can require a specific biome, structure, or dimension before a pool/entry is granted. In the Loot Tables tab, open any table and use "Add location condition" to attach one to a pool — e.g. make an ore's extra drop only happen in the minecraft:deep_dark biome, or a mob's rare drop only occur in the Nether.
Item icons
Mod jars bundle their own item textures, so icons for modded items appear automatically once you load your mods folder. For icons on vanilla items (sticks, diamonds, etc.) — and to also browse/override vanilla's own recipes and loot tables — click Add Vanilla / Extra Jar and pick your client jar, usually at .minecraft/versions/<version>/<version>.jar (e.g. .minecraft/versions/1.21.1/1.21.1.jar). Everything stays on your machine — nothing is uploaded.
Mob drops
These are just loot tables under data/<namespace>/loot_table/entities/<mob>.json — same editor, filter by "Mob drops" category.
Load order
Datapacks generated by this tool load automatically after the mods (mod-builtin data always loads first, then world datapacks by their listed order — newest/last added generally wins), so your overrides apply. If something doesn't seem to override, check /datapack list in-game and make sure your pack is enabled and positioned after the mod's pack.
Fabric, Forge, NeoForge, and different Minecraft versions
Datapacks aren't tied to a mod loader — a Fabric mod, a Forge mod, and a NeoForge mod all ship their recipes and loot tables in the exact same data/<namespace>/… layout, because that's vanilla Minecraft's own format, not something each loader invents. So this tool scans and generates the same way regardless of which loader the jars came from, and the exported pack works on any of them. Two things do genuinely change by Minecraft version, which is why there's a version picker in the Export tab: the recipe/loot-table folder got renamed from plural to singular in 1.21 (handled automatically), and the pack_format number in pack.mcmeta changes every version or two — pick the version your instance actually runs.
One Forge/NeoForge-specific quirk: some Forge mods wrap a recipe in a forge:conditional (or neoforge:conditional) block that only applies it if certain mods/items are present. The Item Recipes tab automatically unwraps these to show you the actual recipe inside; when you Edit one, you're editing the real inner recipe, but keep in mind that overwriting the whole file removes the conditional check too (usually fine, but worth knowing if that mod ships several alternate versions of the same recipe).