config block states - BuiltBrokenModding/ICBM-Classic GitHub Wiki
Info
Block State config system allows blasts to be adjusted via config. In many cases this may involve changing which blocks are allowed to be destroyed, changed, mutated, or otherwise impacted. Not all blast support this system but those that do should be documented.
BlockState
A block state is each unique block and property combination in minecraft. Stone for example may be minecraft:stone but have a unique state of minecraft:stone@0 and minecraft:stone@1 for different types.
Format supported by ICBM for most configs is as followed
Block
Format: domain:resource
Examples: minecraft:stone, forge:fluid, icbmclassic:explosive
This will be just the key used to register a block. The domain will be either minecraft, forge, or a mod's id. With the resource being either a single word or series of words with separators. Some mods will use . or _ to separate words. See each mod's documentation for a list of blocks or use a tool like NEI/JEI to lookup.
The id will not always match the mod's name. Neither will the resource always match the block's name.
Metadata
format: domain:resource@number
Examples: minecraft:stone@0, minecraft:leave0@10, icbmclassic:explosive@5
Quick way to get some block states for Minecraft 1.12. Not supported in newer version as metadata was removed from the base game. Newer versions view each blockState as a unique block. Exceptions to this where render or location specific properties. Such as rotation, on/off, or random.
BlockState
format: domain:resource[property:value, property*:value*]
Examples: minecraft:lever[face:wall,facing:north,powered:false]
Can't be combined with metadata version. As metadata is a quick lookup for properties. Each property is a unique state of the block. Some blocks may only have a single property such as facing. While other blocks may have several depending complexity. Simple looking blocks may actually be far more complex in terms of data. Use tools to detect which properties to use. Not all properties are useful. Such as facing only being used for rotation when placed.
Rule of thumb: if the property isn't related to a unique item. Then it can be ignored to prevent over unique specifiers.
Replacements
format: input=output or input=output,chance/condition
example: minecraft:stone@0=minecraft:cobblestone
Follows the same general options for block/blockState. Only using a = to split the input from the output. Not all configs will support chance or conditionals. See each mechanic or feature documentation to better understand what is supported.
replacements do not chain, so if you have water -> ice and then ice -> stone. The result will only use the first entry found. This is currently to reduce chance of loops and complexity in the code base. Future systems may allow this for advanced functionality. Such as map data systems using properties like heat, radioactive material, or in-world crafting
Chance
Supported by: EMP and Mutation (nuclear) blast
format: @chance(value) with value being between 0.0 and 1.0 floating
example: minecraft:dirt=minecraft:stone;@chance(0.5); 0.5 being 50%
Chance for replacement to trigger
NBT Replacements
Supported by: EMP and Mutation (nuclear) blast
format: @nbt({"field":"value"})
example: minecraft:dirt=minecraft:stone;@nbt({"energy":0})
Allows editing a tiles NBT via merge overriding. Can be combined with ~ to maintain the blocks state but replace only the NBT value. Example: power:machine:~;@nbt({"energy":0}
It is important to understand this does allow storing anything on a tile. Meaning tools are required to check for the correct field, type, and that it is merging as expected. Failure to do so can cause a mod to crash unexpectedly. As this isn't a recommend method by other modders. Only exists to allow work arounds for lack of API features in target blocks.