Choonster

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 .

Item implements IForgeRegistryEntry , as do most other singleton classes stored in registries (e.g. Block , BiomeGenBase , Enchantment ). Instead of specifying the registry name in the GameRegistry.registerItem call, set the registry name using IForgeRegistryEntry#setRegistryName (or one of the overloads provided by the Impl subclass) and then register it using the single-argument overload of GameRegistry.register . Don't use unlocalised names to determine the registry names, the whole point of the original implementation of the registry name methods in 1.8.9 was to stop people doing that. You can see how I register items in my mod here. Most of my items use ItemTestMod3.setItemName to set their registry and unlocalised names, but some have completely separate names (e.g. records) that they set manually. Don't use unlocalised names for model locations, the default model loaded for an Item is specified by its registry name. Don't use ItemModelMesher#register to register models, use ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition in preInit. I would advise against registering client-only things like models in the same class as you register common things like Item s. I recommend creating a separate class to handle model registration, like this one.

This tutorial explains how to set up a ForgeGradle workspace, including how to give Gradle more memory.

This has been reported here.

[nobbc]This is an example[/nobbc]