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 registers several commands through Forge’s server-side command system. These commands give server operators and developers direct control over radiation data, the live config system, JSON recipes, orbital satellites, power networks, and packet threading — all without requiring a server restart. Unless explicitly noted otherwise, each command listed here inherits the default Forge CommandBase permission level of 4 (operator / op), meaning only players with op status (or the server console itself) can run them. The one exception is /ntmcustomize, which is intentionally open to all players.
All commands can be run from the server console as well as in-game. Console input is always treated as having the maximum permission level regardless of the getRequiredPermissionLevel value.

​
Radiation

Manages chunk-level radiation data stored by ChunkRadiationManager.Permission level: 4 (operator)Syntax:
/ntmrad set <amount>
/ntmrad clear
SubcommandArgumentsDescription
set<amount> (float, 0–100000)Sets the radiation level at the command sender’s current coordinates.
clear(none)Clears all radiation data for the current world.
/ntmrad clear removes all radiation from the entire world immediately and cannot be undone. Use with caution on survival servers.
Examples:
/ntmrad set 500
/ntmrad clear
The set subcommand places radiation at the sender’s exact block position, which ChunkRadiationManager then distributes across the surrounding chunk area according to its normal decay rules.

​
Configuration & Recipe Reload

The three commands below share a common base class (CommandReloadConfig) that provides a consistent list / reload / get / set interface for live-editable config variables. Tab completion is supported for all subcommands and variable names.
Reads and writes client-side configuration variables at runtime without requiring a game restart. This command is registered as a client command via ClientCommandHandler, so it is only available in single-player or from the client side of an integrated server — it cannot be run from a dedicated server console.Permission level: Available to any player (client-side command).Syntax:
/ntmclient help [<subcommand>]
/ntmclient list
/ntmclient reload
/ntmclient get <name>
/ntmclient set <name> <value>
SubcommandDescription
help [<subcommand>]Prints usage for all subcommands, or detailed help for a specific one.
listDisplays all client variable names and their current values.
reloadRe-reads all client variables from the config file on disk.
get <name>Prints the current in-memory value for the named variable.
set <name> <value>Updates the named variable and saves it to the config file immediately.
Selected client variables:
VariableTypeDefaultDescription
RENDER_REEDSBooleantrue (auto false with Angelica)Renders the underwater portion of NTM reeds. Disable to work around the Angelica Compact Vertex Format issue.
GUN_ANIMS_LEGACYBoolean—Switches gun animations to the legacy style.
GUN_MODEL_FOV——Controls the field-of-view used for gun model rendering.
GUN_VISUAL_RECOILBoolean—Enables or disables visual recoil on guns.
RENDER_CABLE_HANGBoolean—Toggles cable sag/hanging rendering.
NUKE_HUD_FLASHBoolean—Toggles the screen flash effect on nuclear detonations.
NUKE_HUD_SHAKEBoolean—Toggles screen shake on nuclear detonations.
DODD_RBMK_DIAGNOSTICBoolean—Shows the RBMK DODD diagnostic overlay.
COOLING_TOWER_PARTICLESBoolean—Toggles cooling tower steam particles.
Example — disable reed rendering for Angelica compatibility:
/ntmclient set RENDER_REEDS false
Reads and writes server-side configuration variables at runtime. This command is registered on the server and is available to operators in-game only. The canCommandSenderUseCommand override returns false for non-player senders, so the server console cannot use this command.Permission level: 4 (operator), player senders only (console input is rejected).Syntax:
/ntmserver help [<subcommand>]
/ntmserver list
/ntmserver reload
/ntmserver get <name>
/ntmserver set <name> <value>
SubcommandDescription
help [<subcommand>]Prints usage for all subcommands, or detailed help for a specific one.
listDisplays all server variable names and their current values.
reloadRe-reads all server variables from the config file on disk.
get <name>Prints the current in-memory value for the named variable.
set <name> <value>Updates the named variable and saves it to the config file immediately.
Changes made with set take effect immediately in memory and are written to disk, persisting across restarts. Use reload to pull in edits made directly to the config file while the server is running.
Reloads all of NTM’s data-driven content without restarting the server. This includes JSON machine recipes, item pool configurations, fluid definitions, fluid container registrations, damage resistance tables, and logic block action/condition/interaction definitions.Permission level: 4 (operator, default CommandBase level)Syntax:
/ntmreload
The command takes no arguments. On success it prints Reload complete :) in yellow. On failure it prints the exception message and the first stack frame to chat, and re-throws the exception so the full trace appears in the server log.What gets reloaded:
  • FluidContainerRegistry — cleared and re-registered
  • Fluids — fluid definitions re-initialised
  • SerializableRecipe — all JSON machine recipes re-parsed
  • ItemPoolConfigJSON — loot pool configs re-parsed
  • DamageResistanceHandler — resistance tables re-loaded
  • LogicBlockActions, LogicBlockConditions, LogicBlockInteractions — structure logic re-initialised
This command is useful when developing custom recipes or testing config changes. It does not reload GeneralConfig or other Java-level configs; use /ntmserver reload for those.

​
World & Structure Tools

Locates the nearest NTM NBT structure of a given name relative to the calling player’s position. The search spirals outward up to a maximum radius of 256 chunks (4096 blocks).Permission level: 4 (operator, default level). Must be run by a player — the command rejects console input with a PlayerNotFoundException.Syntax:
/ntmlocate structure <name>
/ntmlocate list
SubcommandArgumentsDescription
structure<name>Searches for the nearest occurrence of the named structure and reports its block coordinates.
list(none)Prints the names of all registered NTM structures.
Tab completion is available for structure names after the structure keyword.Example output (success):
Found nearest bunker at 1024, -512
If no matching structure is found within 256 chunks the command reports commands.locate.none_found. If the name does not match any registered structure it reports commands.locate.no_match.
The structure search reads generation metadata, not the live world. It will report positions where the structure should have been generated according to world-gen rules, which means it works even on chunks that have not yet been loaded and rendered.

​
Satellite Management

Manages the orbital satellite registry stored in SatelliteSavedData. NTM satellites are items that implement the ISatChip interface; once in orbit they are tracked by frequency and type.Permission level: 4 (operator, default level). Must be run by a player.Syntax:
/ntmsatellites orbit
/ntmsatellites descend <frequency>
/ntmsatellites list
SubcommandArgumentsDescription
orbit(none)Launches the satellite item currently held in the player’s main hand into orbit. Consumes one item from the stack. The item must implement ISatChip and must not be a blank sat_chip.
descend<frequency> (integer)Removes the satellite registered at the given frequency from the orbital registry.
list(none)Lists all currently orbiting satellites, showing each one’s frequency and class name.
Tab completion for descend suggests frequencies of currently active satellites.Example session:
# Hold a configured satellite chip, then:
/ntmsatellites orbit
# Satellite orbited.

/ntmsatellites list
# 42 - SatelliteScanner
# 7  - SatelliteIonCannon

/ntmsatellites descend 7
# Satellite descended.
descend permanently deletes the satellite from the world. The item is not returned to the player’s inventory. This action cannot be undone without re-launching the satellite.

​
Player Tools

Applies item-specific customisation options to the item currently held by the player. The exact arguments accepted depend on the item being held; each item that supports customisation implements the ICustomizable interface and defines its own customize(player, stack, args) handler.Permission level: 0 — available to all players, no operator permission required.Syntax:
/ntmcustomize [item-specific arguments...]
The command will fail with an error message if:
  • It is run from the console (players only).
  • The player is not holding any item.
  • The held item does not implement ICustomizable.
Refer to the documentation for individual customisable items to see what arguments they accept.

​
Network Debugging

Forcibly destroys all active NTM power and fluid networks tracked by UniNodespace. Every node in every active network is marked as expired and all network state (links, providers, receivers) is cleared in one sweep. Networks rebuild themselves naturally as their constituent tile entities tick.Permission level: 4 (operator, default level)Syntax:
/ntmreapnetworks
This command takes no arguments. On success it prints Nodespace cleared :). On failure it prints the exception details to chat and re-throws.When to use this command:Use /ntmreapnetworks when power or fluid networks appear to be stuck — for example, machines show as connected but no power is flowing, or fluid networks have stopped transferring after a server crash or chunk reload incident. The reap forces a clean rebuild from the current tile entity state rather than relying on potentially corrupted in-memory network topology.
All active networks are destroyed simultaneously. For a brief moment (typically one to two game ticks) all NTM machines will report no power input while their networks reform. This is harmless but may cause a brief processing stall on large bases.
Reads the raw Anvil chunk NBT data for a specified chunk coordinate and prints all tile entity entries it finds, including their positions relative to the chunk. Entries whose stored coordinates fall outside the valid chunk-local range (0–15 on X and Z, 0–255 on Y) are highlighted in red, indicating corrupted position data.Permission level: 4 (operator, default level)Syntax:
/ntmloadchunk <x> <z>
<x> and <z> are block coordinates, not chunk coordinates. The command converts them to chunk coordinates internally (x >> 4, z >> 4).Output format:
  • Green entries: tile entity ID and chunk-local coordinates — within valid range.
  • Red entries: tile entity ID and chunk-local coordinates — position is out of range (corrupted).
If the target chunk is already loaded in memory, the command reports Chunk currently loaded and exits without reading from disk.
This is a diagnostic/read-only tool. The command does not modify world data. Even though it identifies corrupted tile entity entries, it does not automatically remove them.
Inspects and controls NTM’s packet threading system, which offloads outgoing packet dispatch to a background thread pool to reduce main-thread stall time on busy servers.Permission level: 4 (operator, default level)Syntax:
/ntmpackets [info | resetState | toggleThreadingStatus | forceLock | forceUnlock]
SubcommandDescription
infoPrints a full diagnostic report: threading status, thread pool size (total / core / idle / maximum), per-thread names and states, total packet count, queue backlog size, percentage remaining, and time spent waiting on threads last tick.
resetStateClears the packet threading error flag (hasTriggered) and resets the clear counter. Use this after resolving a threading error to allow the system to resume normal operation.
toggleThreadingStatusFlips enablePacketThreading on or off and reinitialises the thread pool immediately. Useful for isolating whether a crash or lag issue is related to packet threading.
forceLockAcquires the packet thread lock on the calling thread. This will freeze the server main thread. Only use this under explicit direction for advanced debugging.
forceUnlockReleases a previously force-acquired lock.
Running /ntmpackets with no arguments prints the usage string.
forceLock intentionally freezes the main thread and is logged at the ERROR level. Never use this on a live production server. It exists solely for diagnosing deadlock scenarios in a controlled environment.
Example diagnostic output (/ntmpackets info):
NTM Packet Debugger v1.2
Packet Threading Active
Thread Pool Info
# Threads (total): 1
# Threads (core): 1
# Threads (idle): 1
# Threads (maximum): 1
Packet Info:
Amount total: 48291
Amount remaining: 0
% Remaining to process: 0.00%
Time spent waiting on thread(s) last tick: 0.0012ms

​
Client-Side Crash Diagnostics

SuicideThreadDump is a client-side only command registered via ClientCommandHandler. It dumps the full JVM thread state to the log file and, optionally, forces a JVM exit immediately afterwards. It is intended as a last-resort tool for diagnosing deadlocks — situations where the game has frozen and normal crash reporting cannot run.Permission level: Available to any in-game player (client-side). Not available from the server console.Syntax:
/dumpthreadsandcrashgame dump
/dumpthreadsandcrashgame crash
SubcommandDescription
dumpWrites a full thread dump (all threads, with stack traces, locked monitors, and lock owners) to the log at FATAL level. The game continues running.
crashPerforms the same thread dump as dump, then calls FMLCommonHandler.exitJava(0, true) to terminate the JVM immediately.
Per-thread output includes:
  • Thread name and PID
  • Suspended / blocked status (with block time and count)
  • Native execution flag
  • Thread state (RUNNABLE, BLOCKED, WAITING, etc.)
  • All held monitor locks and the stack frame where each was acquired
  • Full stack trace
The crash subcommand terminates the JVM without saving the world. Any unsaved progress will be lost. Only use it when the game is already frozen and unresponsive — the dump is the primary output you are after.
Typical use case: If NTM’s packet threading or another system appears to be deadlocked (server frozen, no crash report generated), run /dumpthreadsandcrashgame dump to capture thread states, then inspect the FATAL entries in the latest log file to identify which threads are holding locks and which are waiting on them. Share the log output when reporting deadlock bugs.

Build docs developers (and LLMs) love

Get started for freeTalk to us