Draco18s

That depends entirely on what it is you are trying to do. Clarify your idea. But I'm not writing the code for you (not unless you want to pay me).

It's funny what you find looking at the ServerConfigurationManager class. MinecraftServer.getServer().getConfigurationManager().transferEntityToWorld(entity, dimID, oldWorld, newWorld, teleporter) If you need a WorldServer object for those two parameters, DimensionManager.getWorld(id)

Question: Why is this line here? MinecraftForge.EVENT_BUS.register(this); Your main mod is not, and should not be, an event handler. Yes, it has @EventHandler annotations, but the event bus looks for @SubscribeEvent (which you do not have), so why are you trying to subscribe your main class to the event bus?

Yes, you can supply a slot that corresponds to another container.

If you have no slots in your GUI, how are you displaying a chest in a slot? http://imgs.xkcd.com/comics/well_2.png[/img]

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?