Draco18s

That is precisely what's happening. It's called z-fighting. Most mods avoid this problem by not using vanilla blocks in their structures. Your best bet is to create an invisible (but solid) block that replaces the redstone (or whatever) so that the original block doesn't render. But when broken, it drops the original and kills the multiblock.

I don't think they're is one. As for events, there aren't any. There is just a handful of method calls, all of which I think 2 or 3 are important (i.e. The rest can be ignored and you'll still have a working coremod). The hard part will be writing the bytecode to dip what you want. And there will be no audible tutorial of the JVM.

Let me Google that for you. You want the first result.

Its a system that allows moss to communicate or intact through procedures more complex than the FML Message system allows for.

No.

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