Draco18s

That void function is the function that checks the slots to see if both have items, and if so, do whatever needs to be done.

SOL? Sh*t Out of Luck. His option is to either check all the blocks that could possibly be providing power (6 for strong, significantly more for weak) or nothing.

Open up BlockFurnace.java

I have no idea how reflection works.

You're probably going to have to make a dummy API (or several, actually) to act as placeholders for the classes from those other mods that don't exist.

Unfortunately not even redstone wire works better than that. So he's SOL.

Running from memory: sometimes you think there are extra params. Apparently I was wrong, world.markBlockForUpdate(x, y, z) should work.

try world.markBlockForUpdate(x, y, z, flag) You'll have to read the javadocs on the flag, but I think you need a 3.

world.getBlockMetadata(x, y, z)

new ItemStack(Block.cloth, 1, metadata);

/** * Called when an the contents of an Inventory change, usually */ public void onInventoryChanged() { ... }

... Seriously? I'm not even going to tell you what's wrong. It should be blindingly obvious to anyone with a pair of eyeballs.

Or the Living Entity. Whateverthehellentity that lets you open the GUI that has the slots in it.

Because: this.blockIcon = par1iconregister.registerIcon("[oreJuli]"); Your registering things wrong. It's looking for a file named "[oreJuli]" (including those brackets!) in the /mods/textures/blocks folder. 17th time I've posted this:

That is not how you should be doing things. The two input slots handle whether or not the item is valid, the TileEntity should handle if both slots are filled and put the output item in the output slot.

This is wrong. You want Juli.oreJuli.blockID Type errors are a very good thing to check: var i = new Object(); if(rand.nextBoolean()) { i = 3; } i.prop = 9; That should not compile.

When you put a function in a class it is assumed that you need it in that class. You're not using it in that class (it is, in fact, identical to the isItemValid function) but you want to call that function from another class....why?

I've gotten into using type restrictions in Flash because it's faster. Otherwise this is valid code (and not only will compile, but will run: var i = 1.333; i += 0x1; i = new Object(); i.random = 2; There are good reasons for getters/setters. For example if setting the property means that some other flags or variables need to get set as a result. A good example is the setters that cause datawatchers to update. Likewise health (forcing every effect that CAN reduce an entity to 0 hp having to manage that entity dying would be absurd, instead you can manage that inside the setter!).

Eh. My C* is a bit rusty. I can't write applications from the ground up, much less one with a GUI or any rendering. Most of what I do is either in Unity3D, Flash, or web-based. As far as I'm concerned the only difference between Java and Flash is how variables are declared. ("int a;" vs. "var a:int;") Oh, and having to deal with Floats and Doubles not being the same thing and can't convert between them implicitly.

"You can probably pick it up while writing mods." I am going to kick the person who wrote that. It's not technically incorrect. I didn't know Java and started writing mods. I did, however, have prior programming experience in multiple languages (C++, C#, Javascript, Actionscript 2, Actionscript 3...).

True, but my point was: The old spritesheets were 256x256 and held 256 sprites. To keep that the same under the new system, you need 16x16 icon files.

Try extracting the entire zip. I don't know if it'll make a difference, but you might be missing a file because of that.

The Minecraft wiki has a template set up for it. Unless your wiki software has templates, then you aren't going to be able to do it easily.

This is more appropriately a vanilla bug. In fact it has already been reported

coolboy: You still need to return the right renderType Indeed.