Tags
Creators
Details
Licensed GPL-3.0-only
Published 7 months ago
Updated 2 months ago
All versions
1.3.1+neoforge-1.21.1
Release
RemapIDs 1.3.1 (NeoForge 1.21.1)4 months ago 691
Compatibility
Minecraft: Java Edition
1.21.1
Platform
NeoForge
Supported environments
Changes
1.3.1
Fixed
- Modded registry IDs not remapped on NeoForge (#5, #6) — On NeoForge 1.21.1, mods are constructed before vanilla bootstrap, and bootstrap freezes the builtin registries before any
RegisterEventfires. TheMappedRegistry.freeze()hook therefore ran against vanilla-only registries: wildcard patterns matched nothing, modded targets (including KubeJS-created IDs) were "not found", and aliases injected for modded source IDs were clobbered when the real entry registered later. Finalization and alias injection are now triggered fromFMLLoadCompleteEvent(mirroring the Forge 1.20.1 fix from 1.3.0), which fires afterGameData.freezeData()when all mod content is registered. This also fixes wildcard remaps for modded item/block IDs. - Recipe re-keying could overwrite existing recipes (#5) — Re-keying a recipe ID to a target that already exists (e.g. an entry without a
typesfilter remappingaether:skyroot_stick → minecraft:stickwhile aminecraft:stickrecipe exists) silently replaced the existing recipe. Colliding re-keys are now skipped with a warning, on all loaders.
Changed
- Entries without a
typesfilter no longer attempt registry aliases for registries that don't contain the target — a typeless item remap previously produced "target not found in block/fluid/entity_type registry" warnings and pointless alias attempts. A typeless entry whose target exists in no registry at all now logs a single warning instead.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:LS9KUmOO:8yrUjwOA"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:LS9KUmOO:8yrUjwOA"
}

