Guff

By default, getting an object from an NBTTagCompound will return 0 if the key doesn't exist. You might try using hasKey checks. I haven't had any problems with this before, so here's what I would do: if(player.getEntityData().hasKey("lifePoints")) { //do stuff }

Assuming you have an instance of EntityPlayer (we'll call this 'player'), you can use player.getEntityData() and do whatever you need to there.

I'd like to propose more ItemStack sensitive versions of some methods in the Item class. The methods that I have in mind are the "tool material" methods used by tools, specifically. They are: canHarvestBlock() getItemEnchantability() getStrVsBlock(ItemStack, Block, int) and a few others already have the sensitivity to ItemStacks, and that would be nice to have for those other methods. I'm sure there are a few others that could do with added ItemStack sensitivity. I have noticed that many methods would be nicer with ItemStack parameters, but these ones specifically would be more useful to have to start with. Thank you, happy modding!

Do you have a crash report?

ICraftingHandler. Check the inventory's name to see if it's the one you want, then close it from there.

Bump up the number on your for loop.

Use reflection: Make a method in one of your classes to set the member accessible and then remove from it. I've done that: public static void removeChatListener(int index) { try { Field f = NetworkRegistry.class.getDeclaredField("chatListeners"); f.setAccessible(true); List<IChatListener> list = (List<IChatListener>) f.get(NetworkRegistry.instance()); if(list.get(index) != null) { IChatListener c = list.get(index); System.out.println("Removed chat listener " + c); list.remove(index); } } catch(Exception e) { System.err.println("Tried to remove chat listener " + index + " but it didn't work! ):"); e.printStackTrace(); } } Alternatively, you can change int index to be a Class object, assuming you know the exact class of the listener you're trying to remove. IE: public static void removeChatListener(Class listener) { try { Field f = NetworkRegistry.class.getDeclaredField("chatListeners"); f.setAccessible(true); List<IChatListener> list = (List<IChatListener>) f.get(NetworkRegistry.instance()); for(int i = 0; i < list.size(); i++) { IChatListener check = list.get(i); if(check.getClass() == listener) { System.out.println("Removed chat listener " + check); list.remove(check); } } } catch(Exception e) { System.out.println("Tried to remove a chat listener but it didn't work. ):"); e.printStackTrace(); } }

Currently when the game is calculating how much damage to do to a piece of armor, it checks the field damageReductionAmount in ItemArmor. I think what would be nice is, instead of this, a method like getDamageReductionAmount(ItemStack) would be preferable in comparison. This would allow for dynamic reduction amounts, which is something I know that I need, but I think many other people would find this useful, too. Since the ItemStack param allows access to the Item's NBTTagCompound it allows for more options when actually retrieving the damage reduction amount. In ItemArmor.class, it will simply return the damageReductionAmount field. Happy modding!

Hi! I'll try to keep this simple. What I think would be a nice addition to Minecraft Forge is two new interfaces, one for blocks and one for items. The interfaces will have methods that are found in Item/Block and will allow the addition of customized vanilla access. For example, the Item Modifier interface would include methods such as addInformation(params), onItemRightClick(params) etc, basically clone methods of the standard methods. In a class that implements one of those interfaces, modders can define their own customized code for vanilla items, such along the lines of making slimeballs spawn slimes on right clicks, or adding "Yummy!" to golden apple's information set. This implementation should only work for Items /Blocks that don't already have their own custom code, which will limit clashes between right click abilities (swords shooting fireballs and then blocking?) and bring the number of base class edits to a minimum (2). I've already written the scratch code for it so I know how it should work and how the access interfaces should be registered. This will also eliminate the need to override items as a new class and possibly cause conflict with mods that do the same. That's all, happy modding.