Bow Texture Dependency

Recently I wrote an entire page dedicated to predicate values, within models.
Only after writing it did I discover an interesting oversight to do with bow models, which I posted on twitter.

In the video you can see the sword change material depending on the pull of the bow, wooden sword is shown when the bow is not being pulled, and a diamond sword will show when the bow is fully pulled back, this will affect the second bow anywhere in the hotbar, the offhand, or even when it’s on the player’s head.

So how did it work?

Firstly it uses two bows, the item in my offhand is another bow with a different damage value, the interesting thing comes from how the second bow had it’s predicates specified.

{ “predicate”: { “damage”: 0 }, “model”: “item/bow”},
{ “predicate”: { “damage”: 0, “pulling”: 1 }, “model”: “item/bow_pulling_0”},
{ “predicate”: { “damage”: 0, “pull”: 0.65, “pulling”: 1 }, “model”: “item/bow_pulling_1”},
{ “predicate”: { “damage”: 0, “pull”: 0.9, “pulling”: 1 }, “model”: “item/bow_pulling_2”},
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0 }, “model”: “item/wooden_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.333 }, “model”: “item/stone_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.667 }, “model”: “item/iron_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 1 }, “model”: “item/diamond_sword” },
{ “predicate”: { “damaged”: 1 }, “model”: “item/bow”},
{ “predicate”: { “damaged”: 1, “pulling”: 1 }, “model”: “item/bow_pulling_0”},
{ “predicate”: { “damaged”: 1, “pull”: 0.65, “pulling”: 1 }, “model”: “item/bow_pulling_1”},
{ “predicate”: { “damaged”: 1, “pull”: 0.9, “pulling”: 1 }, “model”: “item/bow_pulling_2”}

There’s a lot of predicates, so let’s break it down into smaller chunks.

{ “predicate”: { “damage”: 0 }, “model”: “item/bow”},
{ “predicate”: { “damage”: 0, “pulling”: 1 }, “model”: “item/bow_pulling_0”},
{ “predicate”: { “damage”: 0, “pull”: 0.65, “pulling”: 1 }, “model”: “item/bow_pulling_1”},
{ “predicate”: { “damage”: 0, “pull”: 0.9, “pulling”: 1 }, “model”: “item/bow_pulling_2”},

This is the default bow model, it’s been modified so that it will show when using a bow with 0 damage.

{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0 }, “model”: “item/wooden_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.333 }, “model”: “item/stone_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 0.667 }, “model”: “item/iron_sword” },
{ “predicate”: { “damaged”: 0, “damage”: 0.0025974025974025974, “pull”: 1 }, “model”: “item/diamond_sword” },

This is the predicates used to display the swords, the thing to notice between these values and the previous values is the fact that “pulling”: 1 is not used. This is what causes the bow to animate when pulling another bow.
The “pull” predicate does not check whether the player is holding that specific bow in it’s hand, but “pulling” does, so specifying “pulling” will cause the bow only to animate if it is that bow that is being pulled.

The last 4 predicates are the same as the first 4 but are used when the bow is damaged ie when the bow is not unbreakable, so the default bow is used when the bow is not unbreakable.

Download this example resourcepack

This only affects bows and will not work with any other items, also the second bow is a bow itself, which could cause some problems if used as the player could potentially fire the second bow.

I have reported this behaviour to the bug tracker which thanks to another user has some code analysis, including a simple fix, which means this oversight will probably be fixed some time.

Although this means that you need to specify “pulling”: 1 for each override that is used when the bow is being pulled, if you want to have several bow models using different damage values, or you may run into this problem.

Bow Texture Dependency

Patterns in Minecraft’s “Random” Multipart Models

 

Multipart blockstates allow models to be “added together” into one block when ceratin blockstates occur. You can specify the same blockstate several times for multiple models to be “added” when one specific blockstate has a certain value.

{“multipart: [
{“apply”: {“model”: “model1”}},
{“apply”: {“model”: “model2”}}
]}

This file will always apply two models to the block no matter what. Multipart blockstates allow for several models to be supplied via an array, in this case one model will be chosen at random from the array.

“apply”: [
{“model”: “model1”},
{“model”: “model2”}
]

In this case model1 or model2 will be applied but not at the same time.

Combining both of these features together leads to some intersting behaviour.

This is a blockstate file with 16 models in each array, with 4 arrays total, the arrays are in the same order of colours and in the screenshot you can see that each tower will have the same colour for each step.
This shows us that although the blockstate file chooses a random model this array index is used each time for each array, rather than what might be expected to happen which is for a random colour for each step.

This file has 4 arrays but the 2nd, 3rd, and 4th arrays only contain 8 objects, rather than the first which contains 16.
You’ll notice that the top 3 steps are all the same colour but the bottom step is not, but it will still follow a pattern. The black bottom will have black steps on it, but so will the magenta bottom step. Magenta is the first colour missed of the 8 object arrays, so it can be seen that the array will wrap around back to the top of the array when there is less objects in one array than another, but only if one of the arrayss is a multiple of the other.

 

These screenshots show a blockstate file with arrays containg 16, 8, 4, 2 objects and 15, 5, 3 objects, you should be able to spot the patterns here. Each colour step will only appear on top of a certain number of other coloured steps, you should also notice the exact same tower being made several times in each screenshot.

This final screenshot shows weighted values, you can see although some of the values have been weighted, patterns still emerge. The weighted values are picked more often, you may notice that the link between the top two steps and the bottom two steps has no pattern, meaning that weighting the values has broken some of the predictableness of the models.
It does not matter the order of the lists for the weighted values, they will always appear together, which suggests that the weighted values are pulled out of the array and then treated differently as the array models index will match up, ie the top two steps will be the same colour as long as only the weighted values are moved around the array.

random

Although there is predictable patterns that can be made with multipart blockstates, there is ways to disable them which involves either have the arrays not be the same size or multiples of each other, alternatively giving the values in the list different weights and different weights for the other arrays as well, will produce random model selection as viewed above.

Patterns in Minecraft’s “Random” Multipart Models