Draco18s

Holy shit balls what the fuck. Is your main mod file seriously the common proxy? No, bad code monkey, no banana.

It's like registering a block. Except instead of a block, its a TE.

You want two things: 1) @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()); } 2) Whenever the inventory changes if (worldObj != null) worldObj.markBlockForUpdate(xCoord, yCoord, zCoord);

You can get it from the ItemStack, yes.

First one: GameRegistry.registerTileEntity

@Override public void onLivingUpdate() //this function is both client and server { super.onLivingUpdate(); spawnParticle(); //this function is @SideOnly(Side.CLIENT)

Basically, you need this in your item class: Note: this is for my mod and one of the meta's outright doesn't exist and several only exist if IC2 is loaded. Or would, if IC2 didn't handle them. I've got them in here as I have several items that all use the same metadata numbers (itemA:3 is the same material as itemB:3 and itemC:3, even if itemB:3 is illogical and not used). @SideOnly(Side.CLIENT) public void getSubItems(Item item, CreativeTabs tab, List list) { list.add(new ItemStack(item, 1, 0)); list.add(new ItemStack(item, 1, 1)); //list.add(new ItemStack(item, 1, 2)); list.add(new ItemStack(item, 1, 3)); list.add(new ItemStack(item, 1, 4)); /*if(Loader.isModLoaded("IC2")){ list.add(new ItemStack(item, 1, 6)); list.add(new ItemStack(item, 1, 7)); list.add(new ItemStack(item, 1, ); list.add(new ItemStack(item, 1, 9)); }*/ } Then you need the names, so you can localize them: public String getUnlocalizedName(ItemStack stack) { switch(stack.getItemDamage()) { case 0: return "item.small_iron_dust"; case 1: return "item.small_gold_dust"; case 2: return "item.small_diamond_dust";//non-existent. placeholder to match metadata across several items case 3: return "item.small_flour_dust"; case 4: return "item.small_sugar_dust"; case 5: return "item.small_limonite_dust";//non-existent. placeholder to match metadata across several items case 6: return "item.small_tin_dust";//implemented by IC2, placeholder case 7: return "item.small_copper_dust";//implemented by IC2, placeholder case 8: return "item.small_lead_dust";//implemented by IC2, placeholder case 9: return "item.small_uranium_dust";//implemented by IC2, placeholder } return "item.small_dust"; //Just in case, return something }

I don't know what Forge Multipart implements by itself beyond the torches, but the point is that it allows multiple sub-blocks to occupy the same space. For example, carpet and fence. I had a need for something like it recently, but I didn't use Forge Multipart, as I didn't need "[any][any]" but "snow[plant]: http://s7.postimg.org/i82vo7f4b/2015_01_24_21_21_15.png[/img] It also does webs (top right) as they use the same renderer (crossed squares). I render the tile entity manually, first by calling renderer.renderBlockByRenderType(Blocks.snow_layer, x, y, z); and then using the code from renderer.renderCrossedSquares(...)[/code] that I actually need (with a substitution to get the block render color so that grass is multiplied and other blocks are not), which finishes with a call to renderer.drawCrossedSquares(...);

That one still gets me every time. It's dye with a metadata of 15

Forge Multipart kind of allows partial block objects to occupy the same space. But it has to do it using tile entities. So it has some limitations, eg. you can't run redstone over carpet. But you can put five torches in the same 1x1x1 space, etc.

There's also the OreDictionary. For example here's one of my recipes: GameRegistry.addRecipe(new ShapedOreRecipe(new ItemStack(blockmill,9), true, new Object[] {"SSS","SWS","SSS", 'S', "stone", 'W', "logWood"})); Lets me use ANY log registered with the oredict as well as any stone.

Likely you need these two functions: @Override public void readFromNBT(NBTTagCompound tc) { super.readFromNBT(tc); //load your variables } @Override public void writeToNBT(NBTTagCompound tc) { super.writeToNBT(tc); //save your variables }

There's like, five energy systems now. IC2, RedPower, BuildCraft, RestoneFlux, RotaryCraft's torque... Just import Universal Electricity and use that. There's literally no need to reinvent the wheel.

The function's called in the parent class anyway. Overriding it isn't going to harm cpu usage, just check for the material and do nothing if its the wrong material. It'll cost like 6 bytecode instructions, which in the grand scheme of things, is nothing.

No. You create a NEW class that is your key event handler. You then have to do all the networking stuff, which is likely going to involve (at a minimum) two more classes, IIRC: the packet itself and the packet handler.

Sure you can. Only the last one in the stack matters if you don't call super.

Well, it's not, if you use getTextureName() instead of getUnlocalizedName() , like you should.

1.8 don't have "renderParticle" anymore.. Well shucks.

When I poked at custom particles last, I had to manually bind a new texture (and then rebind the vanilla one). https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/client/AntibuilderParticle.java#L59

The default implementation of registerBlockIcons registers ONE texture. If you want to register more than one, you have to override it and do it yourself. No, metadata does not imply multi-texture. On the other hand multitexture does imply metadata block. (Albeit you can have more than one texture on a block, but only one texture per face. So I'm calling that a single-texture block, unlike wool which has 16 textures and displays one at at time on all faces).

setHarvestLevel("tool", level);

It's a vector...

cpw.mods.fml.common.MissingModsException You're missing a mod. One of your installed mods has a parent mod that is not installed. Install it.

To put it simply: Find the method involved, insert an INVOKE call to a class you control, and handle it there. For example, here is where I'm inserting a call inside EntityAnimal#func_146082_f and handling it here, so I can interrupt animals going into love mode only when the player feeds them (I have an AI task that causes it to happen at random intervals as well and I don't want to cancel those). The inserted call only fires off an event, which is handled elsewhere. ASM is a right pain and will likely drive you insane, but sometimes its the only way to do what you need. Oh, and this class may be helpful. shieldbug1 originally wrote it. I've modified it a bit to help figure out what stuff is and does; line 255 should be commented prior to releasing due to unintelligent detection of programmer errors (that is: if looking for an overloaded function, it will spit out output even if a valid method is located, but it did help me find typos). Note: repository is out of date and is not 100% functional, but should provide at least a baseline for good ASM.

You should never need to call readFromNBT or writeToNBT yourself. Remember that a TileEntity has a block in the world, and if you know how to make a block change its light value, you do the same thing for TileEntities.