Choonster

If the problem has been solved, you should post the solution and edit your title.

The loader couldn't find cruxcraft:models/block/SmallDepost.obj , so it tried to load cruxcraft:models/item/SmallDepost.obj ; which also didn't exist.

The boolean argument of Item#onUpdate is whether the item is currently selected (held). If you update to 1.9 (which you should) and want it to work in the off hand as well, you'll need to check if the entity's off hand item is the ItemStack argument (like ItemMap does).

Then set the JAVA_HOME environment variable to point to it.

Look at BlockOre#quantityDroppedWithBonus to see how vanilla ores add the fortune bonus.

Your new code is doing exactly the same thing as your old code, you need to add the fortune bonus yourself.

Override Item#onItemUseFinish to call the super method and return the replacement item, like ItemSoup does. If the food stacks, add the replacement to the inventory instead of returning it from the method. In future, you should always specify which Minecraft version you're using in your thread title.

Override Block#quantityDropped(IBlockState, int, Random) instead of Block#quantityDropped(Random) , this gives you the fortune level. I would personally recommend having fields to store the dropped item and quantity rather than checking which instance this is, it makes your code more extendable. Side note: Always annotate override methods with @Override so you get a compiler error if they don't override a super method.

EnumHelper.addArmorMaterial is currently broken (see this issue), you need to use EnumHelper.addEnum manually. You can see how I do this here.

Which Minecraft version are you using? Always specify this in your thread title. In 1.9, ModelResourceLocation was moved to net.minecraft.client.renderer.block.model . Don't use unlocalised names for registry names or model locations. Registry names are IDs and must not change, unlocalised names can change at any time. If the registry and unlocalised names of an Item are the same, set the registry name and then set the unlocalised name to the full registry name. This will include your mod ID in the unlocalised name, which prevents conflicts with other mods. The default model loaded for every Item is the one with its registry name, so use this as the default model location for your Item s. Don't use ItemModelMesher#register , use ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition in preInit. I recommend creating a separate client-only class to handle your model registration to avoid mixing client-only code with common code. If you're using 1.9, don't use GameRegistry.registerItem / registerBlock , use GameRegistry.register . This registers any IForgeRegistryEntry implementation, including Item and Block . This doesn't create an ItemBlock for your Block , you need to do that yourself.

That's possible: Store the EnumWoodType in the TileEntity . Override Block#getActualState to retrieve the TileEntity at the specified position and set the value of the VARIANT property to the stored value. Override Block#getMetaFromState to return 0.

There's a reason vanilla only has up to four variants per log class: 4 types * 4 axes = 16 possible combinations. Metadata is limited to the range [0, 15], which allows up to 16 combinations to be saved. If you want more than four variants, create a separate class for each set of 1-4 variants like vanilla does. If you're using the same variants as vanilla wood, consider extending BlockOldLog / BlockNewLog and only overriding the necessary methods.

Don't implement IBlockColor / IItemColor on your Block s/ Item s, create a separate implementation and register it with BlockColors / ItemColors from your client proxy in init. You can see how I do this here.

Now that 1910 has been released, this seems to have been fixed.

I said nothing about syncing, I was only talking about reading from/writing to NBT. You need to handle syncing yourself.

That's not at all what I said. You tried to add a recipe with a null ingredient (input).

It looks like you called GameRegistry.addShapelessRecipe with a null ingredient.

I'm pretty sure the problem was that you didn't specify all of your variants, not that you had an empty defaults section.

That's the first alternative I suggested, it's more efficient than using FurnaceRecipes#getSmeltingResult . It's probably slightly less efficient than iterating through the entries rather than the keys (since it needs to look up the value of the key in the map), but not by a large amount. You're still using raw types: FurnaceRecipes#getSmeltingList() returns a Map<ItemStack, ItemStack> , not a Map .

The only errors I see for primevalforest:stone are MissingVariantException s, meaning there's no variant with that name in the blockstates file. I don't see any errors for primevalforest:stone#stone=andesite , does that variant's model work now?

Don't use raw types (e.g. Set ). FurnaceRecipes.instance().getSmeltingList().keySet() returns a generic type ( Set<ItemStack> ), so refer to it as that type. Iterating over the keys and using FurnaceRecipes#getSmeltingResult to get the smelting result is extremely inefficient since you're now iterating through the smelting list again for every entry. Either look up the ItemStack key directly in the Map or iterate over the entries so you have direct access to the key and value.

You probably need to add it the VM options section rather than Program arguments.

I can't see any errors for primevalforest:stone in that log, but there were 12 suppressed errors that weren't logged. The number of errors logged per domain is controlled by the forge.verboseMissingModelLoggingCount system property, the default value is 5. Could you set this to a higher value by adding the -Dforge.verboseMissingModelLoggingCount=[b]N[/b] command-line argument to your run configuration and post the new log?

FurnaceRecipes#getSmeltingList returns a Map<ItemStack, ItemStack> , i.e. a Map with ItemStack keys and ItemStack values. Calling Map#get on this with an int will always return null because it doesn't have int keys. You can't iterate over a Map directly, you must iterate through either its entry set, key set or values collection (obtained by calling the corresponding Map methods). All of these return an object that implements Iterable , so you can either iterate through them with an enhanced for/for-each loop or by using the Iterator . When iterating a collection with an enhanced for loop, you can't modify the collection at all. When iterating with an Iterator , you can remove the current value by calling Iterator#remove but you can't add new values. This is basic Java knowledge that you should already have before making a mod.

Your blockstates file was loaded by the vanilla blockstates loader rather than the Forge one, which threw an exception because your file isn't a valid vanilla blockstates file. Forge only uses the vanilla loader when the file doesn't have the "forge_marker" field set to 1. Are you sure assets/primevalforest/blockstates/stone.json has this field?