Draco18s

This reminds me of Risk Legacy. There's a packet labeled "Do not open. Ever."

Are you sure that largePowerCore is defined? Also, you don't need the new Object[]{} bit. The parameters of the recipes are declared as object... , meaning that it already comes in as an array. Oh, I know what the problem is. Here's one of mine GameRegistry.addRecipe(new ShapedOreRecipe(new ItemStack(BlockPedestal.instance,2), "ggg","g g","sss",'g', thinglass, 's', "stone"));

One, by not using TickEvent.ClientTickEvent as you should be checking server side. Two, by putting code into that function. (Oh, I'm sorry, did you mean to ask "how do I get a reference to the world here?" Well, if you're using the right tick type, you should be passed a reference to the player, which as an entity, contains a reference to the world)

Do instead if (block == null || block.material == Material.air) The first one checks to make sure the block isn't null (to avoid null reference errors) the second check checks to see if the block that is there is of the material air, because with mods there can be blocks that should be treated like air, but are not air. (Gasses, technical lighting blocks, etc.)

Packets are not that hard.

Kinda. Yeah...

World#setBlock(x, y, z, 0, 0, 2) ?

Yes. readFromNBT and writeToNBT are public functions even if the NBT tag itself is not. There is nothing stopping you from creating an NBT tag, passing it to the write function, then adding your own data, and passing it back to the read function.

Ok, but that doesn't tell us what's failing.

And this is where we do things like System.out.println(helmet.getItem() == FireArmorBaseFile.FireHelmet) And see what its doing.

Also know when you've coded yourself into a corner. Even if it works, but the way you've done it you've had to make sacrifices due to some assumption here or how you set your data up over there. In the little project I did over the last few days I got to a spot where it's not viable to keep working because my data structures won't support it. In order to do something simple like locate a topological feature I have to iterate through one of four different arrays and compare datapoints with at least one of the other remaining three. i.e. I have an array that holds vertex locations. I have another array that holds triangles (that references indices in the vertex array). I then have yet another array that holds the edges of those triangles (because the triangle array wasn't set up to be useful for the next step of what I was doing). I then have an array of objects that exist visually, which are related to the vertex array. In order to draw a series of lines between my objects I need to find which object I want to draw from, and to, then locate the relevant edge in the edge array. If it exists (as not every object is connected to every other object). So I need to scrap everything I have, use what I learned, and find a single cohesive way of storing the data so I can reference and modify it in the various ways I need to.

If you're going to do stuff with power systems, you're really going to need to know how to program efficiently. That whole Big-O notation thing.

https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/ClientProxy.java

You don't have to do that, you know. Check out how I did item renders for TESR blocks. https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/ClientProxy.java

Did you register the renderer in your client proxy?

You mean like migrating to a new URL? Your login is valid on the new tracker if you had one on the old.

You are a lazy bastard indeed.

I also pass a new TileEntity to my renderer.

Report it to Mojang. I've reported things I've found in the code before (like why walking on slabs over ice is like walking on ice, it has to do with the fact that the entity position is floored, then subtracts 1 to determine what block you're walking on).

See: https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/client/ClientProxy.java

The blocks that code destroys is based on the blocks that (pickaxe of same material) will destroy. Doesn't matter where they are in relation or what block was originally broken.

Check this out: https://github.com/Draco18s/Artifacts/blob/master/draco18s/artifacts/components/ComponentExcavation.java That's how I achieved it. It does a 3x3x3 cube, simply for the simplistic nature of being easy to calculate.

Uh. You have to add those yourself, last I checked.

And now you have found the problem.

Print out the block ID at that location.