coolAlias

Override Item#onCreated(ItemStack stack, World world, EntityPlayer player) in your item class and add whatever enchantment you want to the stack. Or, if it's not a custom class, use FML's ItemCraftedEvent.

He gave you exactly the code you need, but you are using it incorrectly. You do not create a "new" EnumCreatureType, you just did that using the EnumHelper above; likewise, ENeola is not going to be found in EnumCreatureType.ENeola, because it doesn't exist in that class. Replace "new EnumCreatureType(ENeola)" with "ENeola".

Like sequituri said, you will not be able to remove it due to the '==' operator; however, what you can do is cheat and keep a local instance of the AI in your class, like EntityTameable does with the AI for sitting. This way, you have access to the memory location and '==' will be able to return true. protected EntityAISit aiSit = new EntityAISit(this); // you can now use tasks.remove(aiSit) and it should work Another option is to use List#clear() to remove all AI tasks, and simply add the ones back that you want.

You are setting the value incorrectly, use itemstack.getTagCompound().setInteger(String, int). ItemStack#setTagInfo adds an NBT tag to the item's tag - you can't just use it for any type of data. Also, tags are stored with a String identifier, so "0" is probably not what you think it is. It should be: setInteger("enchant", 0). You should really look more closely at vanilla code examples using NBT, or read the wiki tutorial on it.

Not quite true. Item damage is a short, meaning 2 full bytes. You can squeeze a lot of information in 2 bytes Lol - of course you'd point that out I usually avoid mentioning bit operators unless in the context of Block metadata, just cause... you know. @OP It crashes because you are not null-checking; stack NBT will be null until you set a new NBTTagCompound. Always check if the tag is not null before using it.

If your item has subtypes or is damageable, then you will not have the metadata (i.e. stack damage) option. I didn't mean that removing the "static" modifier from "public static int enchant" would solve your problems: Items are all declared statically, so all Item class fields are also effectively static no matter what you do because there is only one instance of the Item in the game. Unless you want all of your enchanted items to always have the same enchantment, not just for you but for everyone else that has one, then you cannot store any data like that in a class field. Use the stack's damage if you can, or NBT if you cannot.

I thought I just told you that "if(this.Enchant == 0)" kind of stuff will not work... you need to use the ItemStack NBT, not a local field in your Item class. Items are declared as static instances, meaning that ALL class fields (e.g. private int enchant, etc.) are shared amongst ALL instances of that Item. Here you go: http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html

Also, setting "this.field = 1" will set it for ALL Items of that type, so every single player who has that item will have their item changed. You need to put your code within the "if (stack != null && stack.getItem() == YourMod.yourItem)" statement, otherwise you are running that code for every single slot in the inventory without checking. FYI, if a stack is not null, stack.getItem() will never be null. Finally, be sure to break out of the loop after setting the inventory stack.

I would also like a resolution to this issue. Likely someone forgot to remove their own debug before release.

I used 1 and got some errors so squituri told me this: I'm using 7 now. Is this wrong? If using 1 didn't work then the id is not your issue, the issue is as GotoLink mentioned with your packet system - the packet-handling tutorial you mention is up to date for 1.6.4. Actually, if you are coding for 1.6.4, the packet class is totally different: Packet132TileEntityData in 1.6.4, S35PacketUpdateTileEntity in 1.7.2., so that may have been one of your errors as well. Are you trying to code both versions at the same time??? Might be easier to focus on one version first, so we can provide more reliable answers.

To get the slot number, typically you have to iterate through the inventory until you find it: for (int i = 0; i < player.inventory.getSizeInventory(); ++i) { ItemStack stack = player.inventory.getStackInSlot(i); // check if stack is not null and if it is the item you want // if it is, you now know the slot number is ' i ' // do what you want, then break, since you don't need to keep iterating } Containers are both server AND client - why do you think a container instance is used in the GuiContainer class? Where are you trying to call all this code from, anyway?

... you do realize that that method is CLIENT side only, right??? You shouldn't / can't set NBT data from there. Think of the client side as read-only.

new ItemStack(Item, numberOfItems, stackDamage) When using player.inventory.addOrRemoveStuff, make sure you are only doing it on the server side or you will have issues of items looking like they are or aren't there when they shouldn't or should be. To place the new stack in the same slot, first you'll have to get the slot index of the item to replace and use setInventorySlotContents(int slot, ItemStack stack).

That's pretty bizarre, but if I recall correctly you are doing a lot of custom stuff with your tool class. You didn't happen to override the "public int getDamage(ItemStack stack)" method, did you? If so, that may be part of the issue. On a side note, I would probably check if (stack.getItemDamage() > 0) as the very first step in the onUpdate method, with everything else inside of that, since you only care about damaged stacks trying to repair.

It would be really helpful if you showed us whatever code you had tried, rather than just a description, but it sounds like "currentMaxDurability = currentMaxDurability + 1" has nothing to do with the ItemStack. You need to actually reduce the damage on the stack, because damage is added until it reaches max damage at which point it breaks. Perhaps try something like this, but be sure to include your other checks as needed: if (stack.getItemDamage() > 0) { stack.setItemDamage(stack.getItemDamage() - 1); }

That's being caused by one of your custom TileEntity's description packets. When you send the packet, there is an identifier that goes in the packet signature; I always use '1' and it works fine: return new S35PacketUpdateTileEntity(xCoord, yCoord, zCoord, 1, nbttagcompound); If that's not your issue, then as Jwosty suggests we will need to see more of your code.

Gotta love older code I've got plenty that makes me shudder in horror when I look at it now, so I'd say yours is looking pretty good by comparison! Glad I (or rather, lockNload) could help.

Those are good wrapper methods, but I don't think it's advisable to use update frequencies of 1 for your entities. Mobs, for example, typically use 3, while arrows use 20 and throwables use 10 (in vanilla). Using different values than those may cause strange problems or lag - I've noticed it most with arrows - your mileage may vary, and I'm sure you have good reasons for using 1 since you seem to know quite well what you're doing. This spreadsheet put together by lockNload147 sums up the vanilla entity tracking values.

It's important to note that EntityLivingBase's rayTrace method is client side only, so if you plan to use it, plan on sending a packet.

Oh man, this whole time I've been sending custom packets to update all nearby players... I've even used this method for blocks, but didn't think to use it with tile entities. I so smaht. Thanks for that! Side note: the method will only re-render the block if the id or metadata has changed, at least according to the java-docs, so custom packets would still be necessary if you need to re-render and neither of those changed. EDIT: Maybe not, since it also says the TE description packet gets sent during the update... this is great!

I'm not sure why it would matter in this particular case, but the "==" operator in Java checks identity (i.e. memory address), whereas the equals method is typically overridden to allow objects to be considered equal even when they are not at the same memory address.

You could cheat and make an invisible entity that is not affected by gravity, so when the player uses the item it shoots out one of those and teleports the player upon impact. If you want to be able to teleport somewhere even if the player isn't looking at a block (or don't want to use an entity), then you can traverse the player's look vector using for loops to increment each posX/Y/Z by the vector's corresponding coordinates until you either have run 128 iterations (traveled 128 block distances) or hit a block, at which point you teleport the player to that position (or that position minus one or two, if you hit a block).

You can still open the class hierarchy in the package explorer and see what methods are available, even if you can't see the code implementations. The left-hand pane in Eclipse is the package explorer; go to "Referenced Libraries" and expand the forgeSrc->net->minecraft-> etc. folders. If you expand a class, all the methods will be listed.

So open up the ItemStack class or browse the methods from the package explorer to find one that is. There is a public class method that compares the Item and damage values (but not NBT) and a public static method for comparing two ItemStacks that also accounts for NBT.

Usually you can tell which bus an event should be on by looking at the import path.