[SOLVED] [1.12] Prevent Forge looking for block models with vanilla TESR?

[IceMetalPunk]

In my mod, I'm basically hijacking vanilla shulker boxes to add a new block which is a simple trapped shulker box. That is, it's identical to a shulker box, except when opened, it emits a redstone signal like a trapped chest.

Everything works perfectly fine. Except that I get "model not found" errors in the console log, since it's using vanilla's shulker box Tile Entity to do the rendering rather than an actual model file.

 

The errors aren't fatal, and they cause no problems with the game; the boxes work and look exactly as they should. But I'm not comfortable releasing the mod with those errors still in. How do I stop Forge from looking for model files for my block when it doesn't use model files?

Edited July 7, 2017 by IceMetalPunk
Solved

[Leviathan143]

Override Block#getRenderType() to return EnumBlockRenderType.ENTITYBLOCK_ANIMATED. You will notice that the method is marked @Deprecated, this is fine. It's just Mojang's way of saying that these methods should not be called(Call the equivalents in IBlockState instead), however it is still fine to override them.

[IceMetalPunk]

33 minutes ago, Leviathan143 said:

Override Block#getRenderType() to return EnumBlockRenderType.ENTITYBLOCK_ANIMATED. You will notice that the method is marked @Deprecated, this is fine. It's just Mojang's way of saying that these methods should not be called(Call the equivalents in IBlockState instead), however it is still fine to override them.

My class extends the BlockShulkerBox class, which already does that... but just to be sure, I added another override like you suggested into my child class, and it still gives me the same "model not found" errors. EDIT Actually, I just realized that although the error is coming from the ModelLoader, it's the missing block *state* file that's causing the error. But that said, the block doesn't have any block states, either, so this still shouldn't be happening...

Here's the relevant class, if it helps: https://github.com/IceMetalPunk/RedPlusPlus/blob/master/main/java/com/icemetalpunk/redplusplus/blocks/BlockTrappedShulkerBox.java

Edited July 5, 2017 by IceMetalPunk

[Choonster]

Minecraft calls BlockModelShapes#registerBuiltInBlocks for the shulker box Blocks, which means that BlockStateMapper#getBlockstateLocations and BlockStateMapper#getVariants return an empty Set/Map respectively when called with one of the Blocks.

 

You can achieve the same result by implementing IStateMapper#putStateModelLocations to return an empty Map (using Collections.emptyMap) and registering an instance in ModelRegistryEvent using ModelLoader.setCustomStateMapper.

Edited July 5, 2017 by Choonster

[IceMetalPunk]

6 minutes ago, Choonster said:

Minecraft calls BlockModelShapes#registerBuiltInBlocks for the shulker box Blocks, which means that BlockStateMapper#getBlockstateLocations and BlockStateMapper#getVariants return an empty Set/Map respectively when called with one of the Blocks.

 

You can achieve the same result by implementing IStateMapper#putStateModelLocations to return an empty Map (using Collections.emptyMap) and registering an instance in ModelRegistryEvent using ModelLoader.setCustomStateMapper.

Thank you! This fixed it!

However, I now noticed something that may have been a problem before, but I didn't realize until now. The block-breaking particles from the trapped shulker boxes are the purple-and-black "no texture" image. Without a block model, how do I define the particle texture?

[Choonster]

17 minutes ago, IceMetalPunk said:

However, I now noticed something that may have been a problem before, but I didn't realize until now. The block-breaking particles from the trapped shulker boxes are the purple-and-black "no texture" image. Without a block model, how do I define the particle texture?

 

Vanilla hardcodes this for shulker boxes in BlockModelShapes#getTexture, but I think you'll need to create a model without any elements that specifies the "particle" texture and use it instead of registering an IStateMapper to ignore all states. 

[Leviathan143]

12 minutes ago, IceMetalPunk said:

Thank you! This fixed it!

However, I now noticed something that may have been a problem before, but I didn't realize until now. The block-breaking particles from the trapped shulker boxes are the purple-and-black "no texture" image. Without a block model, how do I define the particle texture?

You might like to know that you can replace TrappedShulkerStateMapper with an anonymous class. This allows you to avoid having to create a new class that you will only ever instantiate and use once. Since you are using 1.12 where Java 8 is required, you can also use a lambda expression instead. A lambda would be even shorter than the anonymous class. Which to use, or the choice to not use either at all is up to you. I just thought I'd inform you of some of Java's features that could make this easier.

[IceMetalPunk]

5 minutes ago, Choonster said:

 

Vanilla hardcodes this for shulker boxes in BlockModelShapes#getTexture, but I think you'll need to create a model without any elements that specifies the "particle" texture and use it instead of registering an IStateMapper to ignore all states. 

Oh...darn, that means I need to create 16 model files just for the particle texture Oh, well, if I must I must. Thank you!

3 minutes ago, Leviathan143 said:

You might like to know that you can replace TrappedShulkerStateMapper with an anonymous class. This allows you to avoid having to create a new class that you will only ever instantiate and use once. Since you are using 1.12 where Java 8 is required, you can also use a lambda expression instead. A lambda would be even shorter than the anonymous class. Which to use, or the choice to not use either at all is up to you. I just thought I'd inform you of some of Java's features that could make this easier.

Yes, that would have been more concise. It looks like I won't be using the state mapper anyway after all, as it breaks particles; but thank you anyway!

[Choonster]

1 minute ago, IceMetalPunk said:

Oh...darn, that means I need to create 16 model files just for the particle texture Oh, well, if I must I must. Thank you!

 

You don't need to create 16 models if you create an empty model and use Forge's blockstates format to specify the "particle" texture for each state.

[IceMetalPunk]

14 minutes ago, Choonster said:

 

You don't need to create 16 models if you create an empty model and use Forge's blockstates format to specify the "particle" texture for each state.

Ooh, fancy; I didn't realize Forge had its own extension to the blockstates format. I'll play around with it a bit and see if I can get something working well. Thanks!

 

EDIT Wait, darn. I'm not using block states for these; they're each a separate block instance, the same way Minecraft vanilla handles them. If I made them the same instance of the block and used block states, wouldn't that mess up the tile entity rendering? Or should I be using multiple block instances, each with a block state anyway for the sake of the particle definitions?

You know, I was so close to being finished with this, and now I'm just confused over tiny particles

Edited July 5, 2017 by IceMetalPunk

[Choonster]

27 minutes ago, IceMetalPunk said:

Ooh, fancy; I didn't realize Forge had its own extension to the blockstates format. I'll play around with it a bit and see if I can get something working well. Thanks!

 

EDIT Wait, darn. I'm not using block states for these; they're each a separate block instance, the same way Minecraft vanilla handles them. If I made them the same instance of the block and used block states, wouldn't that mess up the tile entity rendering? Or should I be using multiple block instances, each with a block state anyway for the sake of the particle definitions?

You know, I was so close to being finished with this, and now I'm just confused over tiny particles

 

Ah, I forgot that they're different instances rather than states of the same instance.

 

You can still use Forge's blockstates format, you'll just need to create a blockstates file for every colour (or register an IStateMapper to map them to variants of the same blockstates file).

[IceMetalPunk]

Ugh. So I went the route I mentioned, creating a block state with a "color" property so that each block instance would have its proper color state set, and then using the Forge blockstate format to override the particle definition. I got no errors, but the particles are still not showing up (they're black-and-purple).

I'll see about trying to map them with the state mapper instead, and hopefully that will go better.

 

EDIT Well, that didn't work >_< I'm now getting the following errors for each color of Shulker box:

 

Quote

[03:38:10] [main/ERROR] [FML]: Exception loading model for variant redplusplus:trapped_shulker_box#orange for blockstate "redplusplus:trapped_orange_shulker_box[facing=up]"
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model redplusplus:trapped_shulker_box#orange with loader VariantLoader.INSTANCE, skipping

I've pushed my latest changes to the repo linked above; I'm assuming I've misunderstood the extended BlockState format and done something wrong there, but while I look for that, any guidance would be appreciated.

Edited July 5, 2017 by IceMetalPunk

[Choonster]

Your IStateMapper implementation only specifies a model for the default state, but not for any of the other states.

 

It's probably easiest to extend StateMapperBase, this will call StateMapperBase#getModelResourceLocation for each state of the Block. All you need to do is return the same ModelResourceLocation from this method every time, ignoring the FACING property.

[IceMetalPunk]

4 minutes ago, Choonster said:

Your IStateMapper implementation only specifies a model for the default state, but not for any of the other states.

 

It's probably easiest to extend StateMapperBase, this will call StateMapperBase#getModelResourceLocation for each state of the Block. All you need to do is return the same ModelResourceLocation from this method every time, ignoring the FACING property.

You know, I've been working with my subclass for so long I forgot there even was a FACING property to think about >_< .

Unfortunately, that didn't seem to fix the issue. I changed the state mapper code to this:

 

		ModelLoader.setCustomStateMapper(this, new StateMapperBase() {

			@Override
			protected ModelResourceLocation getModelResourceLocation(IBlockState state) {
				return new ModelResourceLocation(RedPlusPlus.MODID + ":trapped_shulker_box",
						BlockTrappedShulkerBox.this.getColor().getName());
			}

		});

And I'm still getting the same errors, although now it's for every FACING state of each color:

Quote

[04:07:04] [main/ERROR] [FML]: Exception loading model for variant redplusplus:trapped_shulker_box#orange for blockstates ["redplusplus:trapped_orange_shulker_box[facing=up]", "redplusplus:trapped_orange_shulker_box[facing=north]", "redplusplus:trapped_orange_shulker_box[facing=down]", "redplusplus:trapped_orange_shulker_box[facing=west]", "redplusplus:trapped_orange_shulker_box[facing=east]", "redplusplus:trapped_orange_shulker_box[facing=south]"]
net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model redplusplus:trapped_shulker_box#orange with loader VariantLoader.INSTANCE, skipping

 

[Choonster]

1 minute ago, IceMetalPunk said:

You know, I've been working with my subclass for so long I forgot there even was a FACING property to think about >_< .

Unfortunately, that didn't seem to fix the issue. I changed the state mapper code to this:

 

		ModelLoader.setCustomStateMapper(this, new StateMapperBase() {

			@Override
			protected ModelResourceLocation getModelResourceLocation(IBlockState state) {
				return new ModelResourceLocation(RedPlusPlus.MODID + ":trapped_shulker_box",
						BlockTrappedShulkerBox.this.getColor().getName());
			}

		});

And I'm still getting the same errors, although now it's for every FACING state of each color:

 

Please post the full error or the full FML log. ModelLoaderRegistry.LoaderException is a just wrapper around the actual exception that was thrown by the model loader, which explains why the model failed to load.

 

You're getting one exception for all states because you're mapping all states to the same model.

[IceMetalPunk]

4 minutes ago, Choonster said:

 

Please post the full error or the full FML log. ModelLoaderRegistry.LoaderException is a just wrapper around the actual exception that was thrown by the model loader, which explains why the model failed to load.

 

You're getting one exception for all states because you're mapping all states to the same model.

You can find the full log here: https://www.dropbox.com/s/tplz3325pvw6xk6/fml-client-latest.log?dl=0 (The errors begin on line 393.)

 

But as far as I can tell, it doesn't give much more information than a "missing variant" for each of the colors; yet unless I'm missing something, I've defined all those color variants in my block state file.

Edited July 5, 2017 by IceMetalPunk
Added error line number in log

[Choonster]

8 minutes ago, IceMetalPunk said:

You can find the full log here: https://www.dropbox.com/s/tplz3325pvw6xk6/fml-client-latest.log?dl=0 (The errors begin on line 393.)

 

But as far as I can tell, it doesn't give much more information than a "missing variant" for each of the colors; yet unless I'm missing something, I've defined all those color variants in my block state file.

 

You're running into these limitations of Forge's blockstates format, so it's treating the individual colours as properties instead of fully-defined variants.

 

I suggest moving the individual colours to be values of a "color" property instead of being fully-defined variants and using "color=" + colorName as the ModelResourceLocation variant.

[IceMetalPunk]

On 7/5/2017 at 4:41 AM, Choonster said:

 

You're running into these limitations of Forge's blockstates format, so it's treating the individual colours as properties instead of fully-defined variants.

 

I suggest moving the individual colours to be values of a "color" property instead of being fully-defined variants and using "color=" + colorName as the ModelResourceLocation variant.

Aha! A little bit of fiddling later, and it all works now! Thank you!

Now if I could only figure out why I can't get .json-style recipes to show in the recipe book, my mod will be ready for release!