Choonster

FluidStack has an NBT compound tag like ItemStack does. Most Fluid getter methods supply a FluidStack parameter, which you can use to determine the returned value. Fluid s only exist as FluidStack s when in a tank or container (e.g. buckets) of some sort; when they're in the world as a Block , only the Fluid is known (so you don't have anywhere to store NBT data unless you make a TileEntity for the Block ).

World#getBlock(int,int,int) was replaced by World#getBlockState(BlockPos) in 1.8, which returns an IBlockState . IBlockState#getBlock will return the Block of the IBlockState . You can use Entity#getPosition to get an Entity 's position as a BlockPos and BlockPos#down(int) to subtract an amount from the y coordinate.

It's hard to help you without seeing your latest code and the error. Post them on Gist or Pastebin and link them here.

Ah, I didn't get that from your last post. If it's rendering with colour in the world but grey in your inventory, you need to create a custom ItemBlock class that overrides Item#getColorFromItemStack like ItemColored does. You'll want to extend ItemSlab (to inherit the slab placement logic) and have a constructor that takes your actual single/double slab classes for the singleSlab and doubleSlab parameters instead of BlockSlab (so FML can find the constructor via reflection when you register your Block s).

Post your new model(s).

Like the error says, a model can only specify a parent or elements; but not both. Since you need to specify the tintindex in the elements, you need to define the elements yourself instead of inheriting from the default slab models. You'll need to copy the grass.json model, adjust the height (the y dimension of the from and to coordinates) of each element to 8 instead of 16 and remove the cullface from the up or down face (like the slab models). You can then inherit from this model for each variant of grass you want to support like the default grass models.

Blocks are only rendered with a colour multiplier if the model defines a tint index for the face. Look at the grass.json and grass_normal.json models.

The field with the @Instance annotation needs to be the same type as your main mod class (the one with the @Mod annotation), since it holds the instance of that class. Why are you doing this in ClientProxy ? Entities need to be registered on both sides. There's no reason to use global entity IDs ( EntityRegistry.registerGlobalEntityID ) or manually add spawn eggs in 1.8, if you need a spawn egg just call the EntityRegistry.registerModEntity overload with the two extra int parameters (the background and foreground colours of the egg).

Add acceptableRemoteVersions = "*" to your @Mod annotation, like this.

That's the actual grass texture, but BlockGrass overrides getBlockColor , getRenderColor and colorMultiplier to colour it depending on the position in the world. You should override these methods in MimicBlock to call the corresponding methods of the mimicked Block .

The original code had FMLPreInitializationEvent as the parameter for all three methods instead of each method having the appropriate event parameter.

Block IDs were phased out in 1.7, so the method was replaced by World#getBlock . This was then replaced by World#getBlockState in 1.8.

Because that doesn't exist maybe? Removing from the Iterator changes the underlying List, so this should work just fine. I'm talking about the removeRecipe method in the code the OP posted, not the vanilla CraftingManager class.

It doesn't look like you're calling craftingmanager.removeRecipe anywhere.

It looks like you've tried to add your grenade as a naturally spawning entity with EntityRegistry.addSpawn (like a mob or animal), but this doesn't work because it doesn't extend EntityLiving . You shouldn't have added it as a naturally spawning entity in the first place.

Yes, that will work. The doc comment of the @Mod annotation does show a brief example using required-after, but doesn't specify the exact format of the dependencies string (the field's doc comment references ModLoader's "priorities" string, so it probably hasn't been updated in a few years).

In the dependencies field of your @Mod annotation, you can list dependencies as before / after (optional dependency) or required-before / required-after (required dependency).

Only spawn the grenade entity and play the sound if you successfully consumed the reagent (in the if (player.inventory.consumeItem(...)) block). Item#setMaxStackSize should only be called once (in the constructor or wherever you instantiate the class). There's no reason to call it every time the item is right clicked.

Do you need to handle the cooldown in that manner? One alternative would be to store its last use time ( World#getTotalWorldTime ) in the NBT and just compare that to the current time when the player tries to use it. I do something like this here. If you have to handle the cooldown like this, override Item#shouldCauseReequipAnimation to ignore the NBT of the stacks.

That is the correct way to get the client player, but you probably shouldn't be changing this on the client side unless it's a client-only mechanic. If other players need to know about the change, you should send a packet to the server to tell it that the key was pressed and then handle the change there. You shouldn't be using block or item IDs at all unless you have a very good reason to (which is almost never the case). To get the Block form of an Item , use Block.getBlockFromItem .

1.8 is slightly different, but it's still possible to do. Look at the WorldGenMinable(IBlockState, int, Predicate) constructor and how it's called by the two-argument constructor.

For reference, I'm also trying to help the OP in their thread on Minecraft Forum.

Yes, you can have as many states as you want; it's just that you can only store 16 possible states in the metadata. Beyond that you have to use a TileEntity and one of the two methods I mentioned. Most Forge and vanilla code uses Block#getActualState , Block#getExtendedState is only used for rendering ISmartBlockModel s and returns the result of Block#getActualState by default.

The furnace only uses a single model rotated around the y axis different amounts depending on the facing property. Is there a reason you have to use an unlisted property? It's entirely possible to use a normal property whose value is set from a TileEntity in Block#getActualState or Block#getExtendedState , look at BlockFlowerPot for an example.

You don't. TileEntities are only written to NBT when the world is being saved, at runtime you should use the TileEntity 's fields directly. Treat it like a normal Java object. Get the TileEntity at the Block 's position ( World#getTileEntity ), cast it to TileEntityMimicBlock and call the getState method on it to get the IBlockState that particular instance is mimicing.