coolAlias

EntityItemPickupEvent is on the MinecraftForge EVENT_BUS, not on FMLCommonHandler; you will need at least two separate event handler classes, one for each of the event buses.

I don't know about you, but to me it looks like you are using par4 twice and ignoring par3 in your super() call here. That might change some important information when the class is constructed. An ID perhaps? Sequituri is 100% correct here, but it's even worse: you used par4 THREE times, as the ID, the armor type, and the render index. Oops. super(par4, par2EnumArmorMaterial, par4, par4); // should be (par1, par2EnumArmorMaterial, par3, par4)

I just tried it and it worked perfectly. That method did not change the inventory Icon, but it DID change the one held in my hand, so you need to use both. This is the code I used for testing: public ItemStack onItemRightClick(ItemStack stack, World world, EntityPlayer player) { if (!stack.hasTagCompound()) { stack.setTagCompound(new NBTTagCompound()); } int icon = (stack.getTagCompound().getInteger("icon") + 1) % 3; stack.getTagCompound().setInteger("icon", icon); return stack; } public IIcon getIcon(ItemStack stack, int pass) { int icon = (stack.hasTagCompound() ? stack.getTagCompound().getInteger("icon") : 0); switch (icon) { case 1: return Items.wooden_axe.getIconFromDamage(0); case 2: return Items.iron_axe.getIconFromDamage(0); case 3: return Items.diamond_axe.getIconFromDamage(0); default: return itemIcon; } } If you have registered your IIcons and stored them in your Item class, you can return them directly. I used vanilla items just for the sake of testing.

I don't believe that getIconIndex is used by the in-hand render calls, though I haven't double-checked. Try overriding a different method(s) in your Item class, such as: public IIcon getIcon(ItemStack stack, int pass) Alternatively, you could implement an IItemRender for your Item and handle the NBT data that way, but I doubt that will be necessary.

That's an excellent point that I think many people probably don't think about right away. Thanks for pointing that out!

Not sure if it makes any difference, but all of my sound files and corresponding names in the json file are entirely lower case. If that doesn't work for you, double-check that both your json and sound file are really the format that you think they are, and not just renamed to have that extension.

Exactly what TGG said, not to mention that every entity, when hurt, becomes temporarily resistant to damage for roughly one second (or maybe 1/2, can't recall exactly). Anyway, the point being that the vast majority of your machine gun bullets would be wasted even if you could manage to do it exactly how you wanted, which is not a good idea. Try what TGG suggests.

Can you post your packet class? A few notes: 1. It's usually better to use a more generic class in your method parameters, such as EntityPlayer - EntityPlayerMP is only for the server, but is still an instance of EntityPlayer 2. Particles will not spawn on the server; you need the method to run on both sides, reinforcing point 1 3. Why not just use the regular Item#onItemRightClick method? For example, in your packet class: // or whatever method you use, but it should only be handled server side handleServerSide(EntityPlayer player) { ItemStack stack = player.getHeldItem(); if (stack != null && stack.getItem() instanceof YourGunItem) { ((YourGunItem) stack.getItem()).onItemRightClick(stack, player, player.worldObj); } } Be sure to call the onItemRightClick method on the client side from the mouse click as well. Then you can move all your code to the non-static Item method, and use "if (world.isRemote)" to determine which side you are on: if (world.isRemote) { // spawn particles } else { // spawn bullet }

cpw's Loader class has several methods for getting which mods are loaded, such as getModList and getActiveModList.

The default is for streaming to be false, so you shouldn't need to add all that extra information. { “Ambient_Hit”: {"category": "master","sounds": [“Ambient_Hit”]} } Try that. Also, if you didn't know the category designates which volume control in the options menu controls this sound's volume. Check out the menu to see which category may best suit your sound.

You can't spawn entities from a keybind without sending a packet. Keys (and mouse) events ONLY happen on the client; EntityPlayerMP is the server version of the player, but you can't get it on the client. Packets packets packets. Btw, you mentioned you are still using a key binding? You shouldn't need to have a custom keybinding - you can simply check if the vanilla keyBindUseItem (i.e. right mouse button) is pressed. It's already a keybinding.

Use MouseEvent - it is fired every time a mouse button is clicked, but keep in mind that keys are all handled only on the client side; you cannot check if a key is pressed on the server without sending a packet. Also note that if you need the key to be keyBindUseItem and not just right click, if the player changes the keybinding then MouseEvent may not be the perfect solution. If you just want to know if the key is held down, you can use KeyBinding#pressed or KeyBinding#isPressed() at any time (on the CLIENT, checking for KeyBinding Minecraft.getMinecraft().gameSettings.keyBindUseItem). pressed returns true only when the key is actually held down; isPressed() can return true for a number of ticks after it is released.

You can either a) have an entry in your lang file for each metadata version of the block (based on the unlocalized name that you return), or b) have one entry for the name of your block and override the getItemStackDisplayName method to return a combination of your block's translated name plus the dye color's translated name. Example: @Override public String getItemStackDisplayName(ItemStack stack) { return StatCollector.translateToLocal(getUnlocalizedName()) + ItemDye.dyeItemNames[stack.getItemDamage() % ItemDye.dyeItemNames.length]; }

Run "gradlew setupDecompWorkspace"

You never add any data to the NBTTagCompound, which you don't even need since you can write the int and String directly to the output stream, and read them back in. You don't need getter and setter methods because you will never be (should never be) trying to access your variables outside of this class.

^^ That's what I was trying to say, though in C++ you can pass a pointer by reference, in which case you can change the original pointer's address... the source of many a C++ coder's nightmares, to be sure Pretty sure anyway, it's been many many years since I've touched C++, so I might be terribly wrong about that statement.

Exactly

In C++ that would be true, but in Java all variables are passed by value; for non-native types, the value is always a copy of the memory address (maybe not always, but I'm pretty sure that's the case). Unlike C++, you cannot pass by reference in Java, even when passing a memory address. Java is "pass by reference by value", as they like to say EDIT: Here is a link that explains it probably better than I am: http://stackoverflow.com/questions/40480/is-java-pass-by-reference

Item#addInformation is what you're looking for.

You can't use NBT during initialization because you don't have any NBT and you don't have any way to get valid NBT. The whole point of NBT is that it is attached to a specific ItemStack, it's not magic that stores data anywhere At this point you should just start coding and see if you can get it to work. Start with something simple first, and add things one at a time, making sure each one works before moving on to the next. If you try to do it all at once with no prior experience, you're just asking for trouble.

That's not how NBT works. You need an ItemStack to have access to NBT, and you won't have one when you are assigning damage, but you could get the MultiMap when your item is changing / breaking or whatever and set a new value from there, in which case you should have an ItemStack handy.

Oops, wrong button No, I'm saying that YOU will have to make it rely on NBT for that stuff, which is not going to be a walk in the park. Weapon damage is based on the multimap data, which does not have an ItemStack parameter, meaning your best bet for changing that is to create a new Item, though that can be worked around it's a lot easier to do it that way.

Except Java passes by value, not by reference: public void aMethod() { ItemStack stack = new ItemStack(Item.diamond); bMethod(stack); System.out.println(stack.toString()); // changing stack to null or anything else here does not affect what becomes of the stack sent // to bMethod, nor does it change what a reference created in bMethod points to } public void bMethod(ItemStack stack) { ItemStack pointer = stack; stack = new ItemStack(Item.emerald); System.out.println(stack.toString()); // prints the emerald stack System.out.println(pointer .toString()); // prints the diamond stack from aMethod } If the stack from aMethod and the pointer from bMethod both point at the same memory location, then whatever one does to that data will be reflected in the other; but changing the location that one of those points to does NOT change what the other one points to. Sorry, but you are still wrong.

Gotcha. You can still do it either way, though. For your idea, you will need to override lots of methods, making sure each one has an ItemStack parameter so you can access the NBT and return an appropriate value based on that, rather than the Item's base values. Any method that you need that does not have an ItemStack-parameter version will require a new Item to handle, but you can still copy the NBT over to the new item when you set the player's held item, retaining all the important data.

You may as well just switch to a different item at that point. Is there any reason that you need to keep it the exact same Item or ItemStack? Will you keep the NBT data intact? You can do that by transferring the NBT to a new stack with a different item. You could do it all in one class, but it's cleaner (and easier) to have a separate item if that many traits will be different.