Choonster

Look for the part that starts with java.lang.IndexOutOfBoundsException (the first line of your crash report).

See these threads about shading: http://www.minecraftforge.net/forum/index.php/topic,37243.0.html http://www.minecraftforge.net/forum/index.php/topic,37742.0.html

Those were the problem mods in benten2000's install. In your install, only Extra Utilities 2 has failed to register its recipe class.

You tried to load a mod built for 1.7.10 while running 1.9.4. Mods only work in the version of Minecraft they were built for. If you post the FML log (logs/fml-client-latest.log), we can probably tell you which mod this is. You could also just look look at your installed mods yourself, mods usually have the Minecraft version they were built for in their file name.

What else could go in there besides null? My model is based off of modelbase, but using return new RenderOompah(manager, ModelBase.class, 0); returns "The constructor RenderOompah(RenderManager, Class<ModelBase>, int) is undefined" Pass an instance of ModelBase or a class that extends it (like ModelOompah ). Don't pass the class itself.

Are you sure the method is actually being called? Set a breakpoint and run Minecraft in debug mode. EntityRegistry.registerModEntity needs to be called on both sides, so don't put it in your client proxy. Passing null as the ModelBase argument of the RenderOompah constructor will almost certainly cause issues, RenderLivingBase doesn't expect the model to be null .

Since I see you mention this again, I have to say this: If you don't own "xyz.com", do not use "com.xyz" as your package name. Package names are tied to domain names. Many people use "me.<name>", but I would prefer "mod.<modID>", since "mod" is not a real TLD. That's a good point. I should probably repackage my code at some point.

There is no list, it's mainly just the one convention (prefix your class names with the super type). For examples, simply look at the vanilla class names; these are all assigned by MCP. This section of Forge's official documentation briefly outlines the recommended way to structure your mod, including how to name your classes.

Call EntityRegistry#registerModEntity in preInit to register your entity. Use the overload with the two additional int arguments to add a spawn egg for the entity. Call RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit from your client proxy to register your entity's renderer. I suggest using an anonymous class (Java 6/7) or lambda/method reference (Java to implement IRenderFactory . Edit: Removed smiley.

onPlayerStoppedUsing is a void method. It doesn't return anything. In the code you posted, you're referencing a player variable. Where is this coming from? You should use the EntityLivingBase argument. Only create and spawn entities on the server (when World#isRemote is false ). In future, always post the error message (if it's a compile-time error) or the FML log (if it's a runtime error). This makes it much easier to help you.

Override the method by creating a method with the same name, return type and parameter types and annotating it with @Override . Your IDE should be able to do this for you. It's not strictly necessary, but you should also annotate your override method with the same annotations as the super method. If you've managed to override the method, post your latest code and describe what the current problem is.

diesieben07 answered before I could (and noticed that you were handling the wrong event), but here are some other things that I noticed: Entity isn't a singleton class like Block , Item or Potion ; don't store an instance of it (or a subclass) in a static field. Don't bother having a PreInitializationEvent parameter in Common#preInit if you're just going to pass null . Either pass a real value or remove the parameter. Your package name should include your name and your mod name (e.g. com.<yourname>.<modname> ). Don't use src in the package name. You should follow Java naming conventions: PascalCase for class, interface and enum names; camelCase for field, method, parameter and local variable names and UPPER_CASE for constants. You should also follow MCP naming conventions by prefixing your class names with the supertype, e.g. ItemMormonBook rather than MormonBookItem . Your proxy classes should have "proxy" somewhere in the class or package name.

If you want to change the texture used to render an entity, override Render#getEntityTexture . That's not what you want to do here though. RenderSnowball already handles the model and texture for you, you just need to pass it the right Item in the constructor (and override RenderSnowball#getStackToRender if you want to use custom metadata/NBT/capabilities). If an entity is rendering as a white box, it hasn't had a Render registered for it. You must do this by calling RenderingRegistry#registerEntityRenderingHandler(Class<T>, IRenderFactory<? super T>) in preInit. The ModelResourceLocation passed to ItemModelMesher#register or ModelLoader.setCustomModelResourceLocation points to a model (the clue is in the name). Render#bindTexture expects the ResourceLocation to point to a texture. Textures and models are not the same thing.

Erebus has been configured to use biome ID 100, but that's already been taken by the Kelp Forest biome from Biomes O' Plenty.

The Magic Touch enchantment from Thaumic Bases and the Magic Resist enchantment from Ars Magica 2 are both configured to use ID 100. Set a new ID for one of them in the appropriate config file.

I don't think I had much luck with the web client, I ended up downloading HexChat to use MCPBot.

Resource Loader is a client-only mod, it doesn't work on the dedicated server.

ModelLoader.setCustomModelResourceLocation tells Minecraft to load that model (with ModelBakery.registerItemVariants ) and use it for that metadata value of the Item . If it's not working, post the FML log. ModelResourceLocation automatically converts its variant to lowercase, so I'd recommend specifying it in lowercase in the first place.

You have two versions of Baubles installed, one for 1.7.10 and one for 1.9.4. Remove the 1.9.4 version.

ASM is a library for manipulating Java bytecode. Minecraft and Forge use it, but mods should avoid using it where possible.

Ah, I didn't notice that you were using 1.8.9. I'd recommend updating to 1.9.4.

The FML log is saved to logs/fml-client-latest.log in the game directory. Things you need to fix: RenderingRegistry.registerEntityRenderingHandler must be called in preInit. Block s, Item s and other IForgeRegistryEntry implementations should be registered in preInit. The same goes for entities. Item models should be registered in preInit from your client proxy (not your @Mod class, you'll crash the dedicated server) with ModelLoader.setCustomModelResourceLocation / setCustomMeshDefinition rather than in init with ItemModelMesher#register . GameRegistry.registerItem and GameRegistry.findItem are deprecated, look at their doc comments for the replacements. Event handler registration can be done in any phase, so that can stay where it is. I did notice the MormonBook item.

You could iterate through the block's valid states ( BlockStateContainer#getValidStates ) and use Block#getMetaFromState to get the metadata corresponding to each one.

Let me be a bit more specific: Post the class where you call EntityRegistry.registerModEntity , the class where you call RenderingRegistry.registerEntityRenderingHandler , the class that calls those classes and your Render class. Also post your FML log.

Keep the field declaration in the main body of the class, only move the initialisation to the method. You must have a solid understanding of Java and OO programming in general before you can make a mod.