Choonster

In future, please use a site like GitHub or BitBucket if you want to share your entire project. It makes it much easier to spot problems without having to download anything. It also makes it easier to share changes. Your code has several issues: In ModBlocks.init , you overwrite the ModBlocks field with a new instance of Block . You do the same thing for the ModItems field in ModItems.init . In ModBlocks.init , you're calling BlockModelShapes#registerBuiltInBlocks . This will stop your blockstates file from being loaded, which will break your block model. Your JSON files have the .JSON extension instead of .json. Paths in JARs are case-sensitive, so the case of the extension matters. You should move your code to a package that includes your name and the mod's name (e.g. somelx.somelxmod ) You should give your blocks and items proper names that aren't the same as your block/item registration classes. These names should be singular rather than plural (e.g. Thing , not Things ). Follow the naming scheme described here for your classes. .

You can't run deobfuscated mods in the obfuscated (normal) client. You need to build your mod using the build Gradle task ( gradlew build from the command line) so ForgeGradle reobfuscates it.

You posted the crash report instead of the FML log, but it will do. Your graphics card doesn't support Forge's loading screen, you need to disable it. This is described in the EAQ, search for "loading screen" on that page for the instructions.

coolAlias has a tutorial on event handlers here. Jabelar has one here.

Mods can only be configured in Minecraft (from the main menu or the in-game menu) if they provide a config GUI, which not all mods do. If a mod was configurable in-game prior to 1.8.8-11.14.4.1579, it must have created its own GUI independent of Forge's config GUI system.

Have you tried looking at the vanilla spawner? ( BlockMobSpawner , TileEntityMobSpawner , MobSpawnerBaseLogic )

compile means that it's a compile-time dependency, i.e. the classes are used in your code and need to exist at compile-time so the compiler knows about them. It doesn't actually compile the dependency.

runtime is for dependencies that you don't need to compile against. compile is for dependencies that you do need to compile against.

Why do you need sun.misc ? That's not part of the supported public interface.

Are you sure you're not thinking of the mods menu accessed from the main menu (i.e. before you load a world)? That should be functional in 1.7.10.

No, all of your dependencies should be handled through Gradle. Gradle will then add these to your IDE project. You can refresh the project from IDEA's Gradle window to update the project (including dependencies) from build.gradle.

You're trying to add project dependencies (things used by your mod) as buildscript dependencies (things used to build your mod).

Anything in the libs directory is automatically included as a dependency, you don't need to explicitly add it. Project dependencies (mods, libraries, etc.) go in the root dependencies block. Buildscript dependencies (like ForgeGradle) go in the buildscript.dependencies block. Maven and local dependencies don't affect each other at all. To add a dependency from Maven, add the Maven repository to repositories and add the dependency to dependencies . To add a local dependency, just add it to dependencies .

You can either add the mod as a dependency via Gradle (the MDK's build.gradle links these pages explaining how to do this) or add the source code of its API to your project (i.e. put it in src/api/java) and add the mod itself to your development environment's mods folder. Baubles is usually used the latter way.

That's the MCP mappings version used by 1.8.9 versions of Forge.

Are you registering ModItems with the name "moditems" ? If not, either change the model name to match the registry name of ModItems or call ModelBakery.addVariantName with "somelxmod:moditems" to load that model. The Grey Ghost has a guide to troubleshooting item rendering here, I suggest following it.

Minecraft only loads one model per Item by default: modid:itemRegistryName (where modid is your lowercase mod ID and itemRegistryName is the name you passed to GameRegistry.registerBlock / registerItem ). This resolves to either the assets/modid/models/item/itemRegistryName.json model or the model specified by the inventory variant of the assets/modid/blockstates/itemRegistryName.json blockstates file. To load one or more other models, you need to call ModelBakery.addVariantName with the names of the models in the same modid:name format as above. To specify which model to use for an Item , call ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition in preInit.

No, I haven't had any response.

Use bearded-octo-nemesis to deobfuscate a mod before decompiling it.

This menu was only made functional in 1.8.8-11.14.4.1579. I don't think it will be backported to 1.7.10.

PlayerEvent.PlayerLoggedInEvent is fired on the server side when a player logs in. You can send a chat message to an ICommandSender (which EntityPlayer implements) using ICommandSender#addChatMessage .

Not too sure what's going on there since I don't use Eclipse myself. Try running gradlew cleanEclipse eclipse to delete the project and then regenerate it.

You need to recreate your IDE project. If you're using Eclipse, re-run gradlew eclipse . If you're using IDEA, open build.gradle with it and re-import the project.

Block#getRenderType is completely unrelated to TESR , except that returning -1 from it prevents the standard baked model from rendering. You should be able to have a baked model and a TESR for the same block.

Did you try looking at the ServerData class or how it's used? You should be able to navigate to it and find usages of it using your IDE.