Troubleshooting

In-game commands

RemapIDs ships two inspection commands. They work for any player, no op required.

`/remapids id block`

Shows the registry ID of the block you are looking at (up to 5 blocks away), including remap information:

/remapids id block

Block: create:brass_block (Remapped from: silents_mechanisms:copper_block)

If nothing is in range you get No block in range.

`/remapids id hand`

Same for the item in your main hand:

/remapids id hand

Item: othermod:silver_ingot (Remapped from: iceandfire:silver_ingot)

The output has two possible annotations:

(Remapped from: ...) means the ID you are holding or looking at is the target of one or more remaps. This is what you see when a remap is working.
(Remaps to: ...) means the ID is a source with an active remap pointing elsewhere. You will mostly see this on IDs that are only remapped for reloadable types, where the original item still exists.

An ID with no annotation is not involved in any remap. If you expected one, check the log messages below.

Reading the log

RemapIDs logs everything it does with a [RemapIDs] prefix. The messages worth knowing:

Message	Meaning
`Remap target '...' not found in ... registry yet (may be a modded ID not registered at this point), remap from '...' will be attempted at freeze time`	Usually harmless. Mods register content after remap files are read, so modded targets often trigger this. The remap is retried once all registration is done and only fails if the target still does not exist then.
`Injected N <type> registry aliases`	Success. N source IDs now resolve to their targets in that registry.
`Remapped N block state IDs for M block aliases`	Success for block remaps; placed-block state IDs were redirected.
`Not re-keying recipe A -> B: a recipe with that id already exists`	A remap tried to rename recipe `A` to `B`, but a recipe `B` already exists. The re-key is skipped so the existing recipe is not overwritten. The remap still applies to ingredients and results inside other recipes.
`Circular remap detected involving: [...]`	Your entries form a loop (`A` to `B`, `B` to `A`). The chain is rejected. Break the loop in your config.
`Unknown numerical ID: '...' (not found in flattening table — may be a modded ID)`	A numerical source is not in the vanilla flattening table. If it came from an old mod, add it to `config/remapids/numerical_ids.json`.
`Loaded custom numerical IDs: N blocks, N items from numerical_ids.json`	Your custom numerical table was read and merged.

Common problems

My remap does nothing

Work through these in order:

Is the file in the right place? Remap files go in config/remapids/remaps/, not in config/remapids/ directly.
Is the JSON valid? A syntax error makes the file unreadable. Run the file through any JSON validator; the log will also complain at startup.
Did you restart? Registry types (block, item, fluid, entity_type) only apply on a full game restart. /reload covers only recipe, loot_table, and tag.
Does the target exist? Run /remapids id hand while holding the intended target item. If the ID does not match what your file says, the remap can never resolve.
Check the log for the not found ... at freeze time warning appearing twice, which means the target genuinely does not exist in this instance.

Wildcard remap matches nothing

Both source and target must contain *. A wildcard pair is only applied where the substituted target ID actually exists, so verify the two mods really use parallel naming (silver_ore on both sides, not silver_ore and ore_silver).

Remaps to modded or KubeJS IDs fail on NeoForge

Fixed in 1.3.1. Older builds finalized aliases before mod content was registered on NeoForge 1.21.1, which broke wildcard matching and modded targets. Update the mod.

A recipe disappeared after remapping

If a remap re-keys recipe IDs and the new ID collides with an existing recipe, the re-key is skipped (see the log message above) and both recipes keep working since 1.3.1. On older versions the collision silently replaced the existing recipe; update if you see this.