SanAndreaP

Nope, just use this: worldInstance.getMoonPhase() I didn't use this, but I think after looking at the code, it's returning a value between 0-7. You have to figure out which is the full moon. Don't ninja threads.

seriously?

Add @Override to your onItemUse method. If there is an error appearing, you're using the wrong method.

You will still have the item on the client-side, although it's disappearing when you do something with it (dropping, using etc.) What I suggest is to send a packet to the server, the server removes the Item and then call playerInstance.openContainer.detectAndSendChanges() This will automatically send any change in the players inventory to the client, thus removing the item in the client.

You can return 22 as the render type in getRenderType() inside your block. It's what the chest does. But please note, since the new texture system, you still need a "block texture" which is registered in the block class or you will get "Missing Texture" particles flying around when punching the block!

In your Item class, where do you register your texture?

Yes, because the new texture system only affects items and blocks.

1. Don't use the ModLoader class. It's bad when using Forge. Look into that class, since the ModLoader class is only a compatibility layer, there are the right Forge methods you should use. 2. Where do you register your TickHandler?

Nope, TileEntities are only "accessible" after placing a block. If you want to store TE data into an item (block in your inventory), then you have to use the NBTTagCompound of your ItemStack. Write the data into that NBTTag and if you place the block again, write the NBT data into the new TileEntity.

This example isn't really good, tbh (for example, why do you extend EntityPlayer?). I would go for the LivingHurtEvent. Here's some Pseudocode: @ForgeSubscribe public void onPlayerHurt(LivingHurtEvent evt) { if(evt.livingEntity instanceof EntityPlayer AND evt.livingEntity.getHealth - evt.damageAmount <= 0) { teleportPlayer((EntityPlayer)evt.livingEntity); evt.setCanceled(true); } }

Well, you CAN do it for a block. The thing is just, I would rather use the TileEntitySpecialRenderer in combination with a TileEntity. If you have that, look at the RenderPlayer class (especially the renderStats() method)

I know im talking about mod version has a bug the minecraft version is okay You misunderstood diesieben07. He meant this line: versionBounds = "[1.5.1]" This variable is NOT for the Minecraft version! It is for your own version.

Which size was the texture before? Whatever it is when you don't override the values in ModelBase, I wanna say 64 x 32. If you increase the texture size, you have to always keep the ratio of the image. Means if the standard is 64 x 32, then the ratio is 2:1. Increasing the height to 64 must result in increasing the width as well. Means your image must have the size of 128 x 64. OR you can add this to each of your ModelRenderer variable, in your Model constructor (after you've initialized the ModelRenderer of course): MyFoot1.setTextureSize(64, 64)

Which size was the texture before?

To get the graphics level, use this code: Minecraft.getMinecraft().gameSettings.fancyGraphics and set the graphicsLevel variable from your leaves instance with the code above in your TickHandler.

I had this problem, too. Just make a txt file next to your animated texture, name it the same as the texture and you should be fine. Leave the txt file blank. For example: texture.png <==> texture.txt

Also don't install ModLoader besides Forge. Ever.

How about using a TickHandler, with TickType.CLIENT, and set the graphics level for yourself?

Either use MultiMC, or look at it's source on github.

It's the Metadata / Damage value of an item / block.

i did exactly what you said and it still errors the "new ItemStack(DivineStone.itemID, 1)," Use the constructor with 3 Integers: new ItemStack(divineStone.itemID, 1, 0) or the one with the Item and the integer as parameters: new ItemStack(divineStone, 1) Also please watch out for capitalizing, since Java is case-sensitive!

This funky name "field_xxxx" is actually the runtime deobfuscated name. It a so called "SRG name". What you want to use would be CSV names, but since they're community-driven, they aren't used there. The solution would be the ObfuscationReflectionHelper class. I use it like this: ObfuscationReflectionHelper.setPrivateValue(EntityLiving.class, entity, 0, "recentlyHit", "field_70718_bc"); So the parameters would be: - class to access - instance - value - the CSV name (the name used in the MCP workspace) - SRG name (the name during the runtime-deobf)

Yes this happens for me, too, since I updated to 1.5.1 (Forge 7.7.1.611). I don't know if a later version of Forge provides a fix. I have to test this.

Yes it is as of 1.5. Actually the "MISSING TEXTURE" icon, which is in MC, is 64x64 in its size, so it IS possible

I assume both need to be upgraded.