Choonster

Try run the setupDecompWorkspace task again and refresh the project (both from IDEA's Gradle window).

LatCoreMC's player data file (latmod/LMPlayers.dat in your save) contains an invalid UUID string. If you care about this data, either restore it from a backup or open it in an NBT editor (e.g. NBTExplorer), find the UUID string mentioned in the crash report and edit it to the correct format (i.e. add dashes so it matches xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ). If you don't care about this data, just delete the file.

Block.getBlockById returns the Block with the specified numeric ID and Block#getStateFromMeta returns the IBlockState for the specified metadata. Block.getStateById takes a state ID and uses the other two methods to return the corresponding IBlockState . Keep in mind that numeric IDs for Block s and Item s are per-world, so a Block / Item won't have the same ID in every world. You should really avoid using numeric IDs/metadata where possible.

You've installed a client-only coremod on the server.

Coremods don't apply a traditional .patch file to the Minecraft source code, they modify the bytecode at runtime using ASM. You should only need to know a couple of SRG names at a time, you don't need the whole codebase in SRG names. You can use a decompiler like Bytecode Viewer to decompile bytecode into Java.

Render layers were added in 1.8. In 1.7.10 and earlier, armour rendering (including colours) is handled directly in the appropriate Render class ( RenderBiped for biped mobs, RenderPlayer for players). Those are the right methods, though only getColor is used for rendering. hasColor is only used for armour dyeing recipes.

Why? There should be a JAR in your Gradle cache that contains the Minecraft and Forge classes with SRG names. For recent versions of Forge, this can be found at ~/.gradle/caches/minecraft/net/minecraftforge/forge/<forge_version>/<mappings_channel>/<mappings_version>/forge-<forge_version>-srgBin.jar (replace ~ with %USERPROFILE% on Windows).

The point of the @Instance annotation is that FML populates the field with the instance it's created. An instance created in the field's initialiser won't work for anything because it won't be the instance that FML knows about.

This is only for one specific type of client/server syncing. The Simple Network Wrapper can be used to send arbitrary data between the server and client at any time, e.g. to tell the server that the player pressed a key so it can take some action.

If you set up your ForgeGradle workspace with setupDecompWorkspace (not setupDevWorkspace ) and then generate your IDE project, the forgeSrc library will have the deobfuscated Minecraft/Forge source code attached to it. This means you can view the source code of each class in your IDE. Just to clarify, there are three types of names: Notch - Fully obfuscated names like aa / ij . These used in the standard Minecraft JAR. SRG/Searge - Auto-generated, semi-obfuscated names like field_0035_a / func_0001_b . Forge deobfuscates the standard Minecraft JAR at runtime to use these names. MCP - Deobfuscated names like thingList / getThingList . These are only used in the development environment, ForgeGradle reobfuscates your code to use SRG names when you build it. The MCP mapping CSVs map from SRG to MCP names. Notch names change with every version of Minecraft. SRG names are fairly stable, they will usually remain the same across multiple versions of Minecraft. MCP names can change with each mapping version.

What Ernio said is correct and will cause a crash if not fixed, but it's not the cause of this crash in particular. The object you passed to EntityPlayer#openGui doesn't have an IGuiHandler registered for it. This means you either didn't register your mod's IGuiHandler correctly or you're not passing the instance of your @Mod class to EntityPlayer#openGui .

You can get the SRG name of a method/field from the MCP mapping CSVs. If you've set up a ForgeGradle workspace for 1.8+, you can find the MCP mappings used by it in the Gradle cache (~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_channel>/<mappings_version>, replace ~ with %USERPROFILE% on Windows). You can also download MCP mappings from the MCPBot website.

No, it's returning the ID of the vanilla state.

I have stepped through it in the debugger a couple of times. It seems the substitution is being activated, but the GameData.BLOCKSTATE_TO_ID map used by ExtendedBlockStorage is never updated with the blockstates of the replacement block.

I wasn't sure if it was a bug or I was just doing something wrong, so I was hoping to find someone who managed to get the system working. I may report it as a bug, since nobody seems to be able to get it working.

I don't believe there is. The easiest way to track this will probably be using IExtendedEntityProperties .

If you just added PlayerAPI as a library in your IDE, Gralde doesn't know anything about it. Create a directory called libs next to build.gradle and put the PlayerAPI JAR in it. Once you refresh your IDE project (from the Gradle window in IDEA or by re-running gradlew eclipse for Eclipse), Gradle should pick up PlayerAPI as a dependency and add it to your IDE project.

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.