coolAlias

IIRC, #onBlockDestroyed is an Item class method - it should be called for all items, not just ItemTools.

Try using Block.getItemForBlock(Blocks.cake) or something like that. If that doesn't work, then the cake block doesn't have a corresponding ItemBlock (like doors), but a special Item, so you'd use Items.cake or whatever it's called instead.

You need to make a new entity each time, rather than spawning the same one multiple times. Every entity needs to be its own unique instance.

As you read more vanilla code, you will see cases of when and when not to use !world.isRemote. Generally, you use it to encapsulate code that changes the world or things within the world, such as modifying a block state, giving a player an item, or spawning an entity. You only need to encapsulate the actual changing code, not necessarily everything around it, though sometimes that is useful to avoid wasting processing power on the client. Anyway, if you model your item after the hoe, then mimic their #onItemUse implementation more closely as I doubt they encapsulate the entire thing in an if (!world.isRemote) statement.

World#playSound plays a sound only when called on the client side (i.e. when the world IS remote). My guess is that your method is only getting called on the server. Is #tillDirt your own method, or inherited from Item and/or ItemTool? If it's your own method, show the code that calls it. If it's a vanilla method, are you sure it is called on both the client and the server side? If you haven't already, take a closer look at the hoe to see how and where it plays its sound.

Hm, your entity registration code looks correct, you're not doing anything strange in your Entity class, and you're testing in a new world so the entity name hasn't changed... those are the usual suspects when it comes to tracking entry errors, so it could be that spawn eggs in 1.9 are bugged. If my coding computer wasn't toast, I'd try it out myself to confirm it; if it is indeed a bug, you can open an issue on Forge's issue tracker (GitHub).

It's always best to post the crash log, but my guess is this is the cause of your crash: this.getBoundingBox() For some strange reason, it usually returns null. Use #getEntityBoundingBox instead, as that will return the actual bounding box.

In my earlier post, I mentioned this: if (!itemstack.hasTagCompound()) { // method name may vary based on version itemstack.setTagCompound(new NBTTagCompound()); } That is the ONLY way you should ever set an empty tag compound on an ItemStack, and that will guarantee that the ItemStack does in fact have an nbt tag. You put that code as the first thing in your #onItemRightClick or #onItemUse method so that the first time the item is used, you will create the tag compound if it doesn't already have one. That way you can add / set your custom tag. You don't need to check if it has the tag or not; integer tags return 0 if they do not exist: if (stack.getInteger("abljeilahgahgeiah") == 0) { // either the tag didn't exist, or it is actually zero } Really, though, you shouldn't be too concerned with that if you follow my advice about using the world time + interval instead of a traditional cooldown timer. There is no reason to add yet another a ticking counter when you already have a perfectly good one.

You have to create the zombie entity, set its position (and anything else you want), and THEN summon it Also, only spawn entities on the server side, i.e. when the world is not remote. The client side entity will be created automatically.

You don't need to worry about giving it an NBTTagCompound when summoned - the tag will be created the first time the player uses it. Unless, of course, you need to store other things in the tag, too? I'm not sure if there are any hooks that allow you to change the outcome of /give and other commands, but I doubt it. If the player has /give permissions, they can set the NBT to whatever they want. As for damaging it when destroying a block, check out ItemTool. I'm certain there is an Item (or ItemTool) method that does just that.

I don't think there is any sort of color code -> int mapping anywhere in Minecraft. You either map them out yourself, or you ask your users to use the integer value of the color they want rather than a string code.

You should really properly indent your code - it's very hard to read right now and probably not a small part of why you're having trouble. Really, it makes a difference: if (itemstack.stackTagCompound.getInteger("word") == 0) itemstack.stackTagCompound = new NBTTagCompound(); itemstack.stackTagCompound.setInteger("word", 60); Look at that - the only thing you do if the 'word' value is 0 is completely wipe any data that may exist in the stack's current tag compound... And then, whether the value was 0 or not, you continue on your merry way to heal the entity. 1. ALWAYS use brackets { } with if statements, even if they are one line. Yeah, some cool kids don't do it, but it can save you some facepalms. 2. NEVER overwrite an existing NBTTagCompound on an ItemStack - you have no idea what it contains, and it is probably important (e.g. enchantment info, etc.) 3. The only time you set a new tag compound on an ItemStack is when it doesn't have one, but if it didn't have one, your check will crash anyway: if (itemstack.stackTagCompound. // right here, because you're trying to call a method on NULL getInteger("word") == 0) Better to use: if (!itemstack.hasTagCompound()) { // method name may vary based on version itemstack.setTagCompound(new NBTTagCompound()); } 4. I don't see anywhere where you decrement the cooldown timer on the stack... so I guess it's single-use? It's better to store the world time at which the stack can be used again anyway, as then you only check when the item is used, not every tick: public static final int INTERVAL = 60; // cooldown interval // when your item is used: if (world.getTotalWorldTime() > stack.getTagCompound().getInteger("nextUse")) { // yay, enough time has passed to use the item again! now set the next time it will be available stack.getTagCompound().setInteger("nextUse", world.getTotalWorldTime() + INTERVAL); } Note: null checks not provided.

FontRender#drawString takes an int parameter for the color, which is a single-value representation of the RGB values. There are color charts available online, or you can search through Minecraft's code for their chat formatting color codes to find their values.

Try removing all spawn eggs for your entity from your inventory, then getting new ones and trying to spawn it again. Does it still happen then? As for the attribute, if the attribute is already registered, you can still change the value: // from 1.8 - names may have changed this.getEntityAttribute(SharedMonsterAttributes.attackDamage).setBaseValue(5.0D);

The method that handles water acceleration is in the World class and is called #handleMaterialAcceleration. If you determine the player is in water, you can do some math to reverse it and then reapply it, or you could probably get by with a simple player.motionX/Y/Z *= 2. If you don't want the player to get pushed at all, you can make a method to reverse the applied motion.

That sounds very reminiscent of a (vanilla?) lighting bug that used to exist but was fixed by Forge - perhaps it's back?

Take a look at the Furnace's Container class - it uses those methods and will show you the correct syntax / names.

IIRC, doesn't ray tracing only find blocks, not entities? Or is #doRaycast something completely different?

The downside is that it renders lots of times, at least 1.8 and earlier that's how it worked. For my own HUD elements, I always render for the ElementType.EXPERIENCE type and it works great. Might want to try that one.

Does the event also have a World object? If so, something like: e.worldObj.setBlockState(e.pos, e.state); // parameter order and types may not be 100% correct

It's not happening with the method you have chosen, no, but there are methods that filter for you, and in 1.9 there are probably even some that accept a Predicate allowing you to custom filter the results. I don't have Forge / MCP on this computer, so I can't tell you any more specifically than that.

Is it only with exactly 2 feathers, or can it be 2+ of any item? If it's the latter, it could be a bug with Forge / Minecraft as the extra layer that renders for the stack size might be doing something funky (it's happened before), or you may want to try using a different ElementType such as EXPERIENCE_BAR during the RenderGameOverlayEvent.Post.

If it's your own Block class, all you need do is override #breakBlock and have it replace itself at that time. If it's not your own block, then you could probably re-place the block from HarvestDropsEvent, though I don't recall if you have access to the BlockPos or state at that point. There are some other events that deal with blocks that you can look into - use your IDE to browse the events at your disposal.

No, that is literally impossible. You can't know which is the nearest without checking all options, though some methods like #findNearestPlayer and such may make it seem like you don't have to check because you are not making the comparisons in your own code.

You're misunderstanding vectors and aabb: the look vector is normalized, so all values are between -1 and 1. If the player is looking straight up or down, x and z coord of look vec are both zero, so: pPos.getX() + look.xCoord*range which equals: pPos.getX() + 0 * range which equals: pPos.getX() So aabb is between pPos.getX() and... pPos.getX(). A horizontal plane of nothing, basically. That, however, is not the issue. The issue is that you are adding the player's position to itself. Vectors are additive, so (x, y, z).add(x1, y1, z1) becomes (x + x1, y + y1, z + z1). Now imagine you are standing at 1000, 60, -500, looking straight west so your look vector is (-1, 0.5, 0) or something like that. Even with a range of 20, the look vector becomes irrelevant compared to the position. Let's take the xCoord for example: pPos = 1000 tPos = 1000 + (1000 + (-1 * range)) = 1980, for example aabb checks for entities between x=1000 and x=1980, which is EAST of your position (very very far east), even though you are looking WEST. Now apply that to all 3 directions; see why you are not getting what you expect? Solution: don't include pPos in the tPos calculations.