Choonster

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]

Forge's ChestGenHooks system was removed in 1.9. It turns out that you can use the loot table system even though Forge hasn't added any hooks for it. See this commit. You can use TileEntityChest#setLoot to set the ID of the LootTable that will be used to generate the chest contents.

Forge hasn't yet added support for custom loot tables, see this PR.

Minecraft doesn't have any mapping between these blocks and their custom items, as far as its concerned they're completely unrelated. It only maintains a mapping for blocks that use a standard ItemBlock . There are two ways you can create this mapping: Hardcode the vanilla block-placing Item s (that don't extend ItemBlock ) and their corresponding Block Iterate through the item registry, find any instances of ItemBlockSpecial / ItemReed and extract their Block The first way will obviously only work for vanilla blocks. The second way will work for any vanilla and modded blocks that use ItemBlockSpecial , but not ones that use their own unrelated Item class (e.g. Items.sign , which is an instance of ItemSign ). This mapping may not be 1:1, it's possible for there to be several Item s that place the same Block or for a single Item to place multiple Block s (e.g. ItemSign can place Blocks.standing_sign or Blocks.wall_sign ).

This is the case. Cake and a few other blocks have separate Item forms that aren't regular ItemBlock s. Items.cake stores the Item form of Cake. Look for usages of ItemBlockSpecial (1.9) or ItemReed (1.8.9 and earlier) to see which blocks have separate Item forms.

Forge's ore recipes all store the List<ItemStack> for the given ore name as returned by OreDictionary.getOres , this list will be updated by the Ore Dictionary if any additional items are registered for this name. Ore Dictionary entries are often registered in the same phase as recipes are added (init), so it's entirely possible that more items will be registered for a name after you add a recipe using it.

Forge's test/example mods can be found in the src/test directory of the GitHub repository.

Update Neat to 1.2-5.