Draco18s

You are running client only code on the server. This is why we have proxies

Where do you call new , where do you call GameRegistry.registerItem , when do these occur relative to MCraft() ?

You would need fake light emitting blocks. I don't recommend it. Trying to clean them up correctly when placing/removing multiple light sources in near proximity would be problematic.

You don't need the whole new Object[] {} syntax, as Java's varargs feature is syntactic sugar that does it for you. But you still haven't addressed what I said was wrong. Or shown otherwise.

Neither. Use World#isRemote , specifically, !isRemote

Your items are null.

Ya know what's great? Crash logs. $20 says that you tried to register the crafting recipes before you initialized the items.

What.

You need a way to make the player fly. Probably by doing something every tick while the armor is worn.

So should I just get rid of all the code that is in both? If it references a class that only exists on the client, it goes in the client proxy. If it does not, it goes in the common proxy.

You would need to use metadata and an ISimpleBlockRenderingHandler

I'll note that the only reason I did that was because the ore was easy to find and crap late game. The player shouldn't want to set up the industry to smelt the stuff into usable metal. It was only there to provide a metal resource in small quantities.

Your common proxy contains client-side code. Not why the game won't load, but its still a problem.

You need to also set the block to not being opaque.

Notice how that image is not a single cuboid, its three. setBlockBounds() will only handle a single cuboid.

Except that it won't work like that. Imagine a corner piece. You can't set any cuboid boundaries that result in an L shape.

My code above was for 1.7.10 and was for a very simple machine. CoolAlias's tutorials are extra generic and cover how to go about working with an API of any sort, looks like 1.7.10 though. The only thing to be aware of when programming for an API is what to do if the API is not present, ie. if someone does not have NEI installed. For something like NEI, this is easy: wrap your NEI API calls in a separate class and only call methods in that class if NEI is loaded. For other things, like when a block or item needs to implement some API interface, but you still want that item to work when the API isn't available, you need to use the @Optional annotations, found in the cpw.mods.fml.common package ( import cpw.mods.fml.common; ). @Optional is essentially (a flag for) some wicked clever ASM that strips out interfaces and/or methods if the target mod isn't installed (as not stripping them out would cause ClassNotFound errors). Lets you have TileEntities which extend IEnergyProvider from [tech mod here] and IGenerator from [some other tech mod] and work with either but require none, instead using your own blocks. Here's an example: public class IndustryEventHandler { @SubscribeEvent public void onCrafting(PlayerEvent.ItemCraftedEvent event) { //standard event method } @SubscribeEvent @Optional.Method(modid = "HardLib") public void itemFrameCompare(ItemFrameComparatorPowerEvent event) { if(event.stack == null || !(event.entity instanceof EntityItemFrame) || event.power > 0) return; event.power = ((EntityItemFrame)event.entity).getRotation()*2+1; } } The itemFrameCompare method has an event object of type ItemFrameComparatorPowerEvent which I had added to my own core library, but the mod this is in has no other dependencies, so it was not set up to actually depend on that library. So rather than go "surprise, you need my library" I marked it as optional. The feature won't work without the library, but there was no reason to enforce the dependency for such a trivial feature. (This event/method adds the ItemFrame Comparator function present in 1.8 to 1.7.10 in order to meet the demands of a requested feature in one of my other mods, the general-purpose orientation code was easy to write and fit in with this particular mod).

I kind of think that he's actually replacing the block with his own block, which has a tile entity. He wants to know how to store the original so it can be rendered. The answer to that is: store the original in the TE and reference it during rendering.

(That process is important, as meta:0 for infinite fluids is a source block, but meta:0 for finite fluids is none!)

I haven't looked, but pretty sure that the vanilla workbench has it hardcoded to only use one of each. There are custom IRecipe implementations, but while you could make the output not show up unless 3 of the item were in a stack, I don't think it would actually use all three. Here's what my block does, it's very single-purpose, pro-automation. http://reasonable-realism.wikia.com/wiki/Sifter The stack-of-eight is actually an efficiency improvement over the workbench crafting recipe (uses 9). (And the second input slot is just a buffer area, like the hopper)

Good job not reading the original post.

Probably because the block's functionality should persist after the player quits the game.

You would need to write your own crafting bench and your own recipes. I have a machine that takes in stacks of size 8 and produces a single-size result, for example.

You still don't need MAP.flush() You may as well think of it as MAP.garbageCollect(), the method exists to mark the memory it uses as free, but you're using it to reset the colors.

Your UVs are incorrect.