Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/hbmmods/hbm-s-nuclear-tech-git/llms.txt

Use this file to discover all available pages before exploring further.

HBM’s Nuclear Tech Mod welcomes outside contributions — bug fixes, new content, localization, wiki articles, and more. That said, the project follows firm quality standards to keep the codebase maintainable and the review process sane. A PR that ignores these guidelines is almost certain to be closed without merge, no matter how much work went into it. Read this page in full before opening your first pull request; a little upfront investment here will save both you and the maintainer a lot of time.

​
Pull Request Principles

​
Keep it concise

The best PRs are small and laser-focused. Every change in a PR should relate directly to the single fix or feature you are adding. If you are implementing the Super Weldtronic 9000 and you notice an unrelated bug while doing so, open a separate PR for the bug. Mixing unrelated changes bloats diffs, complicates review, and increases the chance of introducing regressions.

​
Keep it clean

The codebase is not perfect, but please do not make it worse. Avoid:
  • Unused variables and imports — compilers warn about these for a reason.
  • Mixed indentation styles — match the style of the file you are editing (tabs).
  • New libraries — unless your PR absolutely requires a library for special mod compatibility, do not add new dependencies.
  • Duplicate utility functions — check whether a helper already exists before writing a new one.
  • Unfinished or broken features — do not submit a half-implemented system on the assumption that someone else will finish it.
  • Changelog updates — you will create a merge conflict every time; leave the changelog to the maintainer.
  • I18n usage — NTM uses a custom wrapper. See the Code Style section below.

​
No guarantee of merge

Following these guidelines gives your PR a good chance of being accepted, but there is no guarantee. The maintainer has final say on what goes into the mod. Do not interpret a rejection as a personal attack — it is usually a matter of scope or design direction.

​
Testing Requirements

Testing on both a client and a server is mandatory — not optional. A PR that has only been tested in single-player will not be accepted. If your PR adds compatibility code for another mod, the game must function correctly with and without that mod installed.
This policy exists because client-only testing misses a huge class of bugs: server-side NPEs from missing @SideOnly guards, crashes in dedicated server mode from rendering code being called on the logical server, and desync issues that only manifest in multiplayer. Before opening a PR, verify the following:
  1. The feature or fix works in single-player (integrated server + client).
  2. The feature or fix works on a dedicated server with a separate client connecting to it.
  3. If the PR touches compat code, the game loads cleanly without the target mod installed, and the compat functionality activates correctly when the mod is present.

​
No Refactor PRs

Refactor PRs will not be accepted. Wholesale refactoring of existing code tends to break things in subtle ways, and the risk-to-reward ratio is not worth it. If you want to improve code quality, make incremental improvements alongside actual feature or fix work in a well-scoped PR.

​
Communication First

If you are planning a substantial new feature or a far-reaching change, discuss it before writing a single line of code. Post in the project’s Discord or open a GitHub issue describing what you want to do and why. This takes 10 minutes and can save you from spending 50 hours on work that turns out to conflict with planned development, violates a design principle, or duplicates something already in progress.

​
Code Style

NTM targets Java 8. Do not use language features from Java 9 or later. Always use I18nUtil — never I18n directly. The vanilla net.minecraft.util.StringTranslate/I18n class has quirks that I18nUtil works around. Using I18n directly is listed as a prohibited practice in the contribution guidelines and will result in changes being requested. 
// ✅ Correct
import com.hbm.util.I18nUtil;
String label = I18nUtil.resolveKey("container.my_machine.title");

// ❌ Prohibited
import net.minecraft.util.StatCollector;
String label = StatCollector.translateToLocal("container.my_machine.title");
Keep all code compatible with Java 8 syntax and semantics. sourceCompatibility and targetCompatibility are both set to 1.8 in build.gradle, so the compiler will catch outright syntax violations, but be mindful of API usage as well.

​
Where to Start

Not sure where to contribute? Here are areas that are always open to help, roughly ordered from easiest to most complex:

​
Wiki articles

The Official NTM Wiki is the best place to start if you are not yet comfortable with the codebase. Writing or improving an article requires no programming knowledge and immediately benefits the player community. Every machine, material, or mechanic that lacks documentation is a potential contribution.

​
Translations / Localization

Language files live under src/main/resources/assets/hbm/lang/. Translations in any language are welcome. Active languages with existing contributors include:
LanguageCode
Russianru_RU
Chinese (Simplified)zh_CN
Polishpl_PL
Italianit_IT
Copy en_US.lang as a starting point and translate the values. If a language file already exists, compare it against en_US.lang to find missing keys added in recent builds.

​
IConfigurableMachine implementations

IConfigurableMachine is an interface that allows machines to be configured via the external hbmMachines.json file, giving server operators and pack authors fine-grained control over recipes and machine behavior without needing to modify code. Many machines in the mod do not yet implement this interface. Picking a machine and wiring up IConfigurableMachine support is a well-scoped, testable, and appreciated contribution.

​
F1 Presentations (Stare / Jar Presentations)

F1 Presentations — also called Stare Presentations or Jar Presentations — are short in-game movies that play when a player presses F1 while looking at a machine, explaining its functionality. All relevant code lives in the com.hbm.wiaj package: 
src/main/java/com/hbm/wiaj/
├── FauxWorld.java          – lightweight world stub for the presentation scene
├── GuiWorldInAJar.java     – GUI container for the presentation renderer
├── JarScene.java           – scene graph root
├── JarScript.java          – scripting / sequencing API
├── WorldInAJar.java        – core presentation engine
├── actions/                – scriptable actions (camera moves, text overlays, etc.)
├── actors/                 – in-scene objects (blocks, items, entities)
└── cannery/                – pre-built presentations for existing machines
Pick a machine that lacks a presentation and write one using the existing entries in cannery/ as a reference. This is a creative task that combines a little Java with a lot of storytelling.

​
Machine tooltips

Many machines display no tooltip text when hovered in the inventory. Adding descriptive tooltips that explain power consumption, processing speed, or unique mechanics makes the mod much more accessible to new players. This typically requires only a few lines of code in the item or block class.

​
Contribution Checklist

Before opening your PR, verify each item:
  • The PR is focused on a single fix or feature.
  • No unused variables, imports, or dead code are present.
  • No new libraries have been added (unless strictly necessary and discussed).
  • The feature has been tested on a dedicated server and on a client.
  • Compat code has been tested with and without the target mod.
  • I18nUtil is used instead of I18n / StatCollector everywhere.
  • The changelog file has not been modified.
  • Grand design changes were discussed before implementation.

Build docs developers (and LLMs) love

Get started for freeTalk to us