Draco18s

I saw that and looked everywhere and couldn't find a second register. I also have no idea how to search in my IDE. I haven't used eclipse in forever. Try using the search menu.

world.setBlockState (pos, state, flag); //flag = 2 if you don't want neighbor updates

That will require a lot of work with ASM, as vanilla doesn't have a concept of gravity. It knows about downward acceleration and whether or not an entity needs it (aka "grounded").

That behavior is built in to vanilla so you actually CAN place blocks against the sides of containers.

Oh, that's because you're trying to register your recipes when the class loads and before Vanilla has defined its items. Items.bread is null (and so are your mod items).

Simply put, all you need is a TileEntity class that your block (as a BlockContainer) provides.* Take a look at Vanilla's furnace. Don't worry about how it knows what a recipe is at the moment, you're only concerned with turning your Ore into your Metal (or whatever you want to call it). So if you mentally replace any reference to the FurnaceRecipes class, you should be able to figure out how much of it works. *You don't have to extend BlockContainer to get a TE, but as you're doing a block that contains items, this is the best/fastest option.

Technically speaking, more code is not slower code. If there's a fast way to check that something may be true (i.e. if the fast check returns a statement that provides false positives, but not false negatives, or vice versa), then if that's false, you can skip a more expensive check, its better than if you didn't check. For multiblock, you shouldn't be doing checks in onUpdate anyway: the world didn't change unless you got a neighbor block update check. Which you can then fast-check the changed block (not one of the multiblock items? No need to check for the whole structure).

I'm not sure about the crash, but: keyBeingChecked.get(0) == list.get(0) That will never return true. ItemStacks don't override the == opperator, and even .equals() is kind of iffy.

Security camera and tvs. He wants a rendered texture on a block.

These lines you have posted are informative. Your game is crashing. You should change something so it doesn't do that. You could try pastebin or gist.

The first one is fairly straight forward, but probably beyond your skill level. The code that holds the painting IDs is called EnumPainting (IIRC). You'd essentially have to insert new values describing the new painting. The latter is far far more complicated of a question and requires manipulating the player's camera.

Pick one, it won't matter in 90% of cases.

Try starting here.

Yes. Although I recommend trying to puzzle the problem out yourself first.

Its super mega hacky.

...you can save it...

Modern JVMs love short-lived objects. The young generation (newly created objects) garbage collectors are very efficient at getting rid of objects, so it might even be faster (because you get less cache-misses) to use a new object every time. In the end both have probably comparable performance and it doesn't matter. Cool. Its one of the things I never turned into a property because it was something that was never referenced for any reason except by that interface, so I felt no need to "save it for later." (More expensive stuff, like Reflected objects, absolutely, but simple objects? na). It has to be an array: public static final int[] fuel = {2};

The FMLInitialization events should also register and pass off a logger to you. Or at least they do in 1.7.10 and I see no reason why that would have changed.

EventName.SubEventName Eg EventChunkData.Load

ItemStack[] inventory = new ItemStack[3]; //0 is 0, 1 is 1, 2 is 2

Out of curiosity, what's the performance difference between keeping them as constants versus returning new int[]{0} every time where is needed?

Show the code for the isOffCooldown(...) method. We need to know why you need access to a World there. As well as why that function is calling getCooldown(...) Notably, because isOffCooldown is calling getCooldown, you could just add a World param to getCooldown and then pass it, then badabing, you have your world object (but still have an infinite loop).

World (or an entity) is passed to most Item methods, the rest have no need.

onLivingUpdate doesn't need to pass the World as a parameter because Entities have a World property that is accessible all the time, this.worldObj.

Uh. Neither 9minecraft nor minecrafteo are "good sites."