Basic Mod-1.8.9

From McJty Modding
Jump to: navigation, search

There many ways that you can structure your mod. This section just proposes two possible solutions:

First here is a minimal mod class:

@Mod(modid = ModTut.MODID, name = ModTut.MODNAME, version = ModTut.MODVERSION, dependencies = "required-after:Forge@[11.15.0.1634,)", useMetadata = true)
public class ModTut {

    public static final String MODID = "modtut";
    public static final String MODNAME = "Mod tutorials";
    public static final String VERSION = "0.0.1";

    @SidedProxy(clientSide = "modtut.proxy.ClientProxy", serverSide = "modtut.proxy.ServerProxy")
    public static CommonProxy proxy;

    @Mod.Instance
    public static ModTut instance;

    public static Logger logger;

    @Mod.EventHandler
    public void preInit(FMLPreInitializationEvent event) {
        logger = event.getModLog();
        proxy.preInit(event);
    }

    @Mod.EventHandler
    public void init(FMLInitializationEvent e) {
        proxy.init(e);
    }

    @Mod.EventHandler
    public void postInit(FMLPostInitializationEvent e) {
        proxy.postInit(e);
    }
}

Now let's talk through what each part of the code does:

@Mod(modid = ModTut.MODID, name = ModTut.MODNAME, version = ModTut.MODVERSION, dependencies = "required-after:Forge@[11.15.0.1634,)", useMetadata = true)

The "@Mod" let's Forge know that this is a mod and it should treat it as such. The "modid" tells forge what id it should use for your mod, in this case it references a string. The "name" part is the readable name that will be displayed, again this references a string. The "dependencies" part shows what mod(s) this mod depends on (what other mod(s) must be there for this to run), in this case Forge 11.15.0.1634. The "useMetadata" determines whether Forge should use the mcmod.info file to override the other settings in the annotation.

    public static final String MODID = "modtut";
    public static final String MODNAME = "Mod tutorials";
    public static final String MODVERSION = "0.0.1";

These are the strings referenced back in "@Mod". They say that the "MODID" is "modtut", the "MODNAME" is "Mod tutorials", and the VERSION is "0.0.1".

    @SidedProxy(clientSide = "modtut.proxy.ClientProxy", serverSide = "modtut.proxy.ServerProxy")
    public static CommonProxy proxy;

This part sets up the proxies which will be explained later

    @Mod.Instance
    public static ModTut instance;

This creates the mod instance by telling Forge it should run the ModTut class.

    @Mod.EventHandler
    public void preInit(FMLPreInitializationEvent event) {
        logger = event.getModLog();
        proxy.preInit(event);
    }

    @Mod.EventHandler
    public void init(FMLInitializationEvent e) {
        proxy.init(e);
    }

    @Mod.EventHandler
    public void postInit(FMLPostInitializationEvent e) {
        proxy.postInit(e);
    }

This large part sets up the running of parts of the mod during preInit, Init and postInit. It also set's up a logger for the mod to print to the console

You also need proxy classes. These classes take care of doing the init of your mod and make sure the right things get done at the right 'side' (i.e. server versus client). It is considered good practice to work like this. Note that in many cases you can use CommonProxy for the server side since most things you want to init on the server you have to init client side as well.

public class CommonProxy {
    public void preInit(FMLPreInitializationEvent e) {
        // Initialization of blocks and items typically goes here:
        ModBlocks.init();
        ModItems.init();
        ModCrafting.init();
    }

    public void init(FMLInitializationEvent e) {

    }

    public void postInit(FMLPostInitializationEvent e) {

    }
}


public class ClientProxy extends CommonProxy {
    @Override
    public void preInit(FMLPreInitializationEvent e) {
        super.preInit(e);
        // Typically initialization of models and such goes here:
        ModRenderers.preInit();
    }
}

public class ServerProxy extends CommonProxy {

}

In Forge 11.15.0.1671 and up, you don't have to fill in the @SidedProxy parameters anymore. When you leave the parameter the default value (an empty String), it uses the nested Server- and ClientProxy classes from the parent class. To use it, you have to make the nested ServerProxy and ClientProxy class inside the class with the @SidedProxy annotation. Here's a little example:

@Mod(modid = ModTut.MODID, name = ModTut.MODNAME, dependencies = "required-after:Forge@[11.15.0.1671,)", useMetadata = true)
public class ModTut {

    public static final String MODID = "modtut";
    public static final String MODNAME = "Mod tutorials";

    @SidedProxy
    public static CommonProxy proxy;

    @Mod.Instance
    public static ModTut instance;

    public static Logger logger;

    @Mod.EventHandler
    public void preInit(FMLPreInitializationEvent event) {
        logger = event.getModLog();
        proxy.preInit(event);
    }

    @Mod.EventHandler
    public void init(FMLInitializationEvent e) {
        proxy.init(e);
    }

    @Mod.EventHandler
    public void postInit(FMLPostInitializationEvent e) {
        proxy.postInit(e);
    }

    public static class CommonProxy {
        public void preInit(FMLPreInitializationEvent e) {
            // Initialization of blocks and items typically goes here:
            ModBlocks.init();
            ModItems.init();
            ModCrafting.init();
        }

        public void init(FMLInitializationEvent e) {
    
        }

        public void postInit(FMLPostInitializationEvent e) {
    
        }
    }


    public static class ClientProxy extends CommonProxy {
        @Override
        public void preInit(FMLPreInitializationEvent e) {
            super.preInit(e);
            // Typically initialization of models and such goes here:
            ModRenderers.preInit();
        }
    }

    public static class ServerProxy extends CommonProxy {
    
    }
}

(This code it untested, but it *should* work)