Jwosty

You'll need to use block metadata to keep track of the orientation that the player places the block in, and you can use a method that pistons use to determine block facing: @Override public void onBlockPlacedBy(World world, int x, int y, int z, EntityLivingBase entity, ItemStack itemStack) { // no need to figure out the right orientation again when the piston block can do it for us int direction = BlockPistonBase.determineOrientation(world, x, y, z, entity); world.setBlockMetadataWithNotify(x, y, z, direction, 2); } @SideOnly(Side.CLIENT) @Override public IIcon getIcon(IBlockAccess world, int x, int y, int z, int side) { return (side == world.getBlockMetadata(x, y, z)) ? this.frontIcon : this.blockIcon; } Note that you'll need to define a field "frontIcon" that contains the IIcon of the texture you want to draw on the front.

It should be the same code that you use for a normal GUI. I'm too lazy to post a code example, but this is what it looks like if you haven't done GUIs before.

I say its fine if we help him through this, as long as we don't give him code directly. He will at least learn something that way.

That's one hell of a stacktrace. It looks like your call to world.canBlockSeeTheSky is causing problems and somehow calls your generate function again, which calls world.canBlockSeeTheSky ... And so on. I suggest simply getting rid of it. Also, do you really mean to say "if block exists OR block is exposed to the sky"? Or do you mean AND?

Well, what are you trying to use this for, ultimately? If you change the item to a random one, then it will most likely end up being a vanilla item. And then you wouldn't be able to change it again from Item#onItemRightClick. You could probably create a custom item that simply takes the texture of another item, changing that item randomly each time it is used.

Two sets of 3x3? What do you mean? Anyway, you should just be able to adapt the code you have -- it will probably just be another set of for loops. Or two calls to destroyBlock in the single set of for loops.

Send a chat packet (C01PacketChatMessage in 1.7). I don't remember what it's called in 1.6; but you can search for it in Eclipse with Navigate > Open Type and searching *Chat

An interesting game mechanic would be to require the player to take some sort of action multiple times to regenerate the block.

I don't think that world gen changed in 1.7. Go ahead and try the existing tutorials and if you get a problem, come back with it! :)

Hmm, that will be a bit trickier... You could iterate down to find the bottom block (a log block on top of dirt) and place your custom block there. Then, when you want to spawn the tree, there's got to be some method you can call to do this for you; just look at the sapling code.

Look around in the vanilla code to find exactly how it finds the block to interact with. I would set a breakpoint inside some block's onBlockActivated or onBlockPlaced methods, then proceeding to step out and see what it calls.

What you're thinking should work just fine, although you'll need a tile entity to handle the update; plain blocks only update when a neighbor is changed.

I think you want onEntityCollided, not onEntityWalking. The former is called when an entity passes inside a block, while I assume that the latter is only called when an entity is above it (?). In any case, you can walk inside fluids.

Ah, normalized vectors. Oh so handy!

Not sure why the getLookVec stuff isn't working right, but you've still structured your conditional wrong. Saying world.isDaytime() || !world.isDaytime() will always evaluate to true, so you may as well be writing: if (true) { // teleport code } else if (world.isRaining()) { // chat code } You want this instead: if (!world.isRaining()) { // teleport code } else { // chat code }

What happens when you use this code?

No one can help you if you don't post any of your code.

I just gotta

It depends on what you're goal is -- there's often a Forge hook for your needs or some other method to do what you're trying to. But if all else fails, you will need to ASM it. I suggest really learning Java before you try that. What are you trying to accomplish by replacing the vanilla class?

Not sure if this is quite the right solution, as it would only introduce one furnace inventory per player -- it would become a sort of "ender furnace".

I would use a tile entity that has a hash map of type HashMap<String, Item[]>, where the string is a player's username. You can then get/set a player's items that they are smelting from that hashmap and act accordingly.

Also, to reduce redundancy in textures (so you don't have to create 16 different textures), you could create a custom block renderer (ISimpleBlockRenderHandler) for your glass block. You'd have a single image that is the edge of the block, and use the tessellator in your custom renderer to draw the edges of a face depending on the blocks around it.

To add a button to the main menu, you'll need to coremod it. Or if there's a forge render event for the main menu, you could hook onto it. There might be; I'm not sure, and I'm to lazy to check right now. As for the button functionality, look at the "Join server" button's code and see what that calls

Can you post your channel handler class (implements FMLIndexedMessageToMessageCodec) and your packet class?

You'll need to look into ray tracing in minecraft forge. Either find a forum topic about it, or look in the essentials of the vanilla code to see how it's used (e.g. when a block is even selected). I've haven't ever done anything like this, so that's all I can tell you, sorry