This is going to be quite lengthy, apologies, but it's quite difficult to explain the exact problem so bear with me. (I've looked everywhere for an example of this in action and can't seem to find anything, so if anyone knows of a good working example for this specific use case I'd like to see it!)
---
I'm having a few issues with getting metadata-based block models to work. I have a block with a number of variants defined by metadata, and these variants are similar in function and usage to coloured blocks in vanilla, in that they each have a slightly different crafting recipe but can be used interchangeably in some cases (specifically, the variants correspond to the different elements in wizardry). For example, take wool: you need different coloured dyes for different coloured wool, but any colours can be used to make a bed. Like wool, each variant of my block has a different texture.
Now, I'd like it to be possible for variants to be added easily if an add-on mod adds an element, so rather than having a single blockstate file containing different variants for each element, I want each variant to have a separate file, so add-ons don't have to overwrite the existing ones. Vanilla wool also works like this; there are 16 blockstate files for wool, one of each colour. I therefore registered a custom state mapper using StateMap.Builder, and added the necessary blockstate and model files.
This worked fine in game, however, from the spam that is now filling my log, it seems that the game is still trying to use the DefaultStateMapper as well as my custom one, since it's printing out a MissingVariantException for each variant, all of which are caused by a FileNotFoundException with the filename as the block's registry name (which is never requested by the custom state mapper). Obviously I don't want to release a mod that fills the log with spurious error messages (or I'll get a ton of bug reports!), so why is this happening and how can I stop it?
A related but different problem: in order to get the block model to show up both on the itemblock (in the inventory) and when placed, I had to define both the "inventory" and "normal" variants in the blockstate file, whereas vanilla blocks without property variants only ever define "normal". To try and get around this, I used Forge's "default" feature to define the model and left the variant objects blank, but this broke all of the models completely.
TL;DR: I'm really confused, vanilla blockstates aren't behaving how I expect them to and Forge's format is only compounding this problem, so can someone show me the correct way to write a blockstate file using Forge's format, and the statemapper and model registry code that goes with it?
And, because I know you'll ask, here's one of my blockstate files (they all follow the exact same pattern):
ModelLoader.setCustomStateMapper(WizardryBlocks.crystal_block, new StateMap.Builder()
.withName(BlockCrystal.ELEMENT).withSuffix("_crystal_block").build());
This is going to be quite lengthy, apologies, but it's quite difficult to explain the exact problem so bear with me. (I've looked everywhere for an example of this in action and can't seem to find anything, so if anyone knows of a good working example for this specific use case I'd like to see it!)
---
I'm having a few issues with getting metadata-based block models to work. I have a block with a number of variants defined by metadata, and these variants are similar in function and usage to coloured blocks in vanilla, in that they each have a slightly different crafting recipe but can be used interchangeably in some cases (specifically, the variants correspond to the different elements in wizardry). For example, take wool: you need different coloured dyes for different coloured wool, but any colours can be used to make a bed. Like wool, each variant of my block has a different texture.
Now, I'd like it to be possible for variants to be added easily if an add-on mod adds an element, so rather than having a single blockstate file containing different variants for each element, I want each variant to have a separate file, so add-ons don't have to overwrite the existing ones. Vanilla wool also works like this; there are 16 blockstate files for wool, one of each colour. I therefore registered a custom state mapper using StateMap.Builder, and added the necessary blockstate and model files.
This worked fine in game, however, from the spam that is now filling my log, it seems that the game is still trying to use the DefaultStateMapper as well as my custom one, since it's printing out a MissingVariantException for each variant, all of which are caused by a FileNotFoundException with the filename as the block's registry name (which is never requested by the custom state mapper). Obviously I don't want to release a mod that fills the log with spurious error messages (or I'll get a ton of bug reports!), so why is this happening and how can I stop it?
A related but different problem: in order to get the block model to show up both on the itemblock (in the inventory) and when placed, I had to define both the "inventory" and "normal" variants in the blockstate file, whereas vanilla blocks without property variants only ever define "normal". To try and get around this, I used Forge's "default" feature to define the model and left the variant objects blank, but this broke all of the models completely.
TL;DR: I'm really confused, vanilla blockstates aren't behaving how I expect them to and Forge's format is only compounding this problem, so can someone show me the correct way to write a blockstate file using Forge's format, and the statemapper and model registry code that goes with it?
And, because I know you'll ask, here's one of my blockstate files (they all follow the exact same pattern):
With defaults (doesn't work at all):
Without defaults, using the vanilla format (works, but causes incorrect error messages - although I think that's the code, not the json file):
... and the state mapper code:
Any help is appreciated!
This is what I have for the block model json