Draco18s

Gui textures don't work the same as block textures with the .meta file (it has nothing to do with 16x16: block textures absolutely must be square, so a non-square texture then must be a series of animated frames). Guis are rendered manually as quads drawn directly on the screen, so in order to animate it, you need to manually select different parts of a large texture, or change to a different texture, each time you draw the gui.

I don't see anything obviously wrong, but there's two things you don't need to do: 1) You don't need new Object[]{} 2) You don't need Character.valueOf('E') You can do it just like this instead: GameRegistry.addRecipe(new ItemStack(hasendna), "DDD", "DDD", "DDD", 'E', Items.egg, 'D', hasenbakterie ); Java has a feature called "varargs" which looks like this on a function: public static void addRecipe(ItemStack result, varargs...) Which wraps all of the other parameters in a new Object[]{} tag for you. Secondly, ' already denotes a character-literal, no need to wrap it in a ValueOf(). Third, with this particular recipe, you have made a recipe which uses only hasenbakterie, but have told the crafting manager that there's an egg in it somewhere (in fact, every other recipe you have does this). I don't know if this is what you intended or not.

public void onUpdate(ItemStack Stack, World world, Entity entity, int par4, boolean par5) { EntityPlayer Player = Minecraft.getMinecraft().thePlayer; What did you expect this to do on a server? Minecraft is a client side class only. Did you completely miss the third parameter?

Mhm. You should do it on both. Item stacks don't automagically delete themselves when their stack size is zero. Check for it and set them to null.

Post the code for crafttablethings.java

The reason they show up with .name at the end is that the default implementation of the unlocalized -> localized code takes the unlocalized string ("foo") adds "item." to the front (because it's an item, "block." if it's a block, etc.) and ".name" to the end. The ".name" is to distinguish it from any other usage, such as ".tooltip" or ".description" although Minecraft typically doesn't have those. You can see in my artifacts localization file that not everything ends in ".name", some of them don't even have a suffix, such as "time.seconds=seconds"

Imagine that your block checks in the following order: North, South, East, West. The first block looks below itself and goes "yup, I'm supported." The second block looks below itself and says "yup, I'm supported." The third block looks below itself and finds air, but it has support to one side, so it says "yup, I'm supported." The structure stays intact until a block anywhere finds that it is not supported and falls, every block it was supporting will now fall. Sorry about that, it was never written with the intent of being visible. All it does is loop through the 4 cardinal directions and check up to 6 blocks distant if there's a continuous line of support. Golf term: https://en.wikipedia.org/wiki/Golf_course#Fairway_and_rough Verb dogleg (intransitive) To bend in the shape of the hind leg of a dog, especially to turn and then turn back in original direction, such as down, right, down.

There's also Forge Inter-Mod Communciations, also known as IMC messages.

That's odd. It's fully documented on the wiki...

Ok, so. Step 1: Whatever method you are going to use, make sure that a block does not ask a neighbor if it is supported, because that neighbor will ask the first block if it is supported. Step 2: There's no need to go down more than 1 Y level. If that block is not actually supported, it will fall when it gets a block update. Note: Step 2 assumes that every block is made support-required, which includes TileEntity blocks, which actually can't be made to fall because of the TileEntity Step 3: What other shortcuts can you take? Here's what I did when I did this: https://gist.github.com/Draco18s/a1a5d65fe39b8fe85cab The third shortcut I took was to assume linear support only, no dog legs.

Its an interface, not a class, you can't instantiate it.

What are you trying to model? Are you trying to create some kind of block-support-physics?

Fixed that for you. Protip: If you want to do something like [X] go look at the code for [X]. It's almost like it'll tell you how to do it.

http://www.minecraftforge.net/forum/index.php?topic=22764.0

That's because all tools get 1 more use when they hit 0 durability.

Thanks for this great adivce but I want to use it in multiplayer and server-side only... Your reply to diesieben07 in no way contradicts what he told you. If you want to use Forge events, you need to write a Forge mod.

If you created a new Potion and it's brewable via PotionBrewEvent, then TADA, it has an item. Please re-ask your question using new words if that is not what you meant.

Having only just woken up, my psychic remote-viewing powers haven't warmed up yet. Mind including...I don't know, anything about where these files are located?

I have a mod and I want to make sure that my custom enchantment can be applied to axes, even mod added ones. How would I do that under your solution, sir?

Item doodad; registerRecipe(doodad, stick, string); //what is the value of doodad now? doodad = new ItemDoodad(); regosterItem(doodad, "doodad");

And your BlockState enum?

This really isn't a Forge question, but a Blender question. But it all has to do with the initial approximation. If you start with a bad approximation, then some of the faces will end up skewed or squashed.

By not returning null.

Yes you are, its in your post: int i =EntityRegistry.instance().findGlobalUniqueEntityId(); //GlobalID EntityRegistry.registerGlobalEntityID(RobotHelper.class,"robotHelper",i); //GlobalID Yes they do, use the registerModEntity overloaded function that takes two color parameters.