Line 1: |
Line 1: |
| Blockstate JSONs are Minecraft’s way to map “variant strings” to models. A variant string can be absolutely anything, from “inventory” to “power=5” to “I am your father.” They represent an actual model, where the blockstate is just a container for them. In code, a variant string within a blockstate JSON is represented by a <code>ModelResourceLocation</code>. | | Blockstate JSONs are Minecraft’s way to map “variant strings” to models. A variant string can be absolutely anything, from “inventory” to “power=5” to “I am your father.” They represent an actual model, where the blockstate is just a container for them. In code, a variant string within a blockstate JSON is represented by a <code>ModelResourceLocation</code>. |
| | | |
− | When the game searches for a model corresponding to a block in the world, it takes the [[BlockState JSONs|blockstate]] for that position, and then it uses a map within <code>ModelManager</code> to find the corresponding <code>ModelResourceLocation</code> for it, which then refers to the actual model. <code>BlockModelShapes</code> uses the block's registry name as the location of the blockstate JSON. (E.g. block <code>examplemod:testblock</code> goes to the <code>ResourceLocation</code> <code>examplemod:testblock</code>.) The variant string is pieced together from the <code>BlockState</code>'s properties. | + | When the game searches for a model corresponding to a block in the world, it takes the [[BlockState JSONs|blockstate]] for that position, and then it uses a map within <code>ModelManager</code> to find the corresponding <code>ModelResourceLocation</code> for it, which then refers to the actual model. <code>BlockModelShaper</code> uses the block's registry name as the location of the blockstate JSON. (E.g. block <code>examplemod:testblock</code> goes to the <code>ResourceLocation</code> <code>examplemod:testblock</code>.) The variant string is pieced together from the <code>BlockState</code>'s properties. |
| | | |
| As an example, let’s take a look at the vanilla <code>oak_log.json</code>: | | As an example, let’s take a look at the vanilla <code>oak_log.json</code>: |
Line 38: |
Line 38: |
| { | | { |
| "when": { "east": "true" }, | | "when": { "east": "true" }, |
− | "apply": { "model": "oak_fence_side", "y": 90, "uvlock": true } | + | "apply": { "model": "minecraft:block/oak_fence_side", "y": 90, "uvlock": true } |
| } | | } |
| </syntaxhighlight> | | </syntaxhighlight> |
− | In this case, the JSON defines that if the east connector is true, then show the model <code>oak_fence_side</code> rotated 90 degrees. This allows the model to be broken up in only two files: the base post and the connection. It can also be represented as 5 statements, one that checks if each of the sides is connected and one that applies the base post unconditionally. | + | In this case, the JSON defines that if the east connector is true, then show the model <code>minecraft:block/oak_fence_side</code> rotated 90 degrees. This allows the model to be broken up in only two files: the base post and the connection. It can also be represented as 5 statements, one that checks if each of the sides is connected and one that applies the base post unconditionally. |
| | | |
| | | |
| [[Category:Models]] | | [[Category:Models]] |