Custom Machines Guide

This is a short guide showing how custom machines can be configured using the config files provided by the custom machine system.

Prerequisites

In order to make a custom machine, one needs the following things:

• Knowledge of the JSON format
• A text editor

JSON is a strict format that adheres to certain rules as to how it is formatted. Failure to comply to the standard will result in an unreadable JSON file that cannot be parsed by the system.

The machines

Located in the hbmConfig folder is a file named hbmCustomMachines.json. This file contains the definitions of the machines themselves, like multiblock composition, base speed, slot count, etc.

The following fields can be used to define a new custom machine:

• recipeKey (mandatory): This value defines what recipe set this machine can use, how recipe sets are defined will be explained later. Multiple machines can use the same recipe sets (like different tiers of the same machine), so this doesn't have to be unique
• unlocalizedName (mandatory): This is the internal name that the machine uses to identify itself. This name isn't visible anywhere, but it is used to store the machine type when saving the game. It is vital that this value is unique.
• localizedName (mandatory): This is the name of the machine as shown in the inventory and on the controller block. It is not required to be unique, but still recommended as to make sure it's obvious what machine it is.
• fluidInCount (mandatory): This is the amount of input fluid slots that the machine has. If the machine can't handle fluid inputs, set this to 0. The maximum is 3 fluid slots.
• fluidInCap (mandatory): The amount of fluid in millibuckets that the input slots have. This value is mandatory, but unused if there are no input fluid slots.
• itemInCount (mandatory): The amount of input item slots that the machine has. If the machine has no item inputs, set this to 0. The maximum is 6 slots. Each created item input slot will also automatically generate a template slot for filtering items.
• fluidOutCount (mandatory): The amount of fluid outputs, 0-3.
• fluidOutCap (mandatory): The size of the output fluid slots in millibuckets.
• itemOutCount (mandatory): The amount of output item slots, 0-6.
• generatorMode (mandatory): Enabling generator mode will change several behaviors:
  • The machine will create energy based on the consumption values instead of using it up
  • Instead of accepting energy, it will give energy off
  • All inputs are consumed at the start of the process instead of the end, preventing infinite energy be made by simply canceling the process
• recipeSpeedMult (mandatory): A multiplier for the duration of recipes.
• recipeConsumptionMult (mandatory): A multiplier for the energy consumption of recipes.
• maxPower (mandatory): The amount of energy this machine can buffer. Has to be at least as little as the consumption of the most expensive recipe, the recommended value is 100x more than this to provide enough power for 5 seconds.
• recipeShape (optional): The crafting recipe shape for this machine controller. The machine controller contain special NBT that distinguishes the type, so it is not possible to add recipes using other hbmRecipe configs. The shape represents the crafting grid and has to always form a proper rectangle, for example two lines with three characters each or three lines with one character each would be valid, while more than three lines or lines with different character counts are not. An empty slot can be represented by any character so long as it is not assigned an item in the following definition. If this value is omitted, no recipe will be generated.
• recipeParts (optional): An array of single characters followed by stack (item or dict) definitions. This assigns the previous recipeShape the different items used in the recipe. Any character that is not assigned an item here will result in the recipe having an empty slot there. If this value is omitted, no recipe will be generated.
• components (mandatory): This is the definition of what blocks need to be where in the multiblock. The component list has an array for each entry with different values. One such array is composed of the following values:
  • block: The internal name for the block at that position. Any of NTM's blocks require the hbm: prefix. Vanilla blocks can have the minecraft: prefix, or the prefix can be omitted.
  • x: The x-coordinate of this block. Position is relative to rotation, so "x" doesn't actually refer to the in-world x-coordinate, instead it's the "sideways" direction. Positive values make the block move to the left compared to the controller, negative values to the right. 0 is the center.
  • y: The y-coordinate is straight forward, it's just the height offset compared to the controller. Positive values make the block go up, negatives make it go down.
  • z: The z-coordinate, refers to "back and forth". Larger numbers make the block move back, further away from the controller. It is not recommended to have the z-coordinate be a negative value, as this would most likely lead to the controller either being further inside the machine or outright obstructed by a block.
    • Consequenly, coordinates should never be 0/0/0 as this is always the position of the controller
  • metas: This is an array of accepted metadata values for this block. For most blocks, this can be a single number being "0", as most blocks do not use metadata. NTM's custom machine blocks do however use metadata for the tiers, so this array allows multiple tiers to be valid for this machine. Another thing it can do is allow all subtypes of a block where the exact type doesn't matter, like wooden planks or wool.

The recipes

In the hbmRecipes folder, there's the config named _hbmCustomMachines.json. This file contains the processing recipes for all custom machines. Before the recipes file can be read, the leading underscore has to be removed from the name, the file will reset to default otherwise.

Unlike with the machine config, the recipe config's fields are all mandatory. If a recipe doesn't have, for example, fluid inputs, the field has to be an empty array. Also make sure that there's no trailing commas (,) after the final entry of an array, since the GSON json parser will interpret that as an additional null value which will break recipes.

The following fields are required for recipes:

• recipeKey: This is the name for the recipe set, as defined by the custom machines. Each set requires a unique name.
• recipes: This array contains all recipes for the set. All subsequent fields are part of the recipes array.
• inputFluids: Each fluid the recipe requires in standard format (i.e. an array with the fluid's registry named followed by the amount). Does not support pressure requirements.
• inputItems: Each item the recipe requires in standard input format (arrays with leading discriminators, item for plain stacks and dict for ore dictionary stacks). Supports stacks with more than one item.
• outputFluids: Each fluid this recipe produces in standard format.
• outputItems: Each item the recipe produces using an extended format. The extended output format follows the rules of the standard format (arrays with registry name, stacksize (optional) and metadata (optional)) with a trailing decimal dumber representing output chance. 1.0 means 100% output chance, 0.5 means 50%, etc.
• duration: The amount of ticks this recipe takes to complete. Values of 0 or below will most likely crash the game. This value is multiplied with the machine's speed multiplier to calculate the final production speed.
• consumptionPerTick: The amount of HE required to process this recipe. This value is multiplied with the machine's power consumption multiplier to calculate the final power consumption. Determines the power generation rate for machines set to generator mode.