coolAlias

What Minecraft version? In 1.7.10, there is EntityLiving#onSpawnWithEgg, and in 1.8 it was renamed to #onInitialSpawn and takes an extra parametr. Yes, you can change the entity's position from there, but why would you want to make the entity always spawn at one specific location?

@Override public boolean onItemUse(ItemStack stack, EntityPlayer player, World world, int x, int y, int z, int side, float hitX, float hitY, float hitZ) x, y, and z are the coordinates of the block hit. This is why you always want to try and rename your parameters, otherwise you very likely have no idea what they do.

Ah yes, that's the one!

@OP DO you see what I used for addRecipe? 'stack', because that's the name of the ItemStack to which I added the enchantment, and that's the stack I want as the recipe output.

So either copy all of them into a static Utility-type class, or use Reflection to call #renderEffect with the RenderItem instance you can retrieve from Minecraft. EDIT: And why are you scaling your HUD? If you look at GuiContainer, it never calls scale. In fact, that's where I would look to see how to render an item with enchanted glow, or just an item in general, into your HUD.

Yikes - you probably need to spend some time following Java tutorials. 1. Items.diamond_sowrd is misspelled, which your IDE would probably tell you if you hovered over the error 2. GameRegistry.addRecipe(new ItemStack(Items.diamond_sword), <-- not an error, but that is not the stack with the enchanment Well that's it - I only saw one error that your IDE would complain about, so if you're getting a 'bunch', then you've got some work to do.

Let me refer you to the official instructions, as well as a by Lex Manos that covers the setup quite thoroughly.

You are thinking of packets, in which the order most certainly does matter because it is a stream of bytes, but NBT, as others have pointed out, is key : value pairs, so order is irrelevant.

You should be able to just call the RenderItem method renderItem directly and it will do it for you: Minecraft.getMinecraft().getRenderItem().renderItemModel(stack); If that is not sufficient, then look at RenderItem#renderEffect to see how the enchanted glint is handled, and copy that (or use Reflection) into your render class.

You make the ItemStack first, add the enchantment, then create the recipe: ItemStack stack = new ItemStack(sword, ...); stack.addEnchantment(whateverEnchantmentYouWant, ...); GameRegistry.addRecipe(stack, ...);

If your 'empty' model isn't showing no matter where you try it, then the problem must be either with the model or the texture, and my bet is on the model. I've copied and pasted plenty of models, and about half the time I ended up with texture issues like this because I forgot to add or remove 's' from 'block' or 'item' in the texture or model name, i.e. models are in 'block' or 'item', but textures are in 'blocks' or 'items'. The point is, just because you copied and pasted it, doesn't mean there isn't a problem. Post your empty.json model contents. EDIT: Actually, I think Ernio has the right of it, as if you messed up on the naming, you should have gotten an error message in the console which you clearly didn't. Oh well.

This is because if you are doing things right, you initialize all of your Blocks before your Items, and thus your custom Item reference to SoulShard is still null at the time you assign it. That's the reason Block has methods to return the Item it should drop, rather than storing it as a class field like you are trying to do. To resolve your issue, use the methods provided.

That's a good point - you need to add variants during preInit, but register to ItemModelMesher during regular init.

EDIT: I have no idea why I thought you were making a Block... In addition to registering your variants, you also need to make an ItemBlock class, or use ItemMultiTexture from vanilla, that returns the correct damage value for the stack, as well as register each renderer for the correct item damage value: @Override public int getMetadata(int damage) { return damage; } // register each of your variant's resource locations with the correct damage value, assuming they are in an array: for (int i = 0; i < variants.length; ++i) { mesher.register(this, i, new ModelResourceLocation(variants[i], "inventory")); } I guess in your case, you'd just need to add each damage value for your Programmer registration, as you just have '0'. Btw, when you register a variant, I'm pretty sure you need to fully qualify the name, e.g. "yourmodid:empty". Also, I'm sure someone mentioned it before, but you should use your proxy for registering the model resource locations and variants.

Like what others have said, if you have a reference to your Config object stored somewhere, such as your Main class, then writing to it from a command is as simple as using that reference to access a value in the file like you do when you first load the config. However, what would be the point of this? Do you just want the command to change the config setting that is currently being used in the game? If so, you need to change THAT reference, not write to the config file - the only reason you would write to the config file is to save the change for the next time the player loads the game, but you'd still have to change the current value of the config setting for it to have any immediate effect.

Of course you have your reasons, but are you not also making assumptions about the tone of responses? Certainly some are outright hostile, yet others which may seem hostile are, in fact, not. And just as you have your reasons for assuming that a tone is hostile (e.g. you have received many hostile responses in the past), so too we have our reasons for assuming you blindly copied and pasted the code - we see it all the time, day in and day out, and 99% of the time it is a correct assumption. Anyway, just pointing out that we all have our reasons for what we do, and they are not always obvious to other people, which leads to unfortunate situations such as this. But at least your problem has been resolved. I hope you continue to ask questions in a mature fashion in the future, and hopefully you will not receive negative responses.

Whoa whoa whoa chill buddy. None of that was hostile, though perhaps you could interpret it that way. I am merely trying to emphasize that you should read code more carefully, and assumed (wrongly, apparently) that you had just copied and pasted it because you left in the ARMOR_SLOT index. I couldn't possibly know that you are alphawolf918 on a different forum when you go by a different name here, and Container code is almost always nearly identical, thus the assumption above. Sorry you interpreted my post as hostile. I use CAPS for emphasis, not hostility. EDIT: Also yes, I have seen that 1.6.4 is not supported at all here. I tried to answer someone's question (about 1.6.4) once, and my comment was deleted and the topic locked. I don't get that, but that's just a fact of MinecraftForge.net.

That's what happens when you blindly copy and paste code. In my tutorial, I talk about adding armor slots, which is why there is ARMOR_START etc., but you do not add any armor slots to your inventory container, so all of your array indexes are off by 4: 38, 39, 40, and 41 do not exist, i.e. they are "out of bounds". Please read more carefully, and actually read ALL of the code so you know what's going on, rather than just copying it and hoping for the best.

Another option if you just need more metadata slots for variant textures is to, like vanilla, just add a second Block for the second batch of variants. Look at BlockLog for an example - it has both BlockOldLog and BlockNewLog, each of which cover some of the log variants.

A "library" is really just a collection of classes / methods. An API can also be a collection of classes and methods, but with the intent that there are some, usually interfaces, that, if used, will provide some functionality with your mod. Think of vanilla Minecraft's IInventory interface - you can trust that any class implementing that interface has inventory-like functionality, and can therefore treat any such class as an inventory. You can retrieve or set the inventory contents, etc. It's a vanilla interface, but many mods use it because it implies a certain behavior. This is a type of API. Another type is the GameRegistry - you can add new Blocks and Items simply by extending the appropriate class and registering them to the GameRegistry. We are able to interact with Minecraft code in many such ways - this is the whole point of an Application Programming Interface, to be able to interact with a program via our own code. That's all it is. Whether you call it a library, an API, or anything else is really kind of irrelevant; what matters is how you intend whatever code you write to interact with others' code, and that should determine how you design it. Again, there is nothing special about it - you just write code and provide that to others with it stating "These classes / methods are part of my API which you can use to interact with X, Y, and Z when used in combination with my mod."

Actually, there is still an issue with it. The way it has been implemented prevents any changes in NBT from affecting the rendering of the item if you don't allow the re-equip animation to play. This would be resolved using my implementation, but I don't want to keep pestering Lex with issues (I opened one and immediately after saw his commit in the change log... doh). This issue is now closed. Many thanks to Lex for implementing this!

Here you go. Or here. Both near the top of the first page of Google results. Replace any reference to JRE with JDK, obviously.

This issue is now closed! Thanks Lex!

Ernio, I think in your example it would be better to just pass ('prefix_' + name) to your constructor as necessary with one single class, especially if you will only have one instance of each subclass. Also, if you are planning on only using a class once, you may want to consider anonymous classes. I often use them if, for example, I have a 'special case' within my class that could instead be handled by overriding a single (or sometimes two) method as an anonymous class, most often with Items. So instead of: public void someMethod() { if (this == MyItems.specialItem) { // do something special } else { // do something mundane } } I end up with: // original class: public void someMethod() { // do something mundane } // when instantiating my SpecialItem: specialItem = (new SomeItem() { @Override public void someMethod() { // do something special } }); // note: you don't technically need to surround your anonymous class declaration in parentheses, but you will need to // if you are going to chain any methods off of it, e.g. setUnlocalizedName, setCreativeTabs, or anything like that This summary, while a bit too concise, still sort of explains typical use cases for nested, inner, and anonymous classes, among other things.

The attack timing is handled in the AI class(es). Look there, and if you need to change it, you probably have to create your own AI class. IRangedMob is just an interface to allow the AI to call the ranged attack method on many different types of mobs without having to check 'is this one a skeleton? okay, it can attack. how about this one, is it a YourModArcher?' etc. Very basic design principle.