Choonster

ModelLoader.setCustomModelResourceLocation only affects item models (including but not limited to the Item forms of Block s). It has nothing to do with the in-world model for blocks. The ModelResourceLocation passed to ModelLoader.setCustomModelResourceLocation can point to a regular item model (the first priority) or to a variant of a blockstates file (only used if the item model doesn't exist). The ModelResourceLocation <modid>:<name>#<variant> can either point to assets/<modid>/models/item/<name> (an item model in JSON, OBJ or B3D format) or the <variant> variant of assets/<modid>/blockstates/<name>.json (a blockstates file). For an item model, the variant should be inventory . If you want to load an item model other than the default (the one with the item's registry name), call ModelBakery.registerItemVariants . To load an OBJ model directly, include the .obj extension in the ResourceLocation / ModelResourceLocation 's resource path. To load a model specified by a blockstates file, don't include the extension. Minecraft used the name blockstates because it was only designed for blocks, but Forge adds the ability to use it for items as well. Edit: Added a missing closing tag.

World#setBlockState sets the block state at the specified position in the world.

I suggest you use the existing ModelRender fields of ModelBiped where possible so that ModelBiped 's methods can set the rotation angles and element visibility for you. Even if you override every method of ModelBiped , some parts of the code directly access and modify its fields rather than calling methods to do so. You'll still need to override most of ModelBiped 's methods to apply to your custom elements.

Blocks.grass uses a standard ItemBlock that will be returned from Item.getItemFromBlock .

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.