Skip to content

Resourcepacks: Blockmap.json

­Sollace edited this page Nov 27, 2021 · 6 revisions

Back

The blockmap.json simply contains a mapping from a block's name to one or more material types to play for that block, separated by a comma (,) with no spaces. This is what controls which blocks Presence Foosteps supports and will be the main component for adding new blocks, or updating existing.

A full example file can be found here for the entire vanilla game and is what Presence Foosteps will include by default when downloaded.

A new resourcepack will place the blockmap.json at /assets/presencefootsteps/config/blockmap.json.

Key Syntax

Blocks can be matched according to a number of criteria. The simplest form is just by their name:

"minecraft:stone": "stone"

However, though this works for simple, solid blocks, sometimes you might need more a more fine-grained control, especially in situations where you have a lot of blocks that map in the same way, need to differentiate between different blockstate values, or want the block to behave like carpets, ferns, or fences.

To solves this problem, the blockmap allows for a wide range of formats all building on each other.

Matching BlockStates

Individual blockstates can be matched by appending their keys=value onto the end of the block's name, surrounded by square brackets. Here is the entry for pistons, for example.

"minecraft:piston_head[facing=up,type=sticky]": "wood_sticky",
"minecraft:piston_head": "wood"

In this example the piston's head is set to produce wood sounds in all cases except when it is A) a sticky piston's head, and B) is facing up. In the case that both A and B match, it will produce a sticky wooden sound instead, as the player would be walking on the slime balls.

Matching Substrates

To allow for different behaviours, you can also append a substrate - in this case a special class name that Presence Footsteps recognises - onto the end of the key.

The block name and the substrate have to be separated by a dot (.) and substrates appear after any blockstate values.

"minecraft:oak_fence_gate.bigger": "bluntwood"

There are so far, only a small number of primitives supported by Presence Footeps. This table will be updated over time as new ones are added.

Primitive Usage Description
bigger Fences and Walls Intended for blocks that are 1.5 meters tall. Normally these blocks wouldn't produce a sound, as the player isn't technically *on* these blocks, but the `bigger` primitive type extends the condition for them to work.
carpet Carpets, Pressure Plates Blocks with this primitive will play their walking sound when the player is inside the block, as well as sounds of the block beneath them.
messy Tall grass and Flowers Messy sounds are played alongside the normal ones when the player lands or jumps on this block
foliage Tall grass and Flowers Similar to messy, however this will cause the sounds to be played when the player brushes up against of passes through these blocks.
wet Rained upon and waterlogged Wet sounds are played alongside the normal ones when the players is on walking a block that is exposed to rain, is waterlogged, or otherwise submerged in water.

Matching Tags

Of course, as of 1.13/14 Minecraft has a gotten a lot more blocks. It's unreasonable to have to match all of them, especially if you're going to have bunches of 15+ blocks all with the exact same properties. That's why the blockmap also supports block tags.

Simply append a # to the beginning to indicate that the key you're specifying is a tag and not a block. Any blocks that are part of that tag will then be matched, thus turning something like this:

"minecraft:white_stained_glass": "glass",
"minecraft:orange_stained_glass": "glass",
"minecraft:magenta_stained_glass": "glass",
"minecraft:light_blue_stained_glass": "glass",
"minecraft:yellow_stained_glass": "glass",
"minecraft:lime_stained_glass": "glass",
"minecraft:pink_stained_glass": "glass",
"minecraft:gray_stained_glass": "glass",
"minecraft:light_gray_stained_glass": "glass",
"minecraft:cyan_stained_glass": "glass",
"minecraft:purple_stained_glass": "glass",
"minecraft:blue_stained_glass": "glass",
"minecraft:brown_stained_glass": "glass",
"minecraft:green_stained_glass": "glass",
"minecraft:red_stained_glass": "glass",
"minecraft:black_stained_glass": "glass",

"minecraft:white_stained_glass_pane": "glass",
"minecraft:orange_stained_glass_pane": "glass",
"minecraft:magenta_stained_glass_pane": "glass",
"minecraft:light_blue_stained_glass_pane": "glass",
"minecraft:yellow_stained_glass_pane": "glass",
"minecraft:lime_stained_glass_pane": "glass",
"minecraft:pink_stained_glass_pane": "glass",
"minecraft:gray_stained_glass_pane": "glass",
"minecraft:light_gray_stained_glass_pane": "glass",
"minecraft:cyan_stained_glass_pane": "glass",
"minecraft:purple_stained_glass_pane": "glass",
"minecraft:blue_stained_glass_pane": "glass",
"minecraft:brown_stained_glass_pane": "glass",
"minecraft:green_stained_glass_pane": "glass",
"minecraft:red_stained_glass_pane": "glass",
"minecraft:black_stained_glass_pane": "glass",

Into something more reasonable, like this:

"#minecraft:stained_glasses": "glass",

Note to Mojang: Pleeeeeeeeaaaaase add a #minecraft:stained_glasses tag, I would love you for life. ❤️

Value Syntax

Okay, so you know how to define the keys, but what are the values?

Simply put, the values are... whatever you want. They're the name of the material use for the block. You can use the names defined in acoustics.json or add your own with a custom acoustics.json.

There also to special values that you can use NOT_EMITTER and UNASSIGNED.

NOT_EMITTER is for when you want to acknowledge a block and specifically don't want it to produce any sounds. This is for technicaly blocks, and things like minecraft:air that you technically can't walk on.

When the block map finds a value of NOT_EMITTER Presence Footsteps will typically stop trying to find a sound for that block. Compare this to UNASSIGNED which literally means "there is no mapping" in which case PF will continue to try to find one, and if it doesn't the default minecraft sounds will play.

UNASSIGNED replaces the old system of adding entries and keeping them commented out in the blockmap, since you (kind of) can't have comments in a json file. Entries with a value of UNASSIGNED will not appear in the blockmap, at all. They're completely ignored which means those values are free to be overwritten by other resourcepacks.

Any blocks that are not in the blockmap will also produce a result of UNASSIGNED when generating debug reports.

You can look at the blockmap.json linked above to see what other values there are available, or continue on to the acoustics.json for a complete list and explanation of what all these values are and what they do.