SanAndreaP

You're trying to destroy multiple blocks, so you need to call the destroyBlock method for each block you're trying to destroy.

and where do you call it? You know it doesn't magically get called by Forge, as it's not a BaseMod class... You need to have a proxy method called registerRenderer or something (it's up to you) and in the Client Proxy, use RenderingRegistry.registerEntityRenderer (or something like that) inside that method. Call it tn your main class (preferably in your @Init method) like "proxy.registerRenderers()"

check if worldObj.isRemote is false when you're trying to spawn something.

read your logs, or read the EAQ

Where exactly? As i remember, nbttagcompaund doesn't save arrays... A for loop on your block break method. An (integer) array can be saved in the NBT just fine (i think it's called set-/getIntArray()), else you can also use NBTList for storing arrays... look at the TileEntityChest NBT methods on how to use them.

Yes, because, following your previous code, the ticks don't happen on the (internal) server-side. They need to happen on the client both, client-sided and server-sided. On a dedicated server, they only need to happen server-sided.

cpw.mods.fml.common.registry.EntityRegistry.findGlobalUniqueEntityId() This is wrong. The parameter is the mod-unique Entity ID, meaning you can / have to begin with 0 and counting up. Also where does this method get called? addRenderer(Map map) EDIT: Also you should call the super methods for these: public void writeEntityToNBT(NBTTagCompound nbttagcompound) { } public void readEntityFromNBT(NBTTagCompound nbttagcompound) { } since it won't write it to the world save (except that is intended)

You need to translate the cube in the Model file, not in the render file. like (warning: pseudocode!): GLPushMatrix() GLTranslate(X, Y, Z) cube.render(par1Float) GLPopMatrix() How to get the value into your Model file? Add a variable in your model class and set it in the render file.

A tick Handler, like you wanted to do it previously, would be the better solution. Did you try to register in the ClientProxy the TickHandler for both sides (client and server)? So having two registrations for it in the client proxy (since on the client, the CommonProxy stuff is not called, unless you add super.registerHandlers(), which should not be done).

You need to make a for loop. Also I would store all positions in a 2D array in all of your TileEntities.

Clean your Coremods folder and try again. Make sure you've updated your mods.

What error? I assume your class name (public class JerrysArmor) is not equal to the java filename (in this case it must be named like "JerrysArmor.java"). Also those names are case-sensitive!

Oh awesome. I was kinda fishing for a response and got it I did some testing, and here are my comments: - Setting the mod meta data dynamically is less error prone (won't forget to move the mcmod.info file for example, although build scripts are the best) - the modid, mod version, and mod name are populated from the Mod annotation if you set autogenerated to false - You do need to set the description property! If you don't you will get a null pointer exception when someone tries to open your mod info page - If you have a mcmod.info file still, it will not work Although the mcmod file is there for a reason. It's for custom launcher and for Forge useful, since they don't need to obtain those infos by searching through the classpath and look for classes with the @Mod annotation (especially for custom launchers very useful). If you accept the fact that the mod info isn't read correctly by custom launchers, then you can stick with it.

That is not the point! Always use Forge methods! Why? ModLoader is client-only. What if you have loads of ModLoader stuff and want to use your mod on a server or make it compatible with it? You simply have to use the Forge methods, because ModLoader is simply not there, since it's client-only. Okay, i see your point. But there's no registerTileEntity method in GameRegistry. Yes there is, look at the class itself. It's in there, most of my mods use it: public static void registerTileEntity(Class<? extends TileEntity> tileEntityClass, String id)

That is not the point! Always use Forge methods! Why? ModLoader is client-only. What if you have loads of ModLoader stuff and want to use your mod on a server or make it compatible with it? You simply have to use the Forge methods, because ModLoader is simply not there, since it's client-only.

That is not the point! Always use Forge methods! Why? ModLoader is client-only. What if you have loads of ModLoader stuff and want to use your mod on a server or make it compatible with it? You simply have to use the Forge methods, because ModLoader is simply not there, since it's client-only.

Using ModLoader classes is bad practice when coding with Forge! Use this: GameRegistry.registerTileEntity( PS: If you find something which you can use with a ModLoader class, look into that class and you'll see the forge equivalent. Basically all ModLoader classes are just wrappers to accomplish compatibility with ModLoader mods.

Using ModLoader classes is bad practice when coding with Forge! Use this: GameRegistry.registerTileEntity( PS: If you find something which you can use with a ModLoader class, look into that class and you'll see the forge equivalent. Basically all ModLoader classes are just wrappers to accomplish compatibility with ModLoader mods.

read the EAQ

read the EAQ

Look at the GuiContainer class.

Look at the GuiContainer class.

What do you mean by "error"? I can't see any... except this little mod-caused one: 2013-04-22 16:33:58 [sTDOUT] 16908458 is not a valid stat, creating place-holder 2013-04-22 16:33:58 [sTDOUT] 16908459 is not a valid stat, creating place-holder

What do you mean by "error"? I can't see any... except this little mod-caused one: 2013-04-22 16:33:58 [sTDOUT] 16908458 is not a valid stat, creating place-holder 2013-04-22 16:33:58 [sTDOUT] 16908459 is not a valid stat, creating place-holder

Read your logs: