Elyon

The indentation issues when pasting arise from using mixed tabs and spaces. You ought to set your editor to enforce one over the other - you will probably want to replace one with the other before pasting, as well, unless your editor allows automatic conversion. Personally I use spaces - that way I am sure other people will have the intended indentation size when reading my code in their editor. If you want, I can look over your code once we fix the overloaded-issue and give you some hints as to improvements for your code, both regarding readability and performance? Just a friendly offer Oh, and if you could update the gist with fixed indentation before I delve into it to try and find the issue you're having, that would be wonderful

When you see errors like these, you may want to have a look at the classes you are actually inheriting/using. There doesn't seem to be an explicit constructor for Item , so just use super(); . As for the TeleportCrystalClass() constructor ... You have written that class yourself, so we can't tell you what the constructor signature is. Whatever arguments your defined constructor/s take, that is what you need to supply it with when you call it. On a side note ... TitleCase is usually reserved for classes and similar, camelCase is for variables and fields, and lowercase is - I believe - generally preferred for unlocalised names. Having Class appended to every class seems a tad redundant and repetitive, no? May I suggest you rename your TeleportCrystal field to teleportCrystal , and your TeleportCrystalClass to TeleportCrystal ? It would probably end up saving you a lot of grief in the long run if you stay consistent to the Minecraft/Forge identifier naming conventions

Could you please paste the class to http://paste.minecraftforge.net/ (which is http://gist.github.com/) instead? It is very difficult to read your code with messed up indentation and without syntax highlighting and line numbers I see a lot of identical calls in there that could (and should) have their result saved to a local variable instead. Also, you may want to look into the keyword switch The use of both could pretty effectively make your code more performant and concise, thereby making future modifications less difficult and error-prone.

Your tasks seem fine. Are you overwriting any methods in the EntityBlockling class? How many Blocklings do you have spawned?

I assume Blocklings use the new AI? How many Blocklings are you loading, what is their detection/pathfinding range, and is there anything else about them that might cause the behaviour of the new AI to take up a large amount of resources?

As the field is private, and you are probably hopefully inheriting from ItemFood rather than replacing it (because that would be silly) or editing it (also silly), you will want to use the setter method setAlwaysEdible . I suppose you just either chain it in your initialisation, or call it in your constructor. As it doesn't take any arguments (the method simply sets the private field to true ), it is simply a matter of calling it: setAlwaysEdible(); As for changing the item use duration (I presume you want to change the time it takes to consume), simply @Override the getMaxItemUseDuration : @Override public int getMaxItemUseDuration(ItemStack itemStack) { return 16; } This should make it consumable in half the time other consumables are consumed in the game.

You should be able to call the method from your Block constructor, or chain it where you initialise the Block. For example, this is how you would set your Block to only be harvestable using an Iron Pickaxe or better: setHarvestLevel("pickaxe", 2); I hope you can make it work

Have a look at setHarvestLevel(String toolClass, int level, int metadata) in Block.java.

If you are inheriting from RenderLiving , you will probably need to @Override the doRender method. Something simple should suffice, along these lines perhaps?: @Override public void doRender(EntityLiving entityLiving, double x, double y, double z, float a, float b) { BossStatus.setBossStatus((IBossDisplayData)entityLiving, true); super.doRender(entityLiving, x, y, z, a, b); } Bear in mind that this exact code probably will not work as it is, but this is at least where I would start. I could be completely wrong, but that seems to be how the Wither does it (Oh, and I don't know what a and b are - maybe pitch/yaw?)

I have no experience with adding bosses, but are you implementing IBossDisplayData in your Entity class, and calling BossStatus.setBossStatus in the doRender method of your Render class? Some code snippets would be helpful, as well

I did that. This is my new initialisation: public static Block chocolateOldLeafBlock = new BlockChocolateOldLeaf().setBlockName("leaves").setBlockTextureName("minecraft:leaves"); Thank you for the input, though

I am not registering the block, just replacing the vanilla block. I figure I need to call setBlockTextureName("minecraft:leaves") , but doing so yields exactly the same result.

Follow this thread, it seems to have the same need as you do

This should be the mod code in its entirety. BlockReplaceHelper (using ReflectionHelper ) is what I am currently doing to replace Blocks.leaves .

I replace Blocks.leaves through reflection. When simply registering the block through the GameRegistry , it works - I guess there is an issue with the way I reflect, then? The very same approach worked for the furnace, though, so I don't know. I initialise the new block statically in my main mod class, but perhaps the registerBlockIcons method of BlockOldLeaf is called after the replacement has taken place? This still doesn't explain why it would work with the furnace ... but they are very different blocks indeed.

"forge/build/tmp/recompSrc/net/minecraft". These are not plain vanilla source files, to my knowledge, though. Anyway, enjoy

Keep in mind recipes relying on the vanilla pumpkin pie would not be able to use your pumpkin pie instead, unless you specifically replace it. Things have changed from the version Thaumcraft 4 supports (which is 1.7.2, I believe). It would probably not help much, no. Reflection seems to be the way to go for now. The relevant issue had a reply with a link to a library of helper methods easing the replacement of vanilla blocks and items, but that link (and indeed the comment itself) has been deleted. Nevertheless, I might be able to provide some insight into using reflection for replacing a vanilla item, if I can find the time. Again, though, you probably don't want to toy with vanilla replacement if you can avoid it. Here is a thread detailing how to remove recipes in [1.7.2] - it might work for [1.7.10] as well. Removing the vanilla recipe, and registering a new identical recipe where the output is your custom pumpkin pie would give you full control of the pumpkin pie, while retaining the vanilla recipe. As said, however, any mods relying on the pumpkin pie as recipe input will not be able to use your replacement in this case.

I have a barebones descendant of BlockOldLeaf . As with my descendant of BlockFurnace , I have left the icon registry (and much everything else) up to the parent class. This does not work for BlockOldLeaf , however. While the block works well within the game world, as soon as I try rendering it as an item (by opening the Decorations Creative tab or "picking" the leaves), the game crashes from a NullPointerException : BlockChocolateOldLeaf.java package net.elyon.chocolate; import net.minecraft.block.BlockOldLeaf; public class BlockChocolateOldLeaf extends BlockOldLeaf { public BlockChocolateOldLeaf() { super(); } } Relevant stacktrace Digging through BlockOldLeaf.java, specifically the getIcon method, I see it relies on the static field field_150130_N , which is declared and initialised in the same class. I cannot figure out why my barebones BlockOldLeaf replacement throws a NullReferenceException in the getIcon method.

Look into Java reflection. I have done it for blocks, not items, and even then I didn't understand fully what I was doing at the time. I would not recommend replacing vanilla blocks/items if you are new to modding or Java in general.

There is no code specific to the pumpkin pie, it is merely a generic ItemFood . I guess you would want to create a new class/item inheriting from ItemFood, if you don't mind your pie being differentiated from the pumpkin pie. If you want to replace the vanilla pumpkin pie with your throwable pie, that is a bit more involved, and there are several possible courses of action.

Odd. The indents should have carried over when you pasted. That code is much more readable, indeed

Heh, by your code style being "interesting", I was referring to the general lack of indentation, as well as the inconsistency and inadherence to established standards for your identifiers. I am happy you were able to solve the issue. Logs are often the best place to start looking

Welcome! Your code style is ... interesting But first things first. Do your blocks show up in your Creative tab? Are there any other things that are not as they should be, to your knowledge? Are there any hints in the logs?

We will not write your code for you. Your best bet is to give it an honest try, and if that doesn't work, we will be happy to help you out with any issues your code might have. Also, http://www.minecraftforge.net/wiki/Key_Binding seems to do what you want.

I had the same issue. I had to create a new empty folder outside the forge folder (I renamed the forge folder to <modname>-files, and named the new folder <modname>). Set the new empty folder as your workspace, and import the real project into that in Eclipse. This seems relevant, although it is not the guide I used - I cannot seem to find that one