-
Notifications
You must be signed in to change notification settings - Fork 2
π§ How does it work?
Before developing this software, I had to think of a solution that would allow me to add custom blocks and items without overriding existing textures.
Figuring that out wasn't hard because there are already servers that use this kind of technology. (servers like OriginRealms or MineClub for example).
Again, by saying "without overriding existing textures" I mean it to a certain level.
It is almost impossible to avoid that whilst adding blocks, however, items are much different.
Items have a thing called CustomModelData
that is crucial when it comes to custom texturing.
By attaching a special NBT tag to an item, we can easily control its texture.
Each and every single custom block generated by ResourcePacker is based on one of the states of a note block.
Yes, a variant of a note block.
Note blocks in Minecraft not only have 23 different note states but also 16 instruments!
With that amount of variations we are able to use them to add our new blocks.
Considering the information written above, if we multiply all possible note states by the amount of unique instruments, we get our limit.
Here's the actual math:
23 (all notes) x 16 (all instruments) x 2 (whether powered or not) = 736 (possible combinations)
Therefore, we know the program is capable of creating 736 unique blocks without overriding any blocks other than a note block.
Imagine if we had to override existing blocks like: stone
, dirt,
, grass_block
... and so on.
That would be a disaster. Not only we demand more blocks but also we lose more original textures.
This is why our solution is much better.
This is what ResourcePacker does to configure the Note Block model.
{
"variants": {
"instrument=harp,note=0": {
"model": "packer:block/dark_tile"
},
"instrument=harp,note=1": {
"model": "packer:block/tile"
},
"instrument=harp,note=2": {
"model": "packer:block/header_tile"
}
}
}
We can clearly see above that each custom block model belongs to a unique variant.
When the note finally reaches the Minecraft limit (23), we switch the instrument and start counting notes from 0 again.
That's how we achieve the uniqueness of variants that let us add custom blocks without a problem.
As mentioned in the first paragraph, items use CustomModelData
that makes it possible to control the textures without any effort.
Our software uses minecraft:paper
item as its "worker" to put all the textures on top of it.
All custom generated items (not block items) are always a paper that contains a unique NBT data.
There are also block items that work the same but use minecraft:note_block
item instead.
The limit isn't really noticeable, as long as you keep the amount of items at a reasonable range.
What I mean by that is I don't believe someone's going to need a resource pack with 50 million items...
But finally, the answer is about 16 million units (aka items).
Minecraft internally converts the custom model data integer to float, causing a precision loss for some numbers above 16 million.
Therefore, if you don't go over that, you will be fine :)
This is what ResourcePacker does to configure the Paper model for regular items.
{
"parent": "item/generated",
"textures": {
"layer0": "item/paper"
},
"overrides": [
{
"predicate": {
"custom_model_data": 1
},
"model": "packer:item/eye_fish"
},
{
"predicate": {
"custom_model_data": 2
},
"model": "packer:item/use_lights"
},
{
"predicate": {
"custom_model_data": 3
},
"model": "packer:item/free_parking"
}
]
}
The data starts from 1
and each item has a unique custom model data.
This is what ResourcePacker does to configure the Note Block model for block items.
{
"parent": "minecraft:block/note_block",
"overrides": [
{
"predicate": {
"custom_model_data": 1
},
"model": "packer:item/dark_tile"
},
{
"predicate": {
"custom_model_data": 2
},
"model": "packer:item/tile"
},
{
"predicate": {
"custom_model_data": 3
},
"model": "packer:item/header_tile"
}
]
}
The data starts from 1
and each item has a unique custom model data.