Draco18s

Reference the seed through your main class, not as an object passed to the constructor.

My bet is that ModItems.itemWheelHub is not defined (i.e. null)

X, y, z, rot, rot, partialTicks that's six

And getHealth()

This part makes no sense. You're asking to not look at entity health unless entity health is less than 1000. But in order to determine that, we need to look at it. Unless you mean, you want something to happen when entity health is 1000 or lower.

Sigh. Use your IDE for what it was designed for. The function you want is so cleverly named getItemDamage()

Most of it is in the code itself, either as javadoc or just by exploring the code base.

Block's updateTick function does not run every tick. ......unless you schedule it to. Look at the repeater.

Yes, it absolutely does, which is why I suggested it . Edit: fixed url tag; tablets are annoying

Invisible blocks are just blocks. But if you want to test it, go find my Unique Artifacts mod.

Not really a new trick. There are some problems with it, too, if you're not careful. But they're minor and as long as you are aware of them, you can tweak the invisible block (and item) to account for it. Eg. What happens if the player drops the item? Dies? Is underwater? Had sand fall on him?

You can't. End of story.

Creating is an event now.

Integer health is only used for the overlay. The health float is fully saved and maintained, due to weakness portions dropping unarmed damage below half of a heart.

If a "sufficiently deep cave" suffices, look at the player's location's sky light value.

A lot of people say it. There is almost no reason to need an edit to a vanilla class: everything already has every conceivable hook. But should you find one missing, there are coremods developed using ASM. But beware the abyss, for it looks back.

Rendering from a given point is easy (this is assuming you mean in the "if the player was there" with perspective, shaders, and all that). There's a handful of things to keep in mind (graphics settings*), but essentially you wait for a (pre or post, pick one) render tick event, then relocate the camera (you will need an entity to target), render, then switch everything back. You render to a dynamic texture, then do whateverthefuck you want with it. *You might want to disable particles, clouds, or other things. Save the current value, render, then set the values back, just like the camera.

http://yourgameideaistoobig.com

A short still gives you a max value in the neighborhood of 32000, which should be enough for anyone.

Which is useless, because he's breaking the block, not activating it. His problem has nothing to do with generating a random item, but with correctly implementing the getDrops function, which the code you posted doesn't use.

http://minecraft.gamepedia.com/Hardness#Speed

You mean....by creating an empty list? @Override public ArrayList<ItemStack> getDrops(World world, int x,int y, int z, int metadata, int fortune){ //don't call super, that drops the block. //Don't call this function, that causes an infinite loop. //Create a new list. ArrayList<ItemStack> stack = new ArrayList<ItemStack>(); stack.add(...); return stack; } Also, Thornack's post is useless.

It might be one character, but it is quite literally the difference between black and white.

Yeah, I keep a shortcut to the vanilla jar for when I need to go extract some texture and utilize it.

No, because the Block is a singleton and the material is a property of the block. You would have to use a tile entity and calculate the player's relative break speed manually. Which I had to do for a block because the tool I wanted to "harvest" it was not considered a tool (the hoe), so it had no efficiency values.