Choonster

Use World#getBlockState to get the current block state at the specified position, then use IBlockState#getValue to get the value of each property. Some blocks have properties that aren't stored in the metadata (e.g. connection state of panes), you can use Block#getExtendedState to get an IBlockState with the actual values of these properties.

You should pass the actual state ( World#getBlockState ) rather than the default state ( Block#getDefaultState ) to harvestBlock . At the time of removedByPlayer being called, the Block is still in the world.

You can also download exports of the mappings from the MCPBot site. Alternatively, you can view the mappings used by your ForgeGradle workspaces in the ~/.gradle/caches/minecraft/de/oceanlabs/mcp/<channel>/<version> directory (replace ~ with %USERPROFILE% on Windows).

Override the BiomeGenBase#getGrassColorAtPos method that Failender mentioned.

Not unless you create your own wire, vanilla redstone can only store power levels 0-15.

Try overriding Block#removedByPlayer to call Block#harvestBlock if the player that destroyed the block is in creative mode.

Simply returning true from Block#onBlockActivated should prevent the Eye of Ender from spawning. I just wrote this simple example and it works without issue.

Gradle skips a task if it has previously completed it and the result is still valid. Your log doesn't have any errors in it, have you tried running gradlew eclipse or gradlew idea to generate an IDE project?

Re-run gradlew setupDecompWorkspace eclipse .

Okay, I thought I could use the vanilla spawn egg; but I'll implement my own egg and manually increment the stats.

The Fluid constructor takes a ResourceLocation each for the still and flowing icons. To change the colour of the fluid, you'll need to extend Fluid and override Fluid#getColor . You'll need to register the forge fluid model for your BlockFluid . You can see an example of this here and here.

You're calling ItemStack#getItem before checking if the ItemStack (returned from player.getCurrentEquippedItem() ) is null . When it's null , you'll get a NullPointerException because you tried to call a method of a null value. getHeldItem and getCurrentEquippedItem do the exact same thing, you should really only use one. Don't use System.out.println for output that the player is supposed to see in-game. Use EntityPlayer#addChatComponentMessage to send a chat message to a player (make sure you only do it on the client or server, not both). For general logging output, use FMLLog or a wrapper around it.

For the stats to be incremented, the class to ID mapping is needed. For the egg to work, the ID to class mapping is needed. For the /summon command's auto-complete to work (not a big priority), the string (name) to ID mapping is needed (though the IDs are never actually used). Should I let FML create the class <-> name mappings with EntityRegistry.addModEntity and then manually add the three ID mappings and the egg?

Is the basic premise of what I'm doing (using IDs >= 256 with vanilla spawn eggs) correct? Is there a specific part of my code you think is unnecessary? EntityRegistry.registerGlobalEntityID will log an ERROR message when the ID isn't an unsigned byte, though it will still add the mapping and the egg with EntityList.addMapping . My code calls the same method.

This is only for a test mod which I don't plan to update to 1.8, I have a separate test mod for each version. I ended up going with a slightly different solution, but your reference to invalid IDs pointed me in the right direction. Thanks. The solution I ended up with was using IDs in the range [256, Short.MAX_VALUE ] and calling EntityList.addMapping instead of EntityRegistry.registerGlobalEntityID to add the spawn egg. You can see the code here. In the process of testing this, I realised that Biomes O' Plenty was already using IDs >= 300 for its own entities; so I found its implementation here. This is simpler than mine, but it doesn't add the class to ID mapping so kill statistics don't work.

Following the comments from diesieben07 in this thread, I thought I'd try and implement my own spawn egg that didn't use global IDs. I quickly ran into an issue: the entity kill statistics rely on EntityList.EntityEggInfo , which is tied to the global ID list. I can create my own stats for each of my entities and increment them myself; but they won't show up in the vanilla statistics GUI (the mobs section of which also relies on global IDs). Is there any way to have kill statistics that display in the vanilla GUI without global IDs?

You need to call setHasSubtypes(true) on your Item , otherwise the metadata will be ignored when the player picks it up.

Don't you still need a global ID if you want an egg for the entity? Recent versions of Forge for 1.8 removed this requirement, but I don't think it was backported to 1.7.10.

Your initial code didn't work because you never change the values in the TileEntity 's dir array once it's detected a connecting pipe on each side at least once (so it still thinks it's connected to a neighbouring pipe when you remove the pipe next to it); and even if you did, you ignore the values in the array when rendering it. I'm not sure why you were storing an int array in the first place, wouldn't a boolean array make more sense?

You need to send an IMC message to "ThermalExpansion" by calling FMLInterModComms.sendMessage before the postInit phase or FMLInterModComms.sendRuntimeMessage during the postInit phase. The reason you can use both methods is because TE subscribes to IMCEvent (fired between init and postInit) and also explicitly checks for runtime IMC messages when FMLLoadCompleteEvent fires (after postInit). Some mods only subscribe to IMCEvent , so they won't process runtime messages. As far as I can tell there's no formal documentation of TE's expected IMC format, but you can download a recent dev version and view the IMCHandler class in a decompiler to see how it handles each message. You'll need to use ItemStack#writeToNBT and FluidStack#writeToNBT to write the inputs and outputs to the NBT message you send to TE. Edit: I forgot some words.

MineMaarten has tutorials on multiblock structures and . This is a fairly advanced topic, so you'll need have a good understanding of Java and Minecraft/Forge to understand it completely.

Look at RenderFallingBlock to see how it's done for anvils, gravel and sand.

DamageSource is simply the base class. EntityDamageSource and EntityDamageSourceIndirect are used for damage caused by entities and correctly override DamageSource#getEntity and DamageSource#getSourceOfDamage .

IBlockState s are immutable. IBlockState#withProperty returns a different IBlockState instance with the property set to the specified value rather than modifying the existing instance. If you want to change the state of a block in the world, you have to use World#setBlockState . Simply calling IBlockState#withProperty and not doing anything with the result does nothing. Your code will correctly preserve any properties except the ones you change, though.

If it's your own Item class, use the ItemStack argument of getMaxDamage to determine the max damage (e.g. store the Blacksmith level in the NBT when crafted, read it back in getMaxDamage ).