[1.9] [Solved] Blockstate file not loading

[Earthcomputer]

Hi

 

This is the first time I've tried to add custom blocks since block models have been added (I normally don't do this kind of stuff, I've done items though).

My item displays as you'd expect, like any other itemblock, but my block just uses the pink and black missing model and I get this error in the console on loading:

net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model justdoable:crafter#facing=up,triggered=false with loader VariantLoader.INSTANCE, skipping
at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:134) ~[ModelLoaderRegistry.class:?]
at net.minecraftforge.client.model.ModelLoader.registerVariant(ModelLoader.java:222) ~[ModelLoader.class:?]
at net.minecraft.client.renderer.block.model.ModelBakery.loadBlock(ModelBakery.java:144) ~[ModelBakery.class:?]
at net.minecraftforge.client.model.ModelLoader.loadBlocks(ModelLoader.java:210) ~[ModelLoader.class:?]
at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:127) ~[ModelLoader.class:?]
at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?]
at net.minecraft.client.resources.SimpleReloadableResourceManager.notifyReloadListeners(SimpleReloadableResourceManager.java:130) [simpleReloadableResourceManager.class:?]
at net.minecraft.client.resources.SimpleReloadableResourceManager.reloadResources(SimpleReloadableResourceManager.java:111) [simpleReloadableResourceManager.class:?]
at net.minecraft.client.Minecraft.refreshResources(Minecraft.java:792) [Minecraft.class:?]
at net.minecraftforge.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:323) [FMLClientHandler.class:?]
at net.minecraft.client.Minecraft.startGame(Minecraft.java:554) [Minecraft.class:?]
at net.minecraft.client.Minecraft.run(Minecraft.java:381) [Minecraft.class:?]
at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_65]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_65]
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_65]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_65]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_65]
at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?]
at GradleStart.main(GradleStart.java:26) [start/:?]
Caused by: net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException
at net.minecraft.client.renderer.block.model.ModelBlockDefinition.getVariant(ModelBlockDefinition.java:75) ~[ModelBlockDefinition.class:?]
at net.minecraftforge.client.model.ModelLoader$VariantLoader.loadModel(ModelLoader.java:1159) ~[ModelLoader$VariantLoader.class:?]
at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:130) ~[ModelLoaderRegistry.class:?]
... 24 more

 

It is only a very simple mod atm, so the block is registered and stuff in my main mod file:

package net.earthcomputer.justdoable;

import net.minecraft.block.Block;
import net.minecraft.block.properties.IProperty;
import net.minecraft.client.Minecraft;
import net.minecraft.client.renderer.block.model.ModelResourceLocation;
import net.minecraft.client.renderer.block.statemap.StateMap;
import net.minecraft.creativetab.CreativeTabs;
import net.minecraft.init.Blocks;
import net.minecraft.item.Item;
import net.minecraft.item.ItemBlock;
import net.minecraftforge.client.model.ModelLoader;
import net.minecraftforge.fml.common.Mod;
import net.minecraftforge.fml.common.Mod.EventHandler;
import net.minecraftforge.fml.common.Mod.Instance;
import net.minecraftforge.fml.common.event.FMLInitializationEvent;
import net.minecraftforge.fml.common.event.FMLPreInitializationEvent;
import net.minecraftforge.fml.common.network.NetworkRegistry;
import net.minecraftforge.fml.common.registry.GameRegistry;
import net.minecraftforge.fml.relauncher.Side;
import net.minecraftforge.fml.relauncher.SideOnly;
import net.minecraftforge.oredict.ShapedOreRecipe;

@Mod(modid = JustDoable.MODID, name = JustDoable.NAME, version = JustDoable.VERSION)
public class JustDoable {
public static final String MODID = "justdoable";
public static final String NAME = "Just Doable";
public static final String VERSION = "1.0";

@Instance(MODID)
public static JustDoable instance;

public static BlockCrafter crafter;

public static CreativeTabs CREATIVE_TAB = new CreativeTabs(MODID) {

	@Override
	public Item getTabIconItem() {
		return Item.getItemFromBlock(crafter);
	}

};

@EventHandler
public void preinit(FMLPreInitializationEvent e) {
	crafter = (BlockCrafter) new BlockCrafter().setUnlocalizedName("crafter").setCreativeTab(CREATIVE_TAB)
			.setRegistryName("crafter");
	GameRegistry.register(crafter);
	GameRegistry.register(new ItemBlock(crafter).setRegistryName(crafter.getRegistryName()));
	GameRegistry.addRecipe(new ShapedOreRecipe(crafter, "SSS", "SCS", "SRS", 'S', "cobblestone", 'C',
			Blocks.crafting_table, 'R', "dustRedstone"));
	GameRegistry.registerTileEntity(TileEntityCrafter.class, "Crafter");

	NetworkRegistry.INSTANCE.registerGuiHandler(this, new GuiHandler());
}

@SideOnly(Side.CLIENT)
@EventHandler
public void init(FMLInitializationEvent e) {
	registerTexture(crafter, "crafter", BlockCrafter.TRIGGERED);
}

private static void registerTexture(Block block, String textureName, IProperty<?>... ignoredProperties) {
	ModelLoader.setCustomStateMapper(block, new StateMap.Builder().ignore(ignoredProperties).build());
	registerTexture(Item.getItemFromBlock(block), textureName);
}

private static void registerTexture(Item item, String textureName) {
	Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item, 0,
			new ModelResourceLocation(MODID + ":" + textureName, "inventory"));
}
}

 

assets/justdoable/blockstates/crafter.json:

{
"variants": {
	"facing=down":  { "model": "justdoable:crafter_vertical", "x": 180 },
        "facing=up":    { "model": "justdoable:crafter_vertical" },
        "facing=north": { "model": "justdoable:crafter" },
        "facing=south": { "model": "justdoable:crafter", "y": 180 },
        "facing=west":  { "model": "justdoable:crafter", "y": 270 },
        "facing=east":  { "model": "justdoable:crafter", "y": 90 }
}
}

 

assets/justdoable/models/block/crafter.json:

{
    "parent": "block/orientable",
    "textures": {
        "top": "blocks/furnace_top",
        "front": "blocks/dispenser_front_horizontal",
        "side": "blocks/furnace_side"
    }
}

 

assets/justdoable/models/block/crafter_vertical.json:

{
    "parent": "block/orientable_vertical",
    "textures": {
        "front": "blocks/dispenser_front_vertical",
        "side": "blocks/furnace_top"
    }
}

 

Thanks in advance for help! I hope this isn't too much of a nooby question, knowing me I've probably done something really nooby that's caused it anyways

[Choonster]

  Quote

net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model justdoable:crafter#facing=up,triggered=false with loader VariantLoader.INSTANCE, skipping

 

Your block has two properties (

facing

and

triggered

), but your blockstates file only specifies variants for one of them (

facing

). You need to include both properties in your blockstates file.

[Earthcomputer]

Thanks! Isn't there a way to tell Minecraft that a certain property doesn't make a difference to the appearance, as my block is very similar to the vanilla dispenser, and my blockstate file is nearly the same as the dispenser blockstate file?

[Choonster]

Yes, create an

IStateMapper

and register it by calling

ModelLoader.setCustomStateMapper

.

 

You can either implement

IStateMapper

yourself or create a

StateMap.Builder

, call

StateMap.Builder#ignore

for each property you want to ignore and then call

StateMap.Builder#build

.

[Earthcomputer]

  On 4/30/2016 at 11:49 AM, Choonster said:

Yes, create an

IStateMapper

and register it by calling

ModelLoader.setCustomStateMapper

.

 

You can either implement

IStateMapper

yourself or create a

StateMap.Builder

, call

StateMap.Builder#ignore

for each property you want to ignore and then call

StateMap.Builder#build

.

 

I have already done that in the code I have given. Look again at the method

registerTexture(Block block, String textureName, IProperty<?>... ignoredProperties)

.

Does anyone know why this isn't working?

[Choonster]

Model registration should be handled in your client proxy or a dedicated class called from it.

 

Referencing client-only classes in a class loaded on both sides can easily crash the dedicated server with a

ClassNotFoundException

if you're not careful. diesieben07 has a post on why you shouldn't use

@SideOnly

here.

[Earthcomputer]

@diesieben07: Thanks for this! I knew it was something I didn't understand about the registries.

 

@Choonster: I am aware that it is better to use proxies, but in this case @SideOnly doesn't hurt because logical sides don't exist at loading time, so I used it for a temporary simple mod. However, as diesieben07 said to move the ModelLoader stuff to preinit, it looks like making proxies is the next stage

[jeffryfisher]

  On 4/30/2016 at 7:33 PM, Earthcomputer said:

@Choonster: I am aware that it is better to use proxies...

Since mc 1.8, proxies are mandatory. Create your proxies and start trying to be clever afterward.

 

The main mod's init method needs to exist on the server side. If you declare it to be client SideOnly, then you're going to crash. The mod validation code within Forge might not even allow your mod to load on the server (when it is truly separate from the client).

[Earthcomputer]

  On 4/30/2016 at 8:23 PM, jeffryfisher said:

The main mod's init method needs to exist on the server side. If you declare it to be client SideOnly, then you're going to crash. The mod validation code within Forge might not even allow your mod to load on the server (when it is truly separate from the client).

Actually this is not true. After running a simple test on a dedicated server:

@EventHandler
@SideOnly(Side.CLIENT)
public void init(FMLInitializationEvent e) {
    System.out.println("Init called");
}

The server ran fine and "Init called" was not printed into the console. I've used this technique a lot for very simple mods which I am using to figure out changes between updates, and I worry about "bad practice" after I get it to work. Anyway, here is not the place to argue

[jeffryfisher]

OK, I'll admit my recollection was vague, but I thought I'd seen loader code checking a supposed mod for the usual three handlers before deciding that it's a valid mod. Maybe it doesn't actually require all three all of the time, but I'd be asking for trouble if I left one out without walking that loader code again to be sure.

 

I'm glad your problem is solved.