Draco18s

Your Container is broken. Also, you didn't post any code.

I'm sure vanilla manages this somewhere. I'm sure you could look at it. Even if that fails, I'm sure an IBlockState decomposes into a collection of values that can be contained within a packet.

public void preInit(FMLPreInitializationEvent event) { logger = event.getModLog(); }

You already have a thread about this:

What do you mean, you can't call it because of one of the parameters? What about that parameter? Which one? What are you doing? From where?

Random question: Why are you printing to standard error? You know every mod had a mod specific logger, right? (Also... System.out is a Thing...)

You can't create an ItemStack out of an IBlockState. You have to ask the block to give you an item stack for the given state (getDrop or getPickBlock)

Not really. But I do know you'll be interested in ISimpleBlockRenderingHandler

Sorry, I missed the version number you're on. 1.7.10 isn't supported here any more.

Use multiple layers. For example, all of my ores use this model: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/models/block/hardore.json Note there are twelve faces specified: each face of the block (up, down, north, etc) is specified twice with different textures each time. You can use blockstates to indicate which texture-file (cross.png) gets drawn in each texture-reference (#overlay, #base, #foo).

Change the size of the item stack.

When would you like to do this?

Second time this exact problem this week. The Block + Meta problem probably needs to go into the common issues thread.

No worries! We all have days like that. Heck, there have been times when writing up a post to as a question or figure out a bug, I'll arrive at the solution. It's called rubber duck debugging.

You can't remove the blocks from being in existence, but you can remove them from the world. There's an OreGen event, you would just need to subscribe to it, then cancel it. (I'm blanking on the exact name atm)

AH HA, that debug output solves it: String str = b.getPropertyString(state.getProperties()); ModelResourceLocation mrl = new ModelResourceLocation(state.getBlock().getRegistryName(), str); // HERE Log.info("Registering variant : " + str + " -- Meta : " + this.getMetaFromState(state) + " @ " + mrl.toString()); ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(state.getBlock()), this.getMetaFromState(state), mrl);

You don't use "inventory" for metadata blocks. Well, you can, but you need to then supply a JSON item model file to specify which texture to use (this is how vanilla does it). It's way easier to reuse the blockstate json for item models when possible (all hail Forge). This is why there's all that StateMapper#getPropertyString() stuff: we need to know what the state mapper says the variant string is so we can tell the Model Loader what variant model to go locate data for from the blockstate json.

You're not using the inventory variant, you're using the other variants: String str = b.getPropertyString(state.getProperties());

Oh, and then it redirects back into the block class. :V You're making things unnecessarily complicated and duplicate code. All of this: public void initModel() { StateMapperBase b = new DefaultStateMapper(); BlockStateContainer bsc = this.getBlockState(); ImmutableList<IBlockState> values = bsc.getValidStates(); ResourceLocation mrla[] = new ResourceLocation[values.size()]; for(IBlockState state : values) { String str = b.getPropertyString(state.getProperties()); ModelResourceLocation mrl = new ModelResourceLocation(state.getBlock().getRegistryName(), "inventory"); Log.info("Registering variant : " + str + " -- Meta : " + this.getMetaFromState(state) + " @ " + mrl.toString()); Item.getItemFromBlock(state.getBlock()).getMetadata(0); ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(state.getBlock()), this.getMetaFromState(state), mrl); } } Can easily be inside a library class and you pass in the relevant block/item instead of using "this." Like this. Now then... This is unused: ResourceLocation mrla[] = new ResourceLocation[values.size()]; This does nothing: Item.getItemFromBlock(state.getBlock()).getMetadata(0); Beyond that...it looks exactly like my own code, so I can't see the error.

ModBlocks.initModels(); ModItems.initModels(); ModLayerStones.initModels(); oh good, we have no idea how you're registering your models. The exact code you're having a problem with.

Blocks default to using the blockstate json to determine their model. (That's what the "inventory" or "normal" variant section is for) Bare items use an item model json file (which is typically a subtype of item/generated which is itself a subtype of builtin/generated, which creates the model from a texture).

You need to subscribe to the ModelRegistryEvent in order to register models for your items with ModelLoader.setCustomModelResourceLocation

Ahh, that explains why I don't like it much. Too sporty for me. I don't need to go 230 mph down the highway, I just need to get there in a reasonable time. (Case in point, my actual car right now is a 1997 Honda CR-V, I bought it about a year ago and it had 112,000 miles on it, its now got 127,000 or so)

And just for an alternative viewpoint: I like Eclipse. I know D7 hates it, but I don't really know why. But the reason I like it is because it's refactoring tools are orders of magnitude better than any other IDE I'd ever used before. Seriously, look at the difference between Eclipse and Visual Studio. Know what else VS can't do? Specify a superclass and interfaces when creating it, automatically creating stubs for any abstract methods.