1.19.x ResourcePacks

Resource Packs

IC2Classic uses custom JsonModels that load via code, meaning model overriding is not supported.
But since we don't use models we load textures differently too.
In Each Texture folder is a "texture_package.json".
These files ic2c scans for automatically and loads/stores them for ic2cs internal system to use.

Here is a example file:

Macerator

{
	"active_down": "ic2:block/electric/battery_station/mv/down",
	"active_east": "ic2:block/electric/energy_storage/mfe/east",
	"active_north": "ic2:block/electric/energy_storage/mfe/east",
	"active_south": "ic2:block/machine/hv/colossal_macerator/active_south",
	"active_up": "ic2:block/machine/lv/macerator/active_up",
	"active_west": "ic2:block/electric/energy_storage/mfe/east",
	"inactive_down": "ic2:block/electric/battery_station/mv/down",
	"inactive_east": "ic2:block/electric/energy_storage/mfe/east",
	"inactive_north": "ic2:block/electric/energy_storage/mfe/east",
	"inactive_south": "ic2:block/machine/hv/colossal_macerator/active_south",
	"inactive_up": "ic2:block/machine/hv/colossal_macerator/inactive_up",
	"inactive_west": "ic2:block/electric/energy_storage/mfe/east"
}

The left names are the identifiers.
DO NOT CHANGE THEM.
The right side is the path on where the texture for that identifier can be found.

Why is it done this way?
It allows to run a tool that scans for duplicates and reduce the total amount of duplicated textures.
With Duplicates ic2c has roughly 3k textures. Without roughly 1.5k.
And that makes a difference by a LOT.

These paths are just any resource location and you can technically even apply any other mods texture if you want to.
You get full control.
Even custom domains are supported.

Everything else is vanilla like regarding textures. This is just the method we find them.

Since all Textures by default are compressed and decompressing it is a lot of work. Here you can download all ic2c textures uncompressed and easily replaceable.
it is highly suggested that you compress them once you are done.
IC2U ResourcePack.zip

DataPack (outdated)

For recent versions of 1.19 look here

IC2Classic has datapack support.
Yes, really.
While IC2Classic doesn't use datapacks by default, because its just easier for the development team, it doesn't mean it isn't supported. All Recipes in IC2Classic can actually be exported. That includes datapack recipes too.
Simple go into a Singleplayer world and run /ic2c_export command and it will create a zip file that contains all recipes in the datapack format.
The resulted zip file can be found in the ic2c config folder.

That is almost a valid datapack only the "pack.mcmeta" file is missing.

IMPORTANT NOTE: Datapacks are significantly slower then ic2cs internal recipe loading system.
So it is suggested you only leave changes in the datapack to ensure the best performance is provided.

Anyways underneath this section you find the documentation on how everything works!

Recipes

Crafting

IC2Classic adds their own Recipe Types to the game.
Mainly for the reason that certain features aren't supported by Vanilla Minecraft, and that while datapacks are great if you have over 500 recipes to write even with the helper tools is way to much grind, so we had our own system that is just datapack compatible.

These features are the following:

• EU Being transfered from input to output.
• Recipes being hidden, (can be disabled in the config)
• Container items being consumed without giving items back
• Stacksize requirement being dynamically. So a recipe can say they need 16 cobblestone in one slot but only 1 in another slot.

To use the any of the ic2classic recipe types, simply use the following type.

Crafting

{
	"type": "ic2:crafting_ic2_automated"
}

Cooking

{
	"type": "ic2:cooking_ic2_serializer"
}

Note this uses just internal recipes so only "enabled": false works here. Since minecraft already has a Furnace recipe parser

Smithing

{
	"type": "ic2:smithing_ic2_serializer"
}

Note this uses just internal recipes so only "enabled": false works here. Since minecraft already has a Smitthing recipe parser

Stonecutting

{
	"type": "ic2:single_item_ic2_serializer"
}

Note this uses just internal recipes so only "enabled": false works here. Since minecraft already has a Stone cutting recipe parser

If you want to disable any recipe within ic2classic simply add this to the recipe file:

{
	"type": "ic2:crafting_ic2_automated",
	"enabled": false
}

Simply setting enabled to false will disable the loading of said recipe.
If you grabbed a recipe from the autogenerated pack, the rest of the file can be discarded since it will be never checked.

If you want to change a existing recipe. Simply name the file exactly how the recipe is named and select the ic2 type and then define your changed recipe as you would normally do.
The Internal Datapack loader sees the replacement and instead load it instead of the internal one.

Adding Recipes works the exact same just that the filename is no longer required to be the same as a existing recipe id.

Now to the specific recipe types that exists.

Shaped

This example recipe shows you exactly all features of the recipe type

• "sub_type": defines which recipe type of the ic2c loader you want. For shaped recipes its called: "ic2:shaped".
• "hidden": defines if a recipe is visible to the player or if they have to enable hidden recipes to be visible. UU-Matter recipes use these for example.
• "consume": if container items should be consumed. Including their container.
• "width": How wide the recipe is. This has to be accurate.
• "height": How tall the recipe is. This has to be accurate.
• "pattern": defines the pattern how the items have to be placed in.
• "inputs": defines the inputs for the recipe and can make use of any of the Inputs.
• "letter": In every input a letter has to be defined which corresponds to the letters in the "pattern".
• "output": The output of the recipe. This can also include NBT, it is using the same way NBTStacks uses it.

{
	"type": "ic2:crafting_ic2_automated",
	"sub_type": "ic2:shaped",
	"output": {
		"item": "ic2:iron_furnace",
		"count": 1
	},
	"hidden": false,
	"consume": false,
	"width": 3,
	"height": 3,
	"inputs": [
		{
			"tag": "forge:ingots/iron",
			"size": 1,
			"type": "ic2:tag",
			"letter": "X"
		}
	],
	"pattern": [
		"XXX",
		"X X",
		"XXX"
	]
}

Shapeless

This example recipe shows you exactly all features of the recipe type.

• "sub_type": defines which recipe type of the ic2c loader you want. For shaped recipes its called: "ic2:shaped".
• "hidden": defines if a recipe is visible to the player or if they have to enable hidden recipes to be visible. UU-Matter recipes use these for example.
• "consume": if container items should be consumed. Including their container.
• "inputs": defines the inputs for the recipe and can make use of any of the Inputs.
• "output": The output of the recipe. This can also include NBT, it is using the same way NBTStacks uses it.

{
	"type": "ic2:crafting_ic2_automated",
	"sub_type": "ic2:shapeless",
	"output": {
		"item": "ic2:bronze_double_insulated_cable_item",
		"count": 1
	},
	"hidden": false,
	"consume": false,
	"inputs": [
		{
			"item": "ic2:bronze_cable_item",
			"size": 1,
			"type": "ic2:item"
		},
		{
			"tag": "ic2:rubber",
			"size": 1,
			"type": "ic2:tag"
		},
		{
			"tag": "ic2:rubber",
			"size": 1,
			"type": "ic2:tag"
		}
	]
}

Repair

The Repair Recipe type is really special. It requires the item that is used to be repaired to implement the [IRepairable](https://github.com/TinyModularThings/IC2Classic/blob/1.19.x/src/main/java/ic2/api/items/IRepairable.java) Interface. If that is not done the game will simply not load the recipe. Also it is a shapeless kind of recipe where it will multiply the "material slots" being found by the repair amount. So keep that in mind.

• "repair": is the item that is being repaired.
• "material": is the input that is required to repair said item. Which uses the Inputs system.
• "size": defines how many durability points are being restored. This can be positive or negative.
• "hidden": defines if a recipe is visible to the player or if they have to enable hidden recipes to be visible. UU-Matter recipes use these for example.
• "consume": if container items should be consumed. Including their container.

{
	"type": "ic2:crafting_ic2_automated",
	"sub_type": "ic2:repair",
	"repair": "ic2:reflector_iridium",
	"material": {
		"tag": "forge:dust/coal",
		"size": 4,
		"type": "ic2:tag"
	},
	"size": 10000,
	"hidden": false,
	"consume": false
}

Machines

IC2 Classic also adds Custom Machines, which also want datapack support.
These recipes are under the "ic2_recipes" folder which is next to the "recipes" folder.
In there are folders for every single machine.
And depending in which of the machines folders you put in your recipe json file it will load into this specific machine.

Removing recipes

If you want to remove machine recipes. It is quite simpler then compared to Vanilla. Since machine recipes are allowed to be removed in the first place. Unlike Vanilla.
But sadly there is a few different removal formats out there due to how machines are designed.
This is the most common format to delete recipes.
If this format isn't used the machines recipe format will state that its different and will explain how it works.

This format goes as follows:
Simply throw a json file into the machines folder wtih the following content.

• "remove": a json array/primitive of resourcelocations for their recipes. The folders do not have to be included, so just modid and filename.

{
	"remove": ["ic2:cfoam_pellets", "ic2:compress_mv_solar_panel"]
}

Also the rest of the file is ignored when "remove" is present.

Basic Machines

Basic Machines are in this case the "macerator", "extractor", "compressor", "recycler", "mixing_furnace" (alloy smelter) and the "sawmill".
While they are very basic machines they are highly dynamic.

• "input": defines the input for the recipe. And uses the Inputs system.
• "output": defines the output for the recipe. And uses the Outputs system.

{
	"input": {
		"item": "ic2:wet_cfoam",
		"size": 1,
		"type": "ic2:item"
	},
	"output": {
		"xp": 0.0,
		"outputs": [
			{
				"item": "ic2:cf_pellet",
				"count": 1
			}
		],
		"type": "ic2:simple"
	}
}

Recycler

The Recycler has a "Blacklist" that can be loaded optionally.

• "filter": if this is set to true the "filter" parser is applied.
• "remove": if this entry is present and set to true will remove every entry from the blacklist that is defined.
• "simple": is a array of itemids, resourcelocations, that should be blacklisted.
• "special": is a array of Inputs that can have a broader selection of items. NOTE: Due to a bug this sadly doesn't work in version 2.0.3 or older. Will be addressed in the next patch.

{
	"filter": true,
	"remove": false,
	"simple": ["minecraft:apple"],
	"special": []
}

Alloy Smelther

The Alloy smelter uses a Slightly different format where input is a "array" instead of a "object".
This is due to having 2 inputs.
And you are required to have 2 inputs with the Alloy Smelter, otherwise the recipe isn't accepted.
Everything else from the "Basic Machines" documentation is still valid, just 2 inputs instead of 1.

{
	"input": [
		{
			"tag": "forge:dust/copper",
			"size": 3,
			"type": "ic2:tag"
		},
		{
			"tag": "forge:dust/tin",
			"size": 1,
			"type": "ic2:tag"
		}
	]
}

Rare Earth Extractor

The rare earth Extractor is a really special Machine, since it doesn't have 1 input and then 1 output.
Instead it has multiple inputs for 1 thing and you accumulate charge for that thing until you reach 1000 points.
The 1000 points is hardcoded. But your input uses floats so you can make it as small as you want.
Though to not break JEI compat anything below 0.01 is not advised. Since it calculates how many items it requires to obtain said item in the description.

So the format goes as follows:

• "output": defines the output and how much it makes. NBT is supported, and is done like NBTStacks does it. If the output is already present it will be just overriden. (If it is the exact same nothing will change)
• "inputs": defines the items and how much they are worth for the given output.
  • "item": is the registry name of the item that is valid.
  • "value": is how much each item is worth.

{
	"output": {
		"item": "ic2:dust_rare_earth",
		"count": 1
	},
	"inputs": [
		{
			"item": "minecraft:stone",
			"value": 3.125
		},
		{
			"item": "minecraft:deepslate",
			"value": 3.125
		},
		{
			"item": "minecraft:granite",
			"value": 62.5
		}
	]
}

Electrolyzer

The electrolyzer is a Machine that charges/discharges items into a different form.
Yes its technically no longer electrolyzation. WHO CARES! (GT Community please leave me alone xD)

Format is actually quite simple:

• "input": is a ItemStack of the item that should be charged. This supports NBT like NBTStacks though this can or can not work.
• "output": is a ItemStack of the item that should be the output. This supports NBT like NBTStacks though this can or can not work.
• "energy": How much EU it should cost to charge the item. Since EU is linked to the progress bar this is also effectively a speed controller too.
• "charging": if the recipe drains EU to get the output item from the input item.
• "discharging": if the recipe supplies EU to get the input item from the output item. (Note the player gets 60% + energy storage tier connected * 10% back, yes this is a lossy system intentional. Though PESU is Tier 6)

{
	"input": {
		"item": "minecraft:quartz",
		"count": 1
	},
	"output": {
		"item": "minecraft:diorite",
		"count": 1
	},
	"energy": 1000,
	"charging": false,
	"discharging": true
}

Note charging & discharging are supported at the same time.

Massfabricator

Yes the Massfabricator does have a recipe list. But to everyones sadness it just uses the "Input" part of it to define what is valid "amplifier".
Time to got to the format:

• "input": is the filter that decides how much amplifier said Input has. It uses the Input System.
• "output": In this case simply copy the output. Its a dummy Output. All that matters is the "nbt":"{Amplifier:100000}".
  • "Amplifier": Decides how much amplifier you get per item that is being consumed.

{
	"input": {
		"item": "ic2:scrap_metal",
		"size": 1,
		"type": "ic2:item"
	},
	"output": {
		"xp": 0.0,
		"nbt": "{Amplifier:100000}",
		"outputs": [
			{
				"item": "ic2:uumatter",
				"count": 1
			}
		],
		"type": "ic2:simple"
	}
}

Liquid Fuel Generator

The Liquid Fuel Generator comes also with a recipe list.
Simply because some moddevs might not add compat to it but it allows the pack devs to reconfigure how the production values are, or add support for other mods.

The format is as follows:

• "fuels": A list of fuel entries.
  • "fluid": the registry id if the liquid that should be added/removed
  • "burntime": the burntime of the fluid in ticks for a full buckets worth of said fluid. (Will be will be adjusted based on how much of a bucket was consumed)
  • "production": the EU/t produced per tick.
  • "remove": if the recipe should be removed. (production/burntime can be left out if this is present)

{
	"fuels": [
		{
			"fluid": "ic2:woodgas",
			"burn_time": 250,
			"production": 10,
			"remove": false
		},
		{
			"fluid": "ic2:bio_fuel",
			"burn_time": 2000,
			"production": 128
		},
		{
			"fluid": "ic2:alcohol",
			"burn_time": 24000,
			"production": 50
		}
	]
}

Uranium Enricher

The Uranium Enricher is again a accumulator recipe list, where you can provide items that give a accumulative value.

Time for the format:

• "input": The requried item that should be enriched. (ItemId/ResourceLocation)
• "fuels": A List of Inputs and their values towards the output.
  • "input": The input for the specific fuel value. Uses the Input system.
  • "value": How much it adds towards the enriching fuel.
• "output": The Output item that is being created. Supports NBT. Which is done like NBTStacks.
• "color": the RGB value of the Fuel Color.
• "energy_usage": How much EU/t is required to craft the ingot. Can be multiplied by 1000 to see the total energy required.
• "points": How many points are required to get the ingot. Internal Point tank has a capacity of 1000 points. Anything higher is not supported.

{
	"input": "ic2:ingot_uranium",
	"fuels": [
		{
			"input": {
				"item": "minecraft:charcoal",
				"size": 1,
				"type": "ic2:item"
			},
			"value": 25
		},
		{
			"input": {
				"item": "ic2:charcoal_block",
				"size": 1,
				"type": "ic2:item"
			},
			"value": 200
		}
	],
	"output": {
		"item": "ic2:ingot_uranium_enriched_charcoal",
		"count": 1
	},
	"color": -13224394,
	"energy_usage": 5,
	"points": 100,
}

Refinery

The Refinery is the Magic New machine for 1.19.2 and is also one of the most complex one provided.
It can be viewed as a Mixer or Ore Washer but that isn't really accurate either.

Anyways time for the FORMAT:

• "input": The item that should be inputed. Uses the Input System.
• "first_tank": The primary fluid required.
• "secondary_tank": The Secondary fluid required. If empty it will be viewed as if the tank has to be empty. Note: Duplicated recipes that are flipped are autogenerated. So fluid order isn't important.
• "output": Defines the output, which can be a Fluid Output too. Uses the Output System.

{
	"input": {
		"tag": "forge:ores/aluminium",
		"size": 1,
		"type": "ic2:tag"
	},
	"first_tank": {
		"fluid": "minecraft:lava",
		"amount": 375
	},
	"second_tank": {
		"fluid": "minecraft:empty",
		"amount": 0
	},
	"output": {
		"output": {
			"item": "ic2:raw_aluminium",
			"count": 1
		},
		"minOut": 15,
		"maxOut": 45,
		"fluidOutput": {
			"fluid": "minecraft:empty",
			"amount": 0
		},
		"minFluid": 0,
		"maxFluid": 0,
		"nbt": "{time_mod:0.5d}",
		"type": "ic2:range"
	}
}

Fusion Reactor

Before anyone from the GT Community complains. Its a FISSION INDUCED Fusion Reactor. Yes its not 100% Realistic, WHO CARES xDDDD

The Fusion Reactor is a infinite lava generator that melts resources into lava. The Recipe list here decides what resources are melt-able. FORMAT!

• "fuels": A list of fuels.
  • "input": ItemId that defines the item thats allowed in the "fuelslot".
  • "fuelValue": How much lava it turns into.
  • "productionRate": how quickly the production of lava happens because of this fuel. 1.0 => 100% 2.5 => 250%
  • "consumed": if the provided item is consumed or if it is a infinite item that will never get consumed.
  • "remove": If this entry should be deleted from the recipe list or not. (consumed/fuelValue/productionRate will not be checked for if this is true)

{
	"fuels": [
		{
			"input": "ic2:upgrade_cobble_generator",
			"consumed": false,
			"fuelValue": 1000,
			"productionRate": 1.0,
			"remove": false
		},
		{
			"input": "minecraft:cobblestone",
			"consumed": true,
			"fuelValue": 1000,
			"productionRate": 1.0
		},
		{
			"input": "minecraft:netherrack",
			"consumed": true,
			"fuelValue": 1000,
			"productionRate": 1.5
		}
	]
}

Scrap Boxes

The Scrap Box Drop is also controllable through datapacks. It is also fairly simple to add drops to the list.
Though as of Version 2.0.3 its not possible to remove any. (Yep oversight, will be addressed in the next patch)

Format goes as followed:

• "remove": defines if the list is here to remove entries or add them. If remove is true "chance" can be ignored. //Unsuported. Will be addressed after the 2.0.3 patch.
• "drops": A list of drops that should be added/removed.
  • "drop": is a ItemStack that should be dropped. NBT is supported and done like NBTStacks does it.
  • "chance": is how likely it is to spawn. Note that chances once all drops are loaded will be normalized for JEI, so chances may vary from inputed values to actual values. It is a WeightedList.

{
	"remove": false,
	"drops": [
		{
			"drop": {
				"item": "minecraft:wooden_hoe",
				"count": 1,
				"nbt": "{Damage:0}"
			},
			"chance": 5.01
		},
		{
			"drop": {
				"item": "minecraft:dirt",
				"count": 1
			},
			"chance": 5.0
		},
		{
			"drop": {
				"item": "minecraft:grass",
				"count": 1
			},
			"chance": 3.0
		},
		{
			"drop": {
				"item": "minecraft:gravel",
				"count": 1
			},
			"chance": 3.0
		}
	]
}

Outputs

IC2Classic adds a custom Output system to the Basic Machines.
Said output system allows you to really control what type of output you are going to get.

There is 2 types of outputs.

Item Outputs

Item Outputs are giving back items. (DUH)
The Basic Machines support multiple outputs at once. As long as 1 item fits the output the recipe will be processed.
And if there is stuff left it will be put into a "to output queue", So if you want to have multiple outputs that is supported.

There is 3 types of Item Outputs:

Simple

This is your Simpel output, no logic applied at all.
Format:

• "xp": How much xp the recipe should provide.
• "nbt": for modifiers (Read Output Modifiers)
• "outputs": Which defines the output, it is using the NBTStack format in inputs.
• "type": Identifier of the Output Type

"output": {
	"xp": 0.0,
	"nbt": "{time_mod:10.0d}",
	"outputs": [
		{
			"item": "ic2:scrap_metal",
			"count": 1
		}
	],
	"type": "ic2:simple"
}

Ranged

A Recipe output that can be between a minimum and maximum number.
Format:

• "output": the output item. Again a NBTStack. Check Recipe Inputs. In this case limited to 1 item.
• "minOut": The Minimum Stacksize of the output.
• "maxOut": The Maxmium Stacksize of the output.
• "nbt": for modifiers (Read Output Modifiers)
• "type": Identifier of the Output Type

"output": {
	"output": {
		"item": "ic2:fertilizer",
		"count": 1
	},
	"nbt": "{time_mod:10.0d}",
	"minOut": 0,
	"maxOut": 1,
	"type": "ic2:range"
}

Chance

A Chance based Recipe output that may or may not come out.
Format:

• "chance": How likely it to be dropped. 1.0 => 100%, 0.0 => 0%, 0.25 => 25%
• "outputs": A list of outputs that can come out. Supports NBT, Check NBTStack in inputs.
• "xp": How much XP should be produced when this recipe was processed.
• "nbt": for modifiers (Read Output Modifiers)
• "type": Identifier of the Output Type

"output": {
	"chance": 0.25,
	"xp": 0.0,
	"nbt": "{time_mod:10.0d}",
	"outputs": [
		{
			"item": "ic2:fertilizer",
			"count": 1
		}
	],
	"type": "ic2:chance"
}

Fluid Outputs

Fluid Outputs is a mix of Fluid/Item outputs for the Refinery.
And they can not be used by any other Machine Basic either.

There is 2 types of Fluid Outputs:

Simple

The Simple fluid output is a basic processing output. It provides what you define. No logic applies.
Format:

• "xp": How much xp the recipe should provide.
• "nbt": for modifiers (Read Output Modifiers)
• "outputs": Which defines the output, it is using the NBTStack format in inputs. (Can be empty)
• "fluidOutputs": Defines which fluids should be produced. Supports any amount of fluids.
• "type": Identifier of the Output Type

"output": {
	"xp": 0.0,
	"nbt": "{time_mod:10.0d}",
	"outputs": [],
	"fluidOutputs": [
		{
			"fluid": "ic2:bio_fuel",
			"amount": 250
		}
	],
	"type": "ic2:simple"
}

Ranged

The Ranged fluid output is your Output.
Format:

• "output": the output item. Again a NBTStack. Check Recipe Inputs. In this case limited to 1 item. (Can be empty)
• "minOut": The Minimum Stacksize of the output.
• "maxOut": The Maxmium Stacksize of the output.
• "fluidOutput": the Fluid that should be outputted.
• "minFluid": The Minimum Fluid Output of the recipe.
• "maxFluid": The Maximum Fluid Output of the recipe.
• "nbt": for modifiers (Read Output Modifiers)
• "type": Identifier of the Output Type

"output": {
	"output": {
		"item": "ic2:raw_aluminium",
		"count": 1
	},
	"minOut": 75,
	"maxOut": 105,
	"fluidOutput": {
		"fluid": "minecraft:empty",
		"amount": 0
	},
	"minFluid": 0,
	"maxFluid": 0,
	"nbt": "{time_mod:0.5d}",
	"type": "ic2:range"
}

Output Modifiers

Since Basic Machines are a bit more flexible then other Machines and some recipes should take different amount of time, there is a need for a control system.
This is the Output Modifiers in the "nbt" section of Recipe Ouputs.
There is 5 total Modifiers that can be applied:

• "consume_containers": boolean, which makes it so if you have a water bucket in your recipe you won't get a Bucket back in the output.
• "time_add": integer, Adds a flat amount of time to the recipe time.
• "time_mod": double, Multiples the recipe time, after the flat addition was made.
• "energy_add": integer, Adds a flat amount to the Energy the Machine consumes per tick.
• "energy_mod": double, Multiplies the amount of energy the Machine consumes per tick, after the flat addition was made.

The Modifiers are applied after the Upgrades were applied.
Meaning if your machine takes normally 16 EU and you say it should be 4x the cost, it would then take 64EU/t to run it.
While if there is enough efficiency upgrades in the machine to get it down to 1EU/t, the absolute minimum, it will only take 4EU/t to run.

The Time modifier for example isn't affected by Overclocker upgrades.
You set the Maximum Time it needs to process it, while the overclockers decide how much progress towards the max is made.

The Formular for how the modifiers are applied is the following:

   round((base + add) * multiplier)

Base being the input after the Upgrades were applied.

Inputs

There is a lot of different inputs that can exist.
So IC2Classic has a Input System, which is fully serialize-able.
Addons can also register their own Inputs that can be defined as they wish.

These Inputs are defined by the "type" argument

Item

Simple Minecraft Item Input

• "item": The item that should be tested against.
• "size": How big the stacksize should be.
• "type": Registry Identifier

{
	"item": "minecraft:blaze_rod",
	"size": 1, 
	"type": "ic2:item"
}

Tag

Simple Minecraft Tag Input

• "tag": The Minecraft Tag that should be tested for.
• "size": How big the stacksize should be.
• "type": Registry Identifier

{
	"tag": "forge:ores/gold",
	"size": 1,
	"type": "ic2:tag"
}

NBTStack

Minecraft Item Input with NBT Support

• "item": The item that should be tested against.
• "count": "Unused" can be anything, but is still there due to how ItemStacks are serialized.
• "size": How big the stacksize should be.
• "nbt": NBTData in the item. Can be a String that is SNBT (what command blocks use) or use json structure. (Optional)
• "type": Registry Identifier

{
	"item": {
		"item": "minecraft:blaze_powder",
		"count": 5,
		"nbt": {
			"Damage": 5
		}
	},
	"size": 5,
	"type": "ic2:nbtstack"
}

Array

Simple List of Elements Input

• "size": How big the stacksize should be.
• "and": If all inputs are required or if one of them has to match.
• "elements": Array of Inputs.
• "type": Registry Identifier

{
	"size": 1,
	"and": false,
	"elements": [
		{
			"tag": "forge:ingots/silver",
			"size": 1
		},
		{
			"tag": "forge:ingots/bronze",
			"size": 1
		}
	],
	"type": "ic2:array"
}

Ingredient

Minecraft Ingredient Input

• "ingredient": Minecrafts Ingredient System
• "size": How big the stacksize should be.
• "type": Registry Identifier

{
	"ingredient": {
		"item": "minecraft:blaze_rod"
	}
	"size": 1, 
	"type": "ic2:ingredient"
}

Fluid

Simple Minecraft Fluid Input that allows any item that contains said fluid.

• "fluid": The Fluid that should be tested against
• "size": How big the stacksize should be.
• "amount": How much fluid the container should contain at minimum.
• "type": Registry Identifier

{
	"fluid": "minecraft:water",
	"amount": 1000,
	"size": 1,
	"type": "ic2:fluid",
}

StackList

Item List Input with NBT Support

• "items": A List of NBTStack entries.
• "item": The item that should be tested against.
• "nbt": Items NBTData (optional)
• "or": If all Entries have to match or not.
• "size": How big the stacksize should be.
• "type": Registry Identifier

{
	"items": [
		{
			"item": "minecraft:blaze_powder",
			"nbt": {
				"Damage": 5
			}
		}
	]
	"or": "false",
	"size": 5,
	"type": "ic2:item_list"
}

Crop

IC2 Crop input that filters for specific ic2 crops.

• "crop": What crop should be used. (SeedBag shows the ids in its NBT)
• "size": How big the stacksize should be.
• "type": Registry Identifier

{
	"crop": "ic2:allium",
	"size": 1,
	"type": "ic2:crop"
}

Undamaged Item

Damage Detector Input

• "item": The item that should be tested against.
• "undamaged": If the Item should be Damaged or not.
• "type": Registry Identifier

{
	"item": "minecraft:golden_axe",
	"undamaged": false,
	"type": "ic2:damaged"
}

Sub Item

Simple Minecraft Item Input that uses the Creative Tab to find all its Sub Variants for JEI.

• "item": The item that should be tested against.
• "size": How big the stacksize should be.
• "type": Registry Identifier

{
	"item": "ic2:crop_seed",
	"size": 1,
	"type": "ic2:sub_item",
}

Empty Input

Expects the Slot to be empty.

• "type": Registry Identifier

{
	"type": "ic2:empty"
}