Examples
Each example below is a complete file you can drop into config/remapids/remaps/ and adapt. If a scenario involves registry types (block, item, fluid, entity_type), restart after editing; recipe, loot table, and tag changes also apply on /reload.
Remove a mod without breaking worlds
Section titled “Remove a mod without breaking worlds”You shipped Silent’s Mechanisms, you are dropping it, and Create covers the same ground. Without remaps, every placed machine block and every stored ingot from the removed mod disappears from existing worlds. With them, world content converts in place:
{ "remaps": [ { "source": "silents_mechanisms:copper_ingot", "target": "create:brass_ingot", "types": ["item", "recipe", "loot_table", "tag"] }, { "source": "silents_mechanisms:copper_block", "target": "create:brass_block", "types": ["item", "block", "recipe", "loot_table", "tag"] } ]}The ingot only needs item plus the data types. The block gets both item and block because it exists as a placed block in the world and as an item in inventories. Recipes from other mods that used the old IDs as ingredients keep working, loot tables that dropped them now drop the replacement, and tag membership carries over.
Consolidate duplicate materials
Section titled “Consolidate duplicate materials”Three mods each register their own silver ingot and your recipe book is a mess. Pick a canonical one and redirect the rest:
{ "remaps": [ { "source": "modone:silver_ingot", "target": "canonical:silver_ingot" }, { "source": "modtwo:silver_ingot", "target": "canonical:silver_ingot" } ]}No types filter here: each entry applies everywhere the target exists. Ores that smelt into modone:silver_ingot now produce the canonical one, and machines that ask for modtwo:silver_ingot accept it. Unlike recipe-unification datapacks, this also converts ingots already sitting in chests.
Replace vanilla content
Section titled “Replace vanilla content”Remaps are not limited to modded IDs. To make a pack where brass replaces copper outright:
{ "remaps": [ { "source": "minecraft:copper_block", "target": "create:brass_block", "types": ["item", "block"] }, { "source": "minecraft:copper_ingot", "target": "create:brass_ingot", "types": ["item"] } ]}Newly generated and already placed copper blocks resolve to brass blocks, and copper ingots in any inventory become brass. The types filter deliberately leaves out recipe, loot_table, and tag here; widen it if you also want recipes that produce copper to produce brass instead.
Remap a whole ID family with wildcards
Section titled “Remap a whole ID family with wildcards”When a mod uses consistent naming, one wildcard entry covers the entire family:
{ "remaps": [ { "source": "iceandfire:silver_*", "target": "othermod:silver_*" } ]}The * must appear in both source and target. Whatever it matches in the source is substituted into the target: silver_ore to silver_ore, silver_nugget to silver_nugget, and so on. Pairs whose substituted target does not exist are skipped, so a family mismatch cannot remap anything into a void.
Redirect a tag
Section titled “Redirect a tag”Tag sources take a # prefix. To make everything that looks for silver ore find tin ore instead:
{ "remaps": [ { "source": "#forge:ores/silver", "target": "#forge:ores/tin", "types": ["tag"] } ]}Recipes and other systems that reference #forge:ores/silver now effectively read #forge:ores/tin.
Replace a tag ingredient with a specific item
Section titled “Replace a tag ingredient with a specific item”A #-prefixed source can target a plain item under the recipe type. RemapIDs then rewrites tag ingredients into item ingredients inside recipe JSON:
{ "remaps": [ { "source": "#forge:ingots/gold", "target": "minecraft:diamond", "types": ["recipe"] } ]}Every recipe ingredient written as {"tag": "forge:ingots/gold"} becomes {"item": "minecraft:diamond"}. Use this when you want to narrow a permissive tag ingredient down to one specific item without editing each recipe.
Migrate a pre-1.13 world
Section titled “Migrate a pre-1.13 world”Worlds from before the flattening store numerical block IDs. RemapIDs ships the vanilla flattening table, so numbers work directly as sources:
{ "remaps": [ { "source": "35:14", "target": "minecraft:red_wool", "types": ["block"] } ]}35:14 (wool with red metadata) resolves through the flattening table and remaps to minecraft:red_wool. Bare numbers work too; 35 is treated as 35:0. For modded numerical IDs that the vanilla table cannot know about, add your own entries to config/remapids/numerical_ids.json, described in Advanced.