Choonster

WorldGenTallGrass only works with Blocks.tall_grass . I meant for you to look at the class to see how it chooses the generation position rather than use the class itself. In future, please give your Gist files the appropriate file extension (.java for Java code) so syntax highlighting works.

Look at the doc comment for the VersionRange.createFromVersionSpec method, which is used to parse the acceptedMinecraftVersions field.

What's your current issue? If it's still crashing, post the new crash report.

Gradle skips a task when it's already run it before and the output is still valid. It's normal for those tasks to be skipped if you've already set up a workspace for that version before.

WorldGenMinable is designed for replacing a terrain block (e.g. stone) with another block (e.g. ore), but your bushes are supposed to generate on top of the ground rather than in it or in the air. I'd recommend looking at WorldGenTallGrass to see how it determines where the ground level is and then generates on top of it.

So create a getCooldown(ItemStack) method that reads the wand's level and spell from the ItemStack and returns the cooldown of the wand in ticks. Replace the FIRE_RATE constant with a call to this method in isOffCooldown .

What determines the cooldown of the wand? Player level? Wand level? Wand type?

Get the player's level (presumably using your IExtendedEntityProperties implementation), derive the cooldown from it and any relevant properties of the item and then use that instead of the constant.

This section is for mod development help, not mod usage help. I'm not sure there's a section on this forum for that. Unless a mod is client-only (e.g. a minimap) or server-only (e.g. backup creation or admin tools), it must be installed on the dedicated server (if any) and all clients. You both need to have Pixelmon installed.

You're using the 1.7.10 method signatures, but they were changed in 1.8. If you look at the WorldGenMinable class, you'll see the new signatures for the constructor and the generate method. In 1.8, most Block and metadata method parameters were replaced with an IBlockState parameter and individual coordinate parameters were replaced with a BlockPos parameter.

Explicitly comparing booleans won't cause any problems, it just makes your code look messy (and needlessly verbose).

When the player uses the item, store the current total world time (World#getTotalWorldTime) in the NBT. When they use it again, subtract the stored time from the current time and check if it's been at least X ticks since the last use (where X is the cooldown). If it has been, store the current time again and perform the effect; otherwise do nothing. I have an example of this for 1.8 here, I've tried to document it fairly well.

Yes, but there's no need to explicitly compare a boolean to true or false. Just use if (someMethod()) or if (!someMethod()) .

A NullPointerException is being thrown because either itemstack or itemstack.stackTagCompound is null , I suspect it's itemstack.stackCompound . Always check if an ItemStack has a stack tag compound before trying to read from or write to it.

Use IWorldGenerator and GameRegistry.registerWorldGenerator to generate something in the world. You can use World#getTopSolidOrLiquidBlock to get the y coordinate of the highest solid block (excluding leaves) at the specified x and z coordinates (which is usually the ground).

this is what i would do: (remember, you can design your own system to fit your needs, this is just what i would do) have a private final field in your item class containing the cooldown time in ticks. (in this example i'll call it cooldown). timer is the value of the timer (don't know if you want to save it to the nbt or as the dmgValue) in opUpdate(): if(timer > 0){ >>> decrement the timer } in onItemUse(): if(timer <= 0){ >>> use spell >>> reset timer to cooldown } you can use this to get an idea of a possible implementation, but you'll have to implement the actual system yourself, so you can make sure it fits your needs Storing any data in a field of your Item class is a Bad Idea. Item s are singletons, so that cooldown will be shared between all occurrences of that Item . If you need a cooldown, use NBT.

When you set an item as "in use" (like the bow does), you specify the maximum duration of the use (how long the player can hold right click to continue using the item). The useRemaining parameter of getIcon is how many ticks of that maximum duration remain. Subtracting the remaining duration from the maximum duration gives you the current use duration (how long the player has been using the item).

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