Links
Tags
Creators
Details
V1.0.2-NeoForge
Compatibility
Changes
Patch release on top of V1.0.1. Closes the remaining intentional regressions documented in V1.0.1's PORT_NOTES - verified in-game both standalone and inside a 95-mod modpack. After V1.0.2 the port has exactly one divergence from upstream 1.20.1-2.0.5, and that one was already broken upstream.
What's new in V1.0.2
- Per-item furnace burn times for charred wood are working: log → 1600t, planks → 400t, slab/stairs/fence/fence_gate → 200t. The previous build's data-map JSON was at the wrong namespace path and silently ignored - NeoForge resolves built-in data maps by their map ID, so for neoforge:furnace_fuels the file has to live at data/neoforge/data_maps/item/furnace_fuels.json.
- Ice Sickle damage / attack speed restored (+5 / -1.0). NeoForge 1.21.1's SwordItem(Tier, Properties) no longer auto-attaches attribute modifiers, so they're pre-baked on Properties via SwordItem.createAttributes(...) before the constructor delegates to super.
- Trident Channeling on Fulgurite restored - lightning fires on Channeling-enchanted hits during a thunderstorm with sky access. Channeling lookup ported to the data-driven 1.21 form (Holder<Enchantment> via the level's RegistryAccess, gated through EnchantmentHelper.getItemEnchantmentLevel).
- Leaf-decay particles + sound restored. SendCustomParticlesPacket now implements Moonlight 2.29's Message interface and is registered as a client-bound payload via NetworkHelper.addNetworkRegistration. Client-side particle/sound logic isolated to a sibling class so dedicated servers don't link Minecraft.
- Vanilla minecraft:hanging_roots wall placement restored on a vertical surface. NeoForge 1.21's RegisterEvent can't replace existing item registrations the way Forge 1.20.1 did, so the upstream CeilingAndWallBlockItem registry-override is replaced with a hangingRootsWallPlacement entry in the ModEvents.onBlockCLicked chain. Wall placement runs the same getNearestLookingDirections selection logic as upstream; ceiling placement falls through to vanilla unchanged.
- Brick tag migrated from legacy forge:ingots/brick to community-standard c:bricks. Other 1.21+ mods that read c:bricks will now find the four IW bricks (deepslate, stone, end stone, blackstone). PORT_NOTES corrections - two entries previously listed as "intentional regressions" turned out to be inaccurate: the five codec dispatch chains had already been correctly migrated to MapCodec in V1.0.0 (not stubbed), and Charred.interactWithProjectile has never had an implementation in any upstream branch (1.18.2 / 1.19.2 / 1.20.0 multiloader / Inferno all checked).
- The no-op default matches upstream runtime behaviour and is the only remaining intentional divergence.
Required dependencies, license, and known divergences from upstream are unchanged from V1.0.1 - see the V1.0.0 changelog or META-INF/PORT_NOTES.md inside the jar for those.
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:AtjxBimt:OTBT0bny"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:AtjxBimt:OTBT0bny"
}

