Choonster

Override Item#getArmorModel to return the armour's ModelBiped instance.

To use a mod with the obfuscated (non-development) client/server, it has to be reobfuscated first. Do this by running the build Gradle task.

Instead of a separate method to register each type of object, there's now a pair of GameRegistry.register methods that register any IForgeRegistryEntry . This includes Block s, Item s and SoundEvent s. The single-argument overload expects the object to already have its registry name set with IForgeRegistryEntry#setRegistryName . The two-argument overload takes a registry name as an argument. Make sure you're using Forge 1.9-12.16.0.1819-1.9 or newer, this is the version that added the new registry system.

Minecraft only loads one model per item by default: the one with the item's registry name. To load additional models, call ModelBakery#registerItemVariants client side in preInit.

Use a separate class to implement ItemMeshDefinition , an anonymous one will be fine if the logic isn't too complex. ModelLoader , ItemMeshDefinition and ModelResourceLocation are all client-only classes; you can only use them in your client proxy (or a class called from it).

Good to hear. I'm glad you got it working.

Did you try searching?

Chisel is the only mod I know of that uses CTMLib (since it was created by Chisel Team for Chisel). Try looking at how CTMLib is used there.

Just to confirm: Your items are all working now?

Implement ItemMeshDefinition and register it using ModelLoader.setCustomMeshDefinition in preInit. This allows you to map an ItemStack to a ModelResourceLocation based on any criteria you want.

Don't use unlocalised names for registry names. The whole point of the registry name methods being added in 1.8.9 was to stop people from doing that. Set your registry names in your Item constructors. If the Item class is used by multiple instances, take the registry name as a constructor argument. If the Item class in only used by one instance, you can hardcode the registry name in the constructor. If your registry and unlocalised names are the same, I recommend setting the registry name ( setRegistryName("myItem") ) and then setting the unlocalised name to the full registry name ( setUnlocalizedName(getRegistryName()) ). This will result in your item's full unlocalised name being item.modid:myItem.name , which includes your mod ID to avoid conflicts with other mods.

This was fixed in Forge 1.9-12.16.0.1803-1.9. Update to the latest version of Forge.

BiomeProvider#findBiomePosition will try to find the position of one of the specified biomes in a fixed range around the starting coordinates and return null if none was found. Note that this uses the biomes that would currently generate at each position rather than the biomes that have already generated at each position. This is an important distinction if the world was generated with a different set of biomes to those currently registered. To check for biomes that have already generated, use World#getBiomeGenForCoords. BlockPos.getAllInBoxMutable can be used to create an Iterable<BlockPos> that iterates through every BlockPos between two positions.

WorldChunkManager was renamed to BiomeProvider in 1.9. BiomeProvider#allowedBiomes doesn't control which biomes generate, it only controls which biomes can be used as the world spawn point. To allow a biome to generate, call BiomeManager.addBiome . To allow a biome to used as the world spawn point, call BiomeManager.addSpawnBiome .

The errors in your fluid.retaw blockstates file are suppressing the errors in your other blockstates files. You can fix the fluid blockstates error by registering a custom IStateMapper like I do for my fluids.

items is a Set<Item> , you can't cast it to IForgeRegistryEntry.Impl<Item> since they're completely unrelated types. Item extends IForgeRegistryEntry.Impl<Item> , so call setRegistryName on the Item instances. I recommend doing this in the constructor of your Item classes.

You already posted your blockstates file, I need to see the FML log to help you.

Like coolAlias said, we need to see the crash report. The exception message should explain what you did wrong.

What isn't working with regards to your blockstates? Is your model not being used? Are your textures not showing up? Are you getting errors in the log? Upload your FML log to Gist and link it here. Minecraft uses its own separate rendering system for liquids that can't be used by mods. Forge adds the fluid system and a fluid baked model that can be used by the regular block rendering system. You can see how I register my mod's fluids here, how I register the models for my fluids here and the blockstates file for my fluids here. I explain how the model registration works here. This has changed a bit in 1.9, so see the 1.9 branch of my repository for the 1.9 code.

In general, you should only use event handlers when dealing with things from vanilla/other mods. For your own items, override the appropriate Item methods to perform whatever action is needed. Item#itemInteractionForEntity is called when a player right clicks on an entity with your Item .

Your repository should have your buildscript (build.gradle) and the Gradle wrapper (the gradlew scripts and the gradle directory) in it. Once you've cloned the repository, run the setupDecompWorkspace task and import build.gradle into IDEA. This tutorial explains how to set up a ForgeGradle workspace and IDE project for your mod. Instead of downloading the MDK and moving it to a new directory, use your existing repository.

It seems that Java bytecode explicitly stores the return type of the method, so it's looking for a method that returns ClassLoader rather than URLClassLoader (even though one is a subclass of the other). Recompiling against 1.8.8 without any changes to the code should work, but using code compiled against 1.8 won't (at least in this specific case). Side note: Why are you using the ClassLoader ? It looks like you're reinventing the @SidedProxy system.

That's something I wasn't doing, and never did on my 1.7.10 Mods. Thanks I'm gonna give that a try and see how it does now. SoundEvent s and Forge's new registry system were only added in 1.9. Earlier versions simply used strings for sound IDs.

For most Block s, Item.getItemFromBlock and Block.getBlockFromItem will convert between the Block and its ItemBlock . Some Block s have a separate Item form, but there's no 100% reliable way to convert between these. You can hardcode the vanilla instances and/or check for the vanilla classes, but you can't cover mods that use their own Item class. Some Block s don't have any Item form. Some Item s (in fact most of them) don't place a Block at all.

SoundEvent s are singletons and need to be registered in preInit using GameRegister.register , just like Block s, Item s and any other implementation of IForgeRegistryEntry .