Choonster

EntityPlayer#getItemInUse is marked as @SideOnly(Side.CLIENT) , which means that it doesn't exist on the server. To access the EntityPlayer#itemInUse field on the server, you'll need to use reflection or an access transformer.

I think the error is caused by returning null from Item#onItemRightClick . ItemInWorldManager#tryUseItem expects a non-null ItemStack to be returned, even if its stackSize is 0 (which it explicitly checks for). Oddly enough, it does check if the returned ItemStack is null; but only after checking that the returned ItemStack is equal to the original ItemStack (which can't possibly be null at that point).

In 1.7.10 and 1.8, the stack size is drawn in RenderItem#renderItemOverlayIntoGUI .

You should override Block#getBlockLayer to return the appropriate layer (explained in TGG's post) and Block#isFullCube to return false .

You need to override Block#isOpaqueCube to return false if your Block isn't a full cube. This way the adjacent Block s will still be rendered. The Grey Ghost has a post on transparent blocks here.

BlockContainer overrides Block#getRenderType to return -1 (no renderer) so you can use a TESR to render the Block . If you want to use a JSON model, override it to return 3.

Use World#getTileEntity to get the TileEntity at the specified position and then cast it to your TileEntity class.

You're instantiating BlockOBBaseFluid before you register your Fluid s, which is invalid. You should instantiate your Fluid s and Block s inside methods called during preInit rather than in field initialisers.

You made fuse and ignited static, so they're shared between all instances of your TileEntity class.

Use EntityPlayer#addChatComponentMessage .

Ah, I missed that. onBlockHarvested should work. This is only called server-side by vanilla, so send the message when World#isRemote is false .

Got it. So I should write @SideOnly(Side.CLIENT) and then below override onBlockDestroyedByPlayer. Makes sense. No. Never use @SideOnly unless the method you're overriding uses it. This method is called on both sides. Instead, check the value of the World#isRemote field ( true on the client, false on the server). I usually send chat messages from the server side, but I don't think it matters as long as you only do it from one.

There's no such thing as "the player" outside of client-only code. There may be any number of players in a World . You should override Block#onBlockDestroyedByPlayer instead, making sure to only send the message on one side.

That won't work. Only one instance of the class exists, so any fields are shared between all stacks of that item type. You need to store all data in the NBT, read from and write to the stack's tag compound directly rather than storing data in fields.

Item s are singletons, only one instance of the class exists for each type. If you want to store data for individual items, you need to use the NBTTagCompound of the ItemStack that you receive as an argument of various Item methods. If you don't have an ItemStack argument, you don't have access to the data.

I've trouble with sending a packet from server side to client side It's my first time with packet sending Have you searched for a tutorial? I believe diesieben07 has one on this forum.

Each possible state of a Block is assigned an ID based on the Block 's ID (automatically assigned) and the metadata value of that state (returned from Block#getMetaFromState ). These IDs are used by ExtendedBlockStorage to store the contents of each chunk. If two states share a metadata value, ExtendedBlockStorage won't distinguish between them. If you want a property's value to be saved with the world, you need to store it in the metadata (just like 1.7.10 and earlier).

You need to encode the files in UTF-8 instead of ASCII/ANSI. How you do this depends on your IDE, there are probably instructions for this if you search.

If the problem was that your resources weren't being copied to the output and you were using IntelliJ IDEA, you can add this to your build.gradle to fix it: // Fix resources not being loaded in IDEA // http://www.minecraftforge.net/forum/index.php/topic,32467.msg169687.html#msg169687 idea.module.inheritOutputDirs = true

This particular check is redundant. If getTagCompound returned null , hasTagCompound will always return false ; so there's no need to check both. Have you considered moving the spells to their own classes? It would reduce the number of huge if chains in your wand class.

Like I've tried to tell you several times: don't use the WorldGenTallGrass class (because it can't be used to generate your block), adapt the logic from its generate method into your own class.

Use the same logic as WorldGenTallGrass does for finding the ground level, then generate your block instead of tall grass. WorldGenTallGrass#generate is called from BiomeDecorator#genDecorations , you can trace the call locations from there to see how the initial position is determined.

JSON models control all textures (except if you're using a TESR). Look at the model for a vanilla block with the type of sided textures you want to see which model it inherits.

Don't compare strings with == , use the equals method. Strings with the same content (which is what the equals method checks) aren't always the same object (which is what the == operator checks). Since display names can be changed, I'd recommend storing the UUID of the owner instead (which is guaranteed to remain the same); you can get this from the Entity#getUniqueId method. UUID s are stored in NBT as a long for the most significant bits and a long for the least significant bits (returned from the appropriate UUID getter methods) and can be read back with the UUID(long,long) constructor. UsernameCache.getLastKnownUsername will return the last known username of the player with the specified UUID . I'm not too sure what would cause an item to lose its NBT when dropped. Your code is a bit hard to read, I'd recommend using your IDE's auto-format tool and posting it on Gist or Pastebin with syntax highlighting. The cooldown code in the second code block looks right to me.

The owner of the skull is stored in the NBT, but vanilla recipes ignore the NBT of ingredients. You'd need to make your own recipe class that implements IRecipe and checks the NBT of the ingredients in addition to the Item and metadata.