Draco18s

....Yes. Forge doesn't know what your mod ID is when you start, so it's not going to make the folders for you.

@Override public final NBTTagCompound writeToNBT(NBTTagCompound nbt) { NBTTagCompound tankData = new NBTTagCompound(); super.writeToNBT(tankData); this.writeTankToNBT(tankData); nbt.setCompoundTag(this.name, tankData); return nbt; } Woah. Slow down. First, you've unneccessarily duplicated your functions. You shouldn't need the this.writeTankToNBT(tankData); part at all (not to mention that that function is empty and does nothing). Second, you've marked that function as final. You don't need that. In fact, probably shouldn't have it. I have half a mind saying that because you marked it as final, the function signature changed and it's no longer overriding. Though my other half says not. Either way, you don't need it. Third, don't use this.name as a key...you can't be sure that that name won't change between a save and a load...

Open Block.java ctrl-f collision

Read the chest, go "oh, a chest," read the chest contents, destroy the chest contents, continue as you're already doing.

Yes. If you know a little programming.

They have fake blocks providing the colliders. When any one of the blocks involved in the multi-tile object are broken, they're all broken.

Bats already spawn only in caves. It's called world.canBlockSeeSky()

floor, ceiling, round...none of those are going to locate a tile entity that encases the player's feet. You should get the location of the tile entity from itself and pass the xyz in the packet.

TileHandheldFurnace tilehandheld = new TileHandheldFurnace(); Uh. You're going to want to approach this differently.

I am surprised that didn't crash. You are not using the method correctly. I think he got lucky.

Don't use variables like that. Just pass them to the function like you did with the world object...

"C:\Users\MyUser\Desktop\Forge Development Environment\src\minecraft\assets\mymod\textures\items" is the correct path, assyming "mymod" is your Mod ID and that you're workspace is at "C:\Users\MyUser\Desktop\Forge Development Environment\"

Go to mcp/conf and open up methods.csv That will tell you the human-readable name of every func_* fields.csv will do the same for variables.

Its the for loop. Eclipse doesn't like for(type var : array) type loops. You'll have to change it to a regular loop. The code is technically valid, Eclipse just doesn't like it (it's a decompile-is-not-perfect issue).

Decompiling is not a perfect science. If you know what the errors are and know what you're trying to do, you can usually solve the problem.

[me=Draco18s]facepalms.[/me]

Right. APIs do not have their own mod ID. They're simply a package that is part of a mod that is distributed as source code. You don't even need to include the compiled API when you distribute if you do things right.

1) Check to see if buildcraft is active first. There's a Forge method for this, I keep forgetting what it's called. (Reflection can do the same thing, here's one I use because I keep forgetting said Forge method: try { Class.forName("com.xcompwiz.mystcraft.api.MystObjects"); } catch(ClassNotFoundException e) { return; } 2) Check to see that the API has instanciated its values. Eg. here's what do if(MystObjects.book_lectern != null) { ... } 3) Once both of these pass, then access the API and do API related calls.

Any square texture works although you're encouraged to use 16x16 or some multiple thereof.

@Override public float getStrVsBlock(ItemStack par1ItemStack, Block par2Block) { } ?

Override getCanSpawnHere() You can access the world with the entity's worldObj, posX, posY, and posZ (even though it hasn't spawned yet) and check to see if any more of your mob are in the area, and if so, return false.

Or leave that function out entirely.

Pre-gradle you can modify the base classes to your heart's content without ASM.

Note: ASM is superadvanged Java and requires an intimate knowledge of compiled Java bytecode.