Choonster

Forge is missing a required library (log4j). Try re-running the installer for the Forge version you want to use.

That's the forge profile, but you don't have a Forge version selected in the "Use Version" dropdown (like diesieben07 said before).

I think diesieben07 meant "show a screenshot of the profile editor with a forge version selected". The screenshot you've posted shows that you're launching vanilla Minecraft. In future, you can use an image hosting site like Imgur to post screenshots.

If your mod requires another mod that embeds the RF API (e.g. CoFHCore, BuildCraft) or RF is an optional feature (i.e. you use @Optional.Interface to strip the interfaces when they're not present), you can put the API's source code in src/api/java (so you have src/api/java/cofh/api/CoFHAPIProps.java). This will compile your mod against these classes without including them in your mod's JAR. If your mod is standalone, put the API in src/main/java instead. This will include the classes in your mod's JAR.

Remove LatCoreMC and keep FTB Utilities, since the latter is the replacement of the former.

I looked at the code again and this error is definitely being thrown while reading data from <save_dir>/latmod/LMPlayers.dat. Are you absolutely sure that the file doesn't exist? Side note: LatCoreMC appears to be have been replaced by FTB Utilities. You may want to consider updating.

Post the full crash report, including the LatCoreMC version. It looks like older versions of LatCoreMC save the data in LatCoreMC.dat instead of latmod/LMPlayers.dat.

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. .