Draco18s

This is the first time someone has ever said I'm doing it wrong.

YOU are defining the states. It's some property of the entity you're displaying information for.

@Override public Packet getDescriptionPacket() { NBTTagCompound nbtTag = new NBTTagCompound(); this.writeToNBT(nbtTag); return new S35PacketUpdateTileEntity(this.xCoord, this.yCoord, this.zCoord, 1, nbtTag); } @Override public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) { readFromNBT(packet.func_148857_g()); } Note, I don't know if any of the names have changed in 1.8, but you need those functions otherwise the client doesn't know jack about the variables you're trying to use.

Exactly the same as you would for drawing the progress bar on a furnace, only the size isn't changing, just the uv coordinates based on your state.

Yes. drawModalRect

Kind of without Internet at the moment, but I'll try and remember when I get home again.

Not sure what you are saying here. But if it means that try-catch is slow, that's not true either. Try-catch is basically free. Unless an exception actually happens, which is then quite slow, but that's ok, since it's an exception, meaning it's exceptional that it happens. False. I had code wrapped in try...catch (a method.invoke call) in a block-update function (ASM injection). It ran so hilariously slow as to take 10 seconds for water to flow 1 block But /forge tps still reported 20 ticks a second. Removing the try...catch fixed it. The only reason i could remove the try...catch was because the calling method was ASMed and the compiler couldn't complain about the unhandled exception involved.

As opposed to player.OpenGUI(...) ?

Seriously? public boolean onBlockActivated(World world, int x, int y, int z, EntityPlayer player, int x2, float x3, float y3, float z3) { Minecraft.getMinecraft().displayGuiScreen(new GuiOven(Minecraft.getMinecraft().thePlayer.inventory, new OvenTileEntity())); return true; } Your given a fucking player and then call client only functions in common code.

Tough. Because that's what you're trying to do.

https://www.google.com/#safe=off&q=how+to+write+a+compiler+for+a+trivial+language

if(pos == null) { use_a_default } else { current_code }

The fuck do you think an ItemStack is? It's a stack of items. Look at its gorram fields and methods.

Note: Reflection is slow. And I don't mean in a "don't do it much" kind of way, I mean in a "don't do it in the onUpdate of any object" way. While I don't think the following description is technically accurate, but it might explain the problem conceptually: Try...catch spawns a thread and waits for it to either crash (catching the exception) or finish executing.

Which, if you look at it, is just a wrapper function for world.setBlock(x, y, z, Blocks.air, 3)

if(some_value == something) { //bind texture 1 } else { //bind texture 2 } Now then, here's your code. if(tileEntity instanceof TileEntityEnergizer){ //this should be true TileEntityEnergizer energizer = (TileEntityEnergizer)tileEntity; LogHelper.info(energizer.getMultiplier()); //lets just not do anything useful with this value image = new ResourceLocation(Reference.MODID + ":textures/blocks/energizer.png"); //bind texture 1 } else{ //this will never happen image = new ResourceLocation(Reference.MODID + ":textures/blocks/energizer.png"); //bind texture 2 }

1 + 2 = ? 2 + 4 = ?

That doesn't explain why you need an EntityPlayer reference at all.

You didn't get my point. It's not me who defines func_aaa_b. Correct. They're SRG names. And the way SRG works is that they are 100% identical between different versions of Forge and usually the same across versions of Minecraft (a major rewrite of a class can throw that out the window though). But your point doesn't make any sense because we don't know where you're trying to get to and where you are coming from. What version of Minecraft (and Forge) is A, what version of Minecraft (and Forge) is B, etc? It doesn't help that you say you want to translate func_aaa_b to something, but can't because it's not func_aaa_b.

Quick interjection: The FMLinit events give you a logger. event.getModLog() if I recall correctly. Just save a reference to that in your main class.

Better idea: Rather than counting a timer in your NBT, save a worldTime plus your delay, and wait for the world's time to exceed the time you saved in the NBT.

Block.getBlockFromItem

How about you show us code where you save that variable to the NBT and read it back out again.

You do know I have not added any number to NBT yet, right? You do know that if you don't, your code is going to do fucknothing, right?

I've known about it for a while, I just haven't linked it very often. So yeah, the other day might've been the first time I used it here.