Custom Machines

Custom machines are multiblock structures developed by the player, that can process recipes also customized by the player.

These multiblocks are composed of a core Controller and blocks of the user's choice. The controller can have a customized crafting, and it serves as a way to access the machine's GUI by right-clicking. They can handle recipes that use up to 3 fluid and 6 item slots, and has the same amount of slots for output respectively. The order of the recipes is important to determine the output (shaped recipes). For this reason, they also contain a template section to ensure the correct input order of the items. Originally, they could accept power, fluids and items only, but the ability to use heat and neutron flux was added in release 1.0.27 X4879, along with the option to generate pollution with them. (1)

How do they work?

These machines are constructed with outsider files that utilize the JSON format, so it is imperative that the user has some knowledge of how it works. JSON files are dynamically written, meaning that numbered values, such as quantities or metadata, can also be strings containing numbers, and the system will parse them normally. For more information about its inner workings, click here.

It is recommended to use a customized JSON file editor, to ensure an easy and straightforward editing experience. This is not necessary though, as the files can be modified with a regular text editor. Just make sure that the format is strictly followed at all times; otherwise the game will not parse the recipes or configuration, resulting on non-working machines or even a crash.

Finally, note that the item or block internal unlocalized names are employed by the configuration files below. This means these machines can use, produce, or be composed of another mod's items and blocks. If you wish to make the machine refer to a Grass block, minecraft:grass must be typed instead of Grass or whatever else. To see these localized names and their metadata, simply pressing F3+H would work, or installing other mods that have this functionality such as COFH Core and Minetweaker, then run their commands to complete this task, like /cofh hand and /mt hand respectively.

Creating your own machines

To shape the machines as you wish, you need to edit the 2 files. They have an homonymous name (_hbmCustomMachines.json), so it is recommended that you change their name and store them on another folder.

All the values these files contain should not be deleted unless specified otherwise. After modifying them, be sure to remove the underscore of the file's name for the changes to apply.

Configuration file

Located in the hbmConfig folder. It's in charge of sorting everything related to the specific, particular aspects of each machine (Which blocks should be used to build the machine, how many output slots for items or fluids there should be, how much energy the machine should hold, etc).

Do not try to delete these values unless it's specified the safety of doing so, as this might cause crashes and unwanted behaviors.

localizedName: In-game name of the machine.

unlocalizedName: Internal name of the machine. Since the game utilizes this value to define itself, it should be an unique string that doesn't contain spaces.

localization: Translation for the machine's name. It contains two values: One for the language file that the translation belongs to (located in the ??? folder) , and the second is the machine's localized name translated to the selected language.

itemInCount: Amount of item input slots. Ranges from 0 (no items needed) and 6.

itemOutCount: Amount of item output slots. Can be either 0 (no item output), or all the way up to 6.

fluidInCount: Amount of fluid input slots. Valid numbers are those between 0 (no fluids needed) and 3.

fluidInCap: Fluid capacity of the input fluid slots, in mb. Should be greater than 0 if there's at least 1 fluid slot; otherwise this value is ignored.

fluidOutCount: Amount of fluid output slots. Ranges from 0 to 3, being 0 no fluid output.

fluidOutCap: Fluid capacity of the output slots. Make sure this value is greater than 0 if there's fluid outputs; otherwise the game will crash.

maxPower: Amount of energy the machine can hold. This value should always be greater than the consumption of the most expensive recipe. The recommended amount is said value multiplied by 20, as the machine would be capable of sustaining production for 10 seconds.

maxPollutionCap: Maximum amount of pollution the machine can produce. Can be deleted if so desired, for the machine not to produce any pollution (be sure to delete the SOOT values on the recipes file too, to not cause a crash).

As specified on the first section of this guide, custom machines can share the same recipes or set of recipes, and so this means they can work with different tiers of the same machine. To make this happen, this configuration file also features three modifiers:

recipeKey: This value defines the recipe, or set of recipes, that the machine can use. Can be shared among machines.

recipeSpeedMult: Multiplies the base duration of a recipe. 1.0 is the base value, decreasing it will speed up the processing time of a recipe and viceversa.

recipeConsumptionMult: This will modify the energy consumption of a recipe. 1.0 is the base value, increasing it will make the consumption greater and viceversa.

They also feature 3 different modes, with 2 of them having the ability to be turned on and of with a boolean value (false or true):

Energy mode, which uses power to execute the recipes. If no other modes are selected, this mode will be defaulted.

fluxMode: This makes the recipes need neutron flux, transferrable with a Research Reactor.

generatorMode: Turns the whole machine into a power generator. Some behaviors of the machine change too, like the machine giving out power instead of accepting it; energy being created instead of consumed per recipe; and fluid/item inputs being consumed at the start of the process instead of at the end, to prevent exploits.

The Configuration file also manages everything in relation to multiblock composition, which means the type and position of the blocks that should be part of the structure. The values shown below are responsible for that:

recipeParts: This array contains the items required to craft the machine's controller. First, a value containing a letter will represent the following one, which specifies the items required, whether if they are plain or dict (Ore Dictionary) stacks.

recipeShape: An array containing 3 values, each with 3 letters, that represent a crafting grid. The letters will represent the items specified in the recipeParts array, and if a letter has no item attached to it, it will show as nothing on the grid.
- This is the only way to craft a machine controller, as using recipes from different machines, such as the Assembly Machine, will not work. The shape of the recipe must be of rectangular form, otherwise it will not get read by the system. Both this field and recipeParts are entirely optional, so they could be left as-is.

components: Represents where blocks need to be in a certain position that is relative to the machine's controller. This is essentially a list of arrays, and each of these arrays consist of 5 elements:
- block: The unlocalized name for the block at a determined position. Only vanilla's prefix minecraft: can be omitted, the NTM prefix hbm: or other mod's prefixes need to be addressed.
- x: The X coordinate relative to the front face of the controller, identifiable by its unique side texture. Since the controller has the 0x, 0y, 0z coordinates, 1 or any positive value means left-side of the controller; negative values means right side.
- y: The Y coordinate means the height, as it is in-game. Positive values mean that the block is above the controller; negative values mean they're under it.
- z: The Z coordinate, or the "back and forth" axis. Negative numbers make the block go behind the controller, positive numbers make them move to the front.
  - Be noted that blocks with a z value of 1 means that they are right in front of the controller, so this could cause problems to access it.
- metas: A number that represent the metadata of the block specified, can be many for a single block. Metadata refers to the specific type of a family of blocks, like colored wools, wood planks, glasses and custom machine blocks, so this allows for easier tiering of the structure. A metadata of 0 means that there's no metadata to match the block, and it's the default value.
  - Metadata values also represent specific rotations on many blocks with a number, such as pillars, woods, and for some reason leaves.

Recipes file

Located inside the hbmRecipes folder, this file manages the general traits that can be shared among multiple machines, such as the recipes.

The formatting for this file is a bit special, as there shouldn't be a final comma , at the last entry of an array; otherwise the system reads there is an extra null value which will break recipes.

recipeKey: The following recipe, or group of recipes, are identified by the custom machines via this string. This name must be different than other recipe keys.

There's a big array called recipes, that will manage variables both mandatory (Cannot be deleted, if the user doesn't want to use them, their arrays must be empty, never erased), and optional (Can be deleted entirely from the file). The mandatory values are the following:

inputItems: This identifies which items should be consumed per recipe operation. Each array contained here represents an item, and their formatting follows this template: First, the stack discriminator (item for regular stacks, or dict for Ore Dictionary stacks). Then comes the unlocalized names for either item or dict stacks. After that, there's two values that can be omitted as they're entirely optional; being the third one a number representing the stacksize (amount of items required) and the fourth one the metadata.

outputItems: Precises which items should be obtained after a recipe is complete. Follows a similar format as the inputItems object, except it doesn't support Ore Dictionary entries. Because of this, the first value is the unlocalized name, followed by the optional values of stacksize and metadata. It contains an extra value after the ones mentioned, which is the output chance: 1.0 being the item is obtained 100% of the times after a recipe is completed, 0.7 being 70% of the times, and etcetera.

inputFluids: Specifies which and how much fluid should be consumed every recipe operation. Each array represents a singular fluid, and has 2 values: First is the fluid's registry name, all in uppercase; second represents the quantity of said fluid. To see the registry names for the fluids, you can check the hbmFluids and hbmFluidTraits files. Other mod's fluids and fluid metadata are not supported, so this means these machines cannot use pressurized fluids...for now.

outputFluids: States the fluids produced each operation, follows the same format above precised.

duration: Indicates the amount of ticks the machine will take to complete a recipe. A tick is 1/20th of a second, so a duration of 100 means 5 seconds. This value is multiplied by the recipeSpeedMult value to calculate the final amount of time needed per operation. Do not set this value to 0 or below; it will crash the game.

consumptionPerTick: A self-explanatory value: Specifies the amount of energy (in HE) required per tick. In generator mode, determines how much HE per tick a recipe should produce. Like duration, this is multiplied by the recipeConsumptionMult modifier to account for the final energy consumption or production of the recipe.

The optional, erasable values are these:

pollutionType: Sets the type of pollution the machine should engender. There's only 3 contamination categories as of now: SOOT, POISON, and HEAVYMETAL. These strings should be written all in uppercase.

pollutionAmount: Determines how much pollution should be generated each second (not ticks) when the recipe is running.

radiationAmount: Sets the amount of chunk radiation the machine can produce in total. A value of 20 means that the chunk should have 20 rad/s as long as the operation is still going.

flux: The required amount of [neutron flux to initiate an operation. Flux can be transferred to the machine from a Research Reactor with the Neutron Flux Receiver, which is a block made specifically for custom machines.

heat: Similar as flux, it determines how much Thermal Units (TU) are needed per operation. To transfer them from TU generating devices such as Fluid Burner, the Heat Receiver block is required.

These are the core files that the system will use to generate your very own machines. As mentioned before, there's tools and blocks that will help fulfill this task more easily, which are going to be covered later.

Installing the machines

To install the machines, both files should be on their respective folders (Recipes file on the hbmRecipes folder, and Configuration file on the hbmConfig folder). If the files were renamed, be sure to change their name back to their original one without an underscore (hbmCustomMachines.json).

If the user wants to make multiple machines, simply stack each other up by copying the objects that represent each machine and pasting them just below each other on the recipes array for the recipes file, or the machines array for the configuration file.

Editing recipes without needing to reload the game can also be done. Simply open the Recipes file, modify the contents and save the file. After that, run the /ntmreload command in your game for the recipes to be updated. This doesn't apply for the configuration file, as it holds key aspects of each machine, so if the user wishes to change anything on them, a complete re-launch should be performed.

Custom machine specific blocks

These are a bunch of blocks that were added along with the Custom Machines, and they're made specifically for them to be constructed. They don't have any other functionality to offer to the mod and are entirely optional, as custom machines can be made with any block from any mod, assuming it isn't a tile entity. However, they provide a better way to implement tiering and upgradability on them, as they have multiple variants for each block.

A Steel Machine Cashing. Can also come in Desh, Advanced Alloy, and Technetium Steel variants

Machine Casing

Structural blocks made of 4 ingots and 1 cast plate of either Steel, Advanced Alloy, Desh or Technetium Steel (Cadmium not supported). Take into consideration that the average cost of one machine casing block is around 2 ingots of material.

Machine Sheet

Pseudo-seamless blocks made of 4 machine casings in a square grid. These sheets are considerably less expensive than the casings, as the yield is 4 times bigger.

A Steel Tank. Doesn't hold any fluids, though.

Tanks

Yet another purely decorative block made with four ingots of the available materials and any piece of glass.

Basic Circuit Block. Every circuit has it's block variant

Circuit Blocks

Also decorative, although slightly varied: they come in 5 tiers instead of 4, so they are a better way to ensure requirement hierarchy. These 5 tiers correspond to the type of Circuits required for the craft (along with 4 Steel ingots), which could be Basic, Enhanced, Advanced, Overclocked and High-Performance.

A Motor Block. The bismuth variant is the most expensive decorative block for these machines.

Motor Blocks

Similar to circuit blocks, Motor blocks are crafted with 4 steel ingots and any of the Motor variants: Normal, Desh and Bismuth. They're also purely decorative.

A Steel Port. Connect pipes or inserters for fluid/item handling.

Ports

These machine ports are the only way to transpose items, fluids and energy into and out of the machine. Since they don't require an inserter for items to be let in, any item duct from any foreign mod can be connected to these ports. They also come in one of the 4 valid flavors, needing a Machine Casing plus 2 Iron Plates.

Heat Receiver

These ports made of Copper Ingots and Insulators are needed to transmit TU from a heat source to the machine. Like any other machine that needs TU, both the coil-like block from the selected source and this heat receiver must be aligned to ensure a correct TU conduction.

Neutron Flux Receiver

A special port required to convey neutron flux from it's only source, a Research Reactor. Both the lower port of it and this block should be connected for flux transfer to work. Advised it is that it's crafting recipe is very expensive, costing almost the same materials as a the Research Reactor itself.

Custom machine specific items and tools

Building these machines only using the configuration file and a text editor might be a hassle for beginners, especially if the structure composition is very complex or big. If it's true, not even experts could complete the titanical task of coding them properly. Thankfully, there's tools available for the player to make this task less of an annoyance. (Only available in creative mode for obvious reasons):

The Custom Machine Structure Output Wand. Call it your best friend from now on

Custom Machine Output Wand

This object can register all the blocks present in a pre-set area and paste the results into a .txt file allowing the user to design their structures in-game and simply copy the results into the components list on the configuration file. The .txt file is called CMOutput.txt, and it's located inside the hbmConfig folder. To do this, the user must right click a Custom Machine Structure Positioning Anchor with the wand. Then, clicking a block will make the wand set the first position, and clicking again sets the second one. Thuis draws an imaginary cube between these 2 positions, and everything this cube contains will be registered as part of the structure. Both position's coordinates are shown with an in-game GUI. To export the file, the user must click again anywhere, and the operation will be completed.

Custom Machine Structure Positioning Anchor

This block with a fancy name sets the position of the controller on the machine. It is recommended that the controller's position is visible and easily accessible for the players.

A Structure Wand. Assembles machines in less than a second

Structure Wand

Your best friend when it's time for testing the machines. Place down a custom machine controller, right click it with this wand, and the machine will be instantly assembled. Works with every multiblock that has only one building template, such as the Fusion Reactor or the Soyuz Launchpad. It is advised that the user builds their custom machines from scratch at least once, to ensure a correct multiblock assembly.

Other tools that might help with machine building are these:

Structure

Existing custom machines

Outside of theory and designs, a player can actually see what a custom machine looks and works in a regular game:

Paper Press

A cheap 3x3 multiblock made of 16 Steel Casing, 7 Steel Sheet and 2 Steel ports that is capable of processing paper from sawdust and water. HE consumption is dirt cheap too, at only 600 per operation. 16, 17*

There's 3 more machines that were made by the NTM developer (HBM) that aren't in the game, but rather on his Github page:

Electric Blast Furnace

A really expensive furnace resembling the Gregtech EBF, being a 3x4 multiblock made of 16 Dense Superconducting Coils and 17 Technetium Machine Casings. It can only yield 2 materials, Steel and Minecraft Grade Copper. The energy consumption and recipe duration are also pretty high: 1.2 million HE every ingot produced, spread across an entire minute.

Surprisingly, the github version doesn't have any ports attached to it, so it cannot be automated. 18, 19*, 20*

Bakelizer

The complete antithesis of the EBF. This extremely cheap machine is composed of 23 Steel Casings, 2 Steel Ports and a Steel Tank in the middle, and it has a singular, amazing recipe: Making Bakelite with half the original price, which was 500mb each of Petroleum Gas and Aromatic Hydrocarbons, and only 10000 HE per operation. As a "downside", it produces 100mb of water each ingot. 21, 22*

Generator

Another 3x3 hollow multiblock composed of 2 Steel Ports and 23 Lead blocks. Relatively expensive even for the mid-game, this structure has one and only recipe: Turning Uranium ingots into Lead, and giving 100000 HE per recipe. 23, 24*

You might find them here, linked on the github release that added the custom machines. Alternatively, you can download them directly here, with fixed automation for the EBF and added a missing crafting recipe for the Generator's controller block. As always, remember: The configuration file goes inside the hbmConfig folder, and the recipes file into the hbmRecipes folder, both files without an underscore.

Interactive Tutorial

Feel these machines are unbalanced, janky or ugly? What are you waiting to make your own, with the help of the Interactive Tutorial!