Draco18s

show also your readFromNBT function.

My guess is that he wants that data to track his collapse physics, that is, how far away a given block is from downward support. Which is functionally equivalent to turning the whole world into redstone. It's not the space-efficiency that's the issue, its the management.

Dev environment: running in Eclipse. After compiled: using the Minecraft launcher. "in the game" is a useless distinction. Where else would you be?

Seriously? Of course it needs to be something specific.

1) http://www.minecraftforge.net/forum/index.php/topic,29341.0.html 2) Subscript to the LivingDropsEvent or the BlockHarvestEvent 3) Yeah, no. You're not going to manage that in anything less than a mess.

Because he didn't wrap it in a [nobbc] [/nobbc] tag, the [nobbc][i][/nobbc] got dropped.

At what point were you planning on adding nbttaglist to tag ?

...No, no you did not. You referenced your KeyInputHandler in your main mod file.

Call manually? No.* Implement? Yes. *Note: There are some functions that are helpful to call manually in certain circumstances, but not technically required. Whenever your TE's data changes (item is added/removed, etc.) if (worldObj != null) { worldObj.markBlockForUpdate(xCoord, yCoord, zCoord); //tells the server that the client needs an update } markDirty(); //tells the server that a change that will require saving has occurred.

ItemStack has a writeToNBT method, which returns NBT, which is savable into NBT. Here's how it's usually done. @Override public void readFromNBT(NBTTagCompound tc) { super.readFromNBT(tc); NBTTagList nbttaglist = tc.getTagList("Items", 10); inventory = new ItemStack[getSizeInventory()]; for (int i = 0; i < nbttaglist.tagCount(); ++i) { NBTTagCompound nbttagcompound1 = nbttaglist.getCompoundTagAt(i); int j = nbttagcompound1.getByte("Slot") & 255; if (j >= 0 && j < inventory.length) { inventory[j] = ItemStack.loadItemStackFromNBT(nbttagcompound1); } } } @Override public void writeToNBT(NBTTagCompound tc) { super.writeToNBT(tc); NBTTagList nbttaglist = new NBTTagList(); for (int i = 0; i < inventory.length; ++i) { if (inventory[i] != null) { NBTTagCompound nbttagcompound1 = new NBTTagCompound(); nbttagcompound1.setByte("Slot", (byte)i); inventory[i].writeToNBT(nbttagcompound1); nbttaglist.appendTag(nbttagcompound1); } } }

Oh. Nice. And your code?

No, bad! You should never directly reference your ClientProxy file. That breaks the whole point of proxies.

You will have to implement the read/write to/from NBT methods as well. NBT isn't hard, just take the nbt and use the getInt or setInt functions (or other types as needed). You can save any primitive type inside NBT, as well as other NBT tags.

Its not pointless. It's so that he can change a single string instance and have it update across all usage. Just that for unlocalized names and file references...you'd then have to update your lang file and file name. If you really want to rename the block...its not that difficult. The problem is that the way he does it is not newbie friendly. A fresh hand at modding will see the line and go "ooh magic code..." and not understand what it does so when things go unexpected, they don't understand why. "I told it to use texture name 'sulfur,' it's looking for minecraft:sulfur and can't find it" is a lot easier to solve when you realize you didn't specify your mod-ID. There's a cause-effect relationship rather than four lines of gibberish.

And why would you NOT save those variables to NBT? Do you want them to get reset when you save and exit?

Because you're still calling that class from common code. Proxy that shit.

Metadata didn't suddenly allow for more than 16 because 1.8 happened. It's still 16, but that other types of states can exist as well, such as ones being inferred based on neighboring blocks or TileEntity data. getMetaFromBlockState can not return a value greater than 15. Ever.

No, Pahimar overcomplicated it in an attempt to use two strings for fuckeverything. Rather than doing it in a straightforward way that was easy to understand. setUnlocalizedName("myThing"); setTextureName("myThingsTexture"); But no, he had to override getUnlocalizedName so that it would strip out the extra copy of the modID, then add it back in differently for texture registration... It's so bad that nearly all the veterans around here recognize his work on sight.

Oh god. I've seen this code before. And it's a terrible, terrible way to do it. Long story short: you're stripping your mod ID from your item's unlocalized name in order to register the texture name, which needs your mod ID.

And...your json?

TileEntities already have packet communication built into them. @Override public Packet getDescriptionPacket() { NBTTagCompound nbtTag = new NBTTagCompound(); writeToNBT(nbtTag); return new S35PacketUpdateTileEntity(xCoord, yCoord, zCoord, 1, nbtTag); } @Override public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) { readFromNBT(packet.func_148857_g()); }

Code?

You should really ask on their forums or IRC channel. IC2, by the way, has an API that is very easy to find and use.

That returns the list of IRecipe objects (which he already figured out), not their ingredients.

Multiply their grayscale texture by the color black? 0 times anything is 0.