HBM's Nuclear Tech Mod is a 1.7.10 Minecraft mod that has outgrown its own version

The main repository is pinned to Minecraft 1.7.10 on purpose

The first line of the project documentation is a warning, not a feature list: this is for 1.7.10. Everything else in the repository is built around that constraint, from the Java 8 toolchain to the Forge decompilation workspace that contributors are asked to set up.

The consequence is that the popular versions of this mod are not in this repository at all. The documentation points 1.12 players to NTM Community Edition, NTM Extended Edition and NTM Reloaded, and then lists further ports for 1.18.2, 1.20.1, 1.21.1 and 26.2, including NTM Remake, HBM Modernized, NTM Neo, NTM Decentralized and NTM NEXT. That is eight other projects to choose from, each in its own repository, and it is a fair signal that the demand for the newer versions outgrew the original's scope.

For an evaluator this is the whole decision. The main repository is the canonical 1.7.10 implementation and a mature one, since the last push was on 2026-10-19 and the repository is not archived. The forks are where the mass of players are. The project description, which calls itself a flaming wreck of a Minecraft mod about nuclear technology that is somehow still in development, is honest about the state of things.

Release assets ship a JAR and its sources side by side

The download path is short and worth understanding before you install anything. Navigate to Releases on the repository, and the links for the compiled JAR as well as the corresponding source code sit under the Assets category below the changelog. The documentation is emphatic that you should review all changelogs when updating, and given the version numbering that advice is not decorative.

The version scheme carries the history. The three most recent releases are 1.0.27_X5846 on 2026-10-12, 1.0.27_X5844 on 2026-10-10 and 1.0.27_X5842 on 2026-10-08, so the release name is the mod version plus a monotonically rising build counter, and a single 1.0.27 series produced three builds in one week. The Gradle example in the documentation uses the same shape, with the build number 5687 and a comment telling you to change that value to the release you want.

The assets also include source code for the exact build you downloaded. That is unusual for a Minecraft mod and it is useful: it means you can diff a release against your own tree when a behaviour changes, rather than guessing at what moved between builds.

Building from source means JDK8, Git Bash and a Gradle wrapper

The build tutorial is written for Windows, and the documentation says plainly that Linux users should know what to do by looking at the same guide. The requirements are JDK8 from adoptium.net, git from git-scm.com, and Git Bash as the shell.

Clone the repository first:

git clone https://github.com/HbmMods/Hbm-s-Nuclear-Tech-GIT.git

Then move into the source tree and let the wrapper do the work:

cd Hbm-s-Nuclear-Tech-GIT

./gradlew build

The build output lands in the build/libs directory, and you take the file named HBM-NTM-<version>.jar, which you install like any other mod by putting it into your mods directory. The repository ships a gradlew script and a gradlew.bat, plus build.gradle, gradle.properties, gradle/ and a curseforge.properties.example file, so the build itself does not require a system Gradle install.

One thing to expect: the repository also contains a gradle.properties and a set of source dependencies that mean a first build pulls a Forge toolchain and decompiles Minecraft. The documentation does not give a time or memory estimate for that step, and the setupDecompWorkspace task is listed separately for contributors who need the decompiled sources inside an IDE.

Using NTM as a Gradle dependency pins an exact build number

If you are writing your own mod and want NTM's blocks, items or machines in it, the project publishes artifacts to a Maven repository rather than requiring a manual JAR copy. The documented buildscript configuration adds a repository named NTM Releases pointing at maven.ntmr.dev, and the dependency block pulls two artifacts: an implementation dependency on the dev artifact and a compileOnly dependency on the src artifact.

dependencies {
		def ntmBuildNumber = "5687" // Change this value according to the release you wish to use

		implementation "com.hbm:HBM-NTM:1.0.27_X${ntmBuildNumber}:dev"
		compileOnly "com.hbm:HBM-NTM:1.0.27_X${ntmBuildNumber}:src"
}

The build number is a string you have to set by hand, and the comment is explicit that it must match the release you want. The pair of classifiers, dev and src, is the notable design choice: the dev artifact is what your mod compiles and runs against, and the src artifact exposes sources for navigation. Nothing in the documentation explains what happens when the number you pick is missing from the repository, so a typo produces a resolution failure rather than a friendly error.

This path is a real advantage over the manual JAR approach, and it is the one most developers working with the 1.7.10 mod will care about.

Contributors decompile Forge into their own working copy

The contributing guide is where the fork workflow becomes concrete, and it is unusual in a way worth flagging. Instead of forking on the hosting site, you clone the repository, download the Forge src for 1.7.10 from files.minecraftforge.net and extract it into a directory whose name is not Hbm-s-Nuclear-Tech-GIT, then move every file from the clone into that directory, overwriting as you go.

The next step is the Forge decompilation workspace:

./gradlew setupDecompWorkspace

Eclipse users have one more command, which generates the IDE project files:

./gradlew eclipse

After that, the guide spends a long stretch on pointing Eclipse at the right JDK, with the Linux path /usr/lib/jvm, the Windows JAVA_HOME variable, and the instruction to select the JavaSE-1.8 execution environment and pick the JRE marked as a perfect match.

This is a heavy setup for a first contribution, and it explains a lot about the shape of the surrounding ecosystem. When the base version is a decade old and the tooling is pinned, forking a copy of the whole project and updating it becomes more practical than extending the original, which is what the list of community editions is really about.

Weapons animate from JSON and OBJ, with Blender addons in tools

The animation pipeline is the one part of the repository where the tooling is described in enough detail to be reproducible. Weapon animations in NTM are stored as JSON files used alongside OBJ models, which the documentation frames as a way to get high quality animations with reasonable file sizes rather than baking them into the model or into code.

For the pipeline to work you need the model and the animation data to line up, so the repository includes import and export Blender addons for versions 2.79, 3.2 and 4.0, located in the tools directory. The documentation notes that they should function reasonably well in newer Blender versions as well, and points to the comments in the header of the export scripts for usage instructions.

The top-level layout supports this: src for the mod code, tools for the Blender addons, a changelog directory, a TODO.txt, and a .github directory. Nothing else in the repository is described at this level of detail, which is a fair indicator of where contributors are expected to need the most help.

NTM crashes Thermos servers on purpose and warns about shaders

The compatibility notice lists behaviours that patch vanilla code, and it is honest about the risk. The Thermos server mod, along with forks such as Crucible, has a performance feature that slows down all tile entity ticking when no player is in the same chunk. In a mod whose content is largely multi-block machines, that means the machines appear to stall, and the symptom is hard to diagnose if you do not know the feature exists.

NTM's response is deliberately blunt. By default the mod crashes on servers running Thermos base code and prints a lengthy message at the top of the crash log explaining the performance feature and how to fix the issues it causes. The documentation notes that failure to read, and understand, that message leaves the server inoperable. A crash on purpose is a defensible choice for a mod where silent slowdown would corrupt machine behaviour, but it does mean NTM and Thermos are not a combination you can run without changing a setting.

The shaders entry is truncated in the documentation, so the specific behaviours there are not confirmed here. The structure of the section makes clear that the list is expected to grow as the project patches more vanilla behaviour, and the documentation states that no cases of these behaviours clashing with other mods are currently known.

Licensing is GPL-3.0, with a LICENSE and a LICENSE.LESSER file at the root. That is a strong copyleft licence, and it carries obligations for anyone who distributes a modified build of the mod or incorporates its code into a larger work. The documentation does not offer any legal guidance on how those terms apply to a derived modpack.

Editorial conclusion

NTM fits players and modpack builders still running Minecraft 1.7.10 who want nuclear industry machinery in a long-lived world, and it fits developers who want to contribute to a Java mod with a real multi-year commit history. It does not fit anyone on a modern Minecraft version, since the main repository targets 1.7.10 only and the newer versions live in separate community forks. Before adopting it, download the pre-compiled JAR from the Releases assets rather than assuming a build will work on your machine, read the changelog for the build you are taking, and check the compatibility notice about Thermos servers and shaders, because those are the two cases the project itself warns about.

Frequently asked questions

Official sources

1. HbmMods/Hbm-s-Nuclear-Tech-GIT on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases