I have tried to create a block with two blockstates (`facing` and `burning`), based on the vanilla Dispenser block. For whatever reason, the texture is not appearing on the block, but it does appear on the inventory item.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Nope, only a warning about missing variant `#normal` for the block... But as far as I can tell, the `#normal` variant shouldn't be required because of the default block state.
I found the issue: The BaseItemBlock(BlockRegistry.Data, Block) constructor passes the Block argument to the super constructor (so this is the Block that's placed in the world) but then creates an unrelated instance of BaseBlock. The Block argument is never registered, only the BaseBlock instance is.
I suggest you fix this by doing the following:
Delete the BaseBlockContainer class, make BlockAlloyFurnace extend BaseBlock and override Block#hasTileEntity(IBlockState) and Block#createTileEntity. There's no reason to use BlockContainer/ITileEntityProvider.
Register the Block returned by ItemBlock#getBlock instead of the BaseItemBlock#block field. Don't create an instance of BaseBlock in the BaseItemBlock constructor. Consider removing the BaseItemBlock#block field entirely.
There's no reason to call ItemBlock#setCreativeTab or ItemBlock#setUnlocalizedName, the corresponding getters both delegate to the Block instead of using the fields set by the setters.
You're also missing @Nullable/@Nonnull annotations, which your IDE should warn you about. Consider copying the package-info.java file generated by MCP from a vanilla package into each of your own packages, this will mark all methods and parameters as @Nonnull by default.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Thanks @Choonster, guess I let my coding standards slip during my frustration... I should have also explained that the Block does need to implement ITileEntityProvider because it will have a TileEntity.
I (think) I have implemented your suggestions, however the issue still remains. Any further assistance would be greatly appreciated! The links to the files in the OP should still work and be relevant.
Thanks @Choonster, guess I let my coding standards slip during my frustration... I should have also explained that the Block does need to implement ITileEntityProvider because it will have a TileEntity.
There's no reason to use BlockContainer or ITileEntityProvider, any Block can have a TileEntity if it overrides Block#hasTileEntity(IBlockState) and Block#createTileEntity.
There's also no reason to override a method (e.g. Block#getRenderType) if you're going to return the same value as the super method (e.g. EnumBlockRenderType.MODEL). The override was necessary when you were extending BlockContainer, but it's not now that you're extending Block.
Block#onBlockPlaced has been deprecated in favour of Block#getStateForPlacement.
I (think) I have implemented your suggestions, however the issue still remains. Any further assistance would be greatly appreciated! The links to the files in the OP should still work and be relevant.
[21:13:00] [Client thread/ERROR] [FML]: Exception loading model for variant plutomc_core:alloy_furnace#burning=false,facing=west for blockstate "plutomc_core:alloy_furnace[burning=false,facing=west]"
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model plutomc_core:alloy_furnace#burning=false,facing=west with loader VariantLoader.INSTANCE, skipping
...
Caused by: net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException
"burning=false,facing=north" isn't the same as "facing=north,burning=false". Each variant in the blockstates file must match the variant that Minecraft looks for exactly (properties in alphabetical order, all lowercase).
You can also use Forge's blockstates format, which allows you to specify the effect of each property value on the model instead of specifying the model for every possible combination of property values.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
It's a shame there's no full documentation available for Forge. Perhaps the details about the order of things in vanilla blockstate JSONs should be mentioned here?
If you want a page changed, you can submit a pull request to Forge's documentation on GitHub.
Rollback Post to RevisionRollBack
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
I have tried to create a block with two blockstates (`facing` and `burning`), based on the vanilla Dispenser block. For whatever reason, the texture is not appearing on the block, but it does appear on the inventory item.
GitHub Repository
Relevant files:
Thanks a lot in advance, I'm seriously stumped.
Are there errors in the log?
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Nope, only a warning about missing variant `#normal` for the block... But as far as I can tell, the `#normal` variant shouldn't be required because of the default block state.
I found the issue: The BaseItemBlock(BlockRegistry.Data, Block) constructor passes the Block argument to the super constructor (so this is the Block that's placed in the world) but then creates an unrelated instance of BaseBlock. The Block argument is never registered, only the BaseBlock instance is.
I suggest you fix this by doing the following:
There's no reason to call ItemBlock#setCreativeTab or ItemBlock#setUnlocalizedName, the corresponding getters both delegate to the Block instead of using the fields set by the setters.
You're also missing @Nullable/@Nonnull annotations, which your IDE should warn you about. Consider copying the package-info.java file generated by MCP from a vanilla package into each of your own packages, this will mark all methods and parameters as @Nonnull by default.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Thanks @Choonster, guess I let my coding standards slip during my frustration... I should have also explained that the Block does need to implement ITileEntityProvider because it will have a TileEntity.
I (think) I have implemented your suggestions, however the issue still remains. Any further assistance would be greatly appreciated! The links to the files in the OP should still work and be relevant.
There's no reason to use BlockContainer or ITileEntityProvider, any Block can have a TileEntity if it overrides Block#hasTileEntity(IBlockState) and Block#createTileEntity.
There's also no reason to override a method (e.g. Block#getRenderType) if you're going to return the same value as the super method (e.g. EnumBlockRenderType.MODEL). The override was necessary when you were extending BlockContainer, but it's not now that you're extending Block.
Block#onBlockPlaced has been deprecated in favour of Block#getStateForPlacement.
"burning=false,facing=north" isn't the same as "facing=north,burning=false". Each variant in the blockstates file must match the variant that Minecraft looks for exactly (properties in alphabetical order, all lowercase).
You can also use Forge's blockstates format, which allows you to specify the effect of each property value on the model instead of specifying the model for every possible combination of property values.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Absolute legend. Thanks so much, got 'em working.
It's a shame there's no full documentation available for Forge. Perhaps the details about the order of things in vanilla blockstate JSONs should be mentioned here?
If you want a page changed, you can submit a pull request to Forge's documentation on GitHub.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.