Mod Structure

Minecraft mods will need a base mod class.  This class will be the place where everything starts.  It will here that the mod is defined.  It will be here that mod will be loaded.  However, unlike the ModLoader, Forge does not require you to specifically extend another class.  Instead you will use a set of annotations.  The trick is to know which annotation to use and where to use it.  The basic set of annotations is:

@Mod(modid, name, version)
@NetworkMod(clientSideRequired, serverSideRequired)

Each of these will be explained in detail as we go through our Minecraft mod. 

At this point you will need to create a new Java package for the first of your many Minecraft mods.  There are several schools of thought on how to name the package, but for this first mod, we will use the simplest approach and name it after the mod itself.  Open up the Minecraft project and under src create a new Java package named reddiamond, then create four child packages under that named block, item, entity and world, which would give you the following set of packages:


Next, in the reddiamond package create two new classes, RedDiamondMod & RedDiamondInfo.  The RedDiamondInfo class will have a set of constants for the mod information.  This will allow for the mod information to be easily available to any other classes in the mod, and be easily maintained in a single place.  This will be particularly important for the modid, which will be used for textures.  The class is shown below:

package reddiamond;

public class RedDiamondInfo {
    public final static String MOD_ID = "reddiamond";
    public final static String MOD_NAME = "Red Diamond Mod";
    public final static String MOD_VERSION = "1.0.0";


The RedDiamondMod class will be your base class.  This will be the heart the mod.  This is where Forge will load the mod, and this is where everything that mod uses will be defined.  This is where the mod related annotations will be placed. 

The @Mod annotation is used to define this class as the base class for your Mod.  It requires three parameters: 1) modid, 2) name & 3) version.  The modid is the internal named by Forge & MC.  This should be all lowercase, which will come in when doing your textures.  The name is the external name, and will appear in the mod list in the UI.  The version can be anything you want, but be sensible (e.g.: X.Y.Z)

The @NetworkMod is used to define how your mod will be used.  It has two parameters: clientSideRequired and serverSideRequired.  These can be either true or false, and determine whether the mod is needed on the client and/or server side.  For now, let’s keep it simple and set client to true and server to false, making this a simple client side mod. 

The @Instance is used define an instance of your base class as a singleton to ensure there is just one instance of your mod in the entire Java Virtual Machine (JVM).

The @EventHandler is used to work with the lifecycle of your mod.  Forge uses this annotation matched with a set of events to manage the lifecycle of the mod.  You would define methods with the event as a parameter with the annotation.  There are three that are generally used

public void preInit(FMLPreInitializationEvent event)
public void load(FMLInitializationEvent event)
public void postInit(FMLPostInitializationEvent event)

However, for this mod, it will only be necessary to have the load() method with the FMLInitializationEvent.  The barebones RedDiamondMod class is shown below.  This will be built up with future steps. 

package reddiamond;

import cpw.mods.fml.common.Mod;
import cpw.mods.fml.common.Mod.EventHandler;
import cpw.mods.fml.common.Mod.Instance;
import cpw.mods.fml.common.event.FMLInitializationEvent;

@Mod(modid=RedDiamondInfo.MOD_ID, name=RedDiamondInfo.MOD_NAME, version=RedDiamondInfo.MOD_VERSION)
@NetworkMod(clientSideRequired=true, serverSideRequired=false)
public class RedDiamondMod {

    public static RedDiamondMod instance;

    public void load(FMLInitializationEvent event) {