Choonster

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.

I don't think you can use 1.9 clients on 1.9.2 servers. Attempting to connect to an actual vanilla 1.9.2 server (without Spigot) from a Forge or vanilla 1.9 client just tells me that my client is outdated.

It's a class. Look at it in your IDE. Custom menus won't affect it, the raw data will always be made available by Minecraft.

That's the class I'm talking about, yes. You're trying to return an existing instance instead of creating a new one (error 1) and returning null because you never assign a value to the field (error 2).

Your IRenderFactory#createRenderFor implementation must create a new instance of the appropriate Render class (e.g. RenderBeeHive ) using the supplied RenderManager . You cannot create the Render instance outside of that method and return it. Your RenderFactory#createRenderFor method is currently returning null because you never assign a value to the RenderBeeHive.instance field. Do not use EntityRegistry.registerGlobalEntityID (there's a reason it's deprecated) or manually manipulate EntityList.entityEggs . All you need to register an entity is EntityRegistry.registerModEntity . If you need a spawn egg, use the overload with the two additional int arguments (the egg colours).

You're running Forge 1.7.10-10.13.4.1448 and trying to load Forge 1.7.10-10.13.4.1614 as a coremod, I'm somewhat surprised that it works at all. You need to tell your launcher to run the newer version of Forge instead of putting Forge in your mods folder. I'm not familiar with the FTB launcher, so I'm not sure how that's done.

Are you sure the FTB launcher loads Forge from the mods folder? Upload your FML log (the file mentioned in the error message) to Gist and link it here.

The ModelVillager class is Minecraft's villager model.

Baked models (which can be JSON, OBJ or B3D) are the essentially equivalent of ISBRH in 1.9, yes. Their lack of OpenGL access allows them to be rendered quickly. If you need OpenGL access, use a TESR .

These are mostly classes that have been renamed in recent versions. You can search the issues of this repository for the old class name to find out what it was renamed to. This will work for most classes that were renamed in 1.9, but may not work for earlier versions. AxisAlignedBB#fromBounds was removed when the class's constructor was made public. Use the constructor instead of fromBounds . Vanilla removed the WorldProvider#dimensionId field and its getter method in 1.9 and replaced them with the DimensionType enum and the WorldProvider#getDimensionType method. Forge re-adds the WorldProvider#dimensionId field, but the getter is now called getDimension instead of getDimensionId . WorldRenderer was renamed to VertexBuffer , so Tessellator#getWorldRenderer was renamed to Tessellator#getBuffer . MCPBot tells me that the SRG name of StructureStart#getComponents in 1.9 is func_186161_c and it was given the name getComponents two days after Forge's default 1.9 MCP mappings were generated. Either use the SRG name or update your mappings. MinecraftServer.getServer is no longer a static method. There are several methods that you can use to get the MinecraftServer instance now, use IDEA's Find Usages (or Eclipse's equivalent) feature to search for methods with return type MinecraftServer . In particular, you can use World#getMinecraftServer on a server-side World or FMLCommonHandler#getMinecraftServerInstance (prefer using the World method when possible). ServerConfigurationManager was renamed to PlayerList , so MinecraftServer#getConfigurationManager was renamed to MinecraftServer#getPlayerList . The PlayerList#playerEntityList field is now private, use the PlayerList#getPlayerList method to get it.

Then I'm not too sure what's going on, sorry.