Draco18s

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.

You need to write your own recipe handler to check for stack sizes. Furnace recipes don't care how big the stack is. So you'll need a way to check that a recipe is valid (ignoring stack size) and then get how big the input stack size is for the recipe and check that the slot has at least that many items and then remove that many items when it completes. This is how I handled it. It's likely not the best way, but I was working off of the vanilla furnace's handling.

Haven't the faintest.

They custom built their animator. public class DragonAnimator { ... }

player.worldObj.provider.dimensionId

Yeah, I'd given it a shot after I'd seen a lot of praise on these forums, but it turns out no one uses it for animation. Surprise, surprise.