Code Monkey

So Now I have an understanding of how things work under the covers, it’s time to actually try to produce something. In the past I have used Eclipse for Java development (In fact development generally since I am a c++ programmer by day…) and I find it reasonable to use for this purpose.

Mincraft Forge before 1.7 had a set of scripts that the user could run to perform the setup (Extraction, de-compilation, de-obfuscation and work-space setup) written in python. These were a black art to most people and so now a Gradle build system has been created, although to many Gradle was a big unknown.

The big head start however is that the forge project can be downloaded without downloading anything else and it will take care of the details for you. Simply down load the “src” version of the forge from the downloads page (E.G. 1.7.2 recommended at the time of writing) and extract the contents into a directory of your choice.

There is actually very little in this setup and that’s because Gradle is told how to download what it needs to run. It downloads a plugin written by forge which will add the tasks that need to be performed in order to set up the environment.

There are 2 different ways to invoke the setup, gradlew setupDevWorkspace  and gradlew   setupDecompWorkspace .  It is useful to be able to examine the minecraft sources and so the latter of these two commands is what I use. N.B. the sources are actually held in a Jar file rather than in the source tree (prior to 1.7 forge included the de-obfuscated sources for minecraft in the project directly).

Once the command has finished running then you can use Gradlew eclipse to actually initialize and set up the eclipse work-space. Once you start eclipse, and set the work-space it should look similar to the picture below.

The picture above shows the ForgeSrc-XXX.jar  file which has the source code in it, if you used setupDevWorkspace then this would be the ForgeBin-XXX.jar  file instead. Also note the “example mod” source that is added to the project as a guide for you.  The setup also adds run/debug configurations, and when run or debugged minecraft will display the following:

Note that the Example Mod has a version of $(version) above. This is because I ran the debug profile. If you run gradle build  it will substitute the $(version)  for the real version specified in  build.gradle into the mcmod.info file under the resources folder.

From the previous article I have now almost covered the basic elements that make up a mod. The last important annotation (That I have come across So far!) is @SidedProxy  .

Essentially this annotation would be used in the mod class to annotate the static variable proxy .  This annotation is used by the framework to initialize the variable with an instance of a class that is dependent on whether it is being run on the server or the client.

By doing this we can code our mod for both sides using a single set of sources, although the actual class is completely under our control again apart from the fact that the two classes should be derived from a common base class. So even though I called the class  CommonProxy  above it is actually an arbitrary class name and so are the methods defined on it.

The way that this is used is in the initialization Event handler defined in the Mod class. The base class is “traditionally” defined in the following way in most tutorials on the web

FML sources are the basis for developing mods that are compatible with Minecraft forge, and here I am going to investigate and explain some of the main features. I’ve done this as a learning process for myself, but if it helps others then great.

A good place to start is with the simple example mod that is included with FML. It is very basic, but it illustrates the principles involved.

I have not used Java for some time and so I need to refresh my knowledge a little, specifically whilst I have used annotations like  @override  but I have not seen this used in user code (I guess because I haven’t worked in a Java Shop before.)

@Mod

The @Mod annotation is provided, along with others as part of the FML interface. It is essentially a way to tag classes with information, and takes the place of what would be often repeated boilerplate code. The definition of this annotation is the basis for the class interface that Forge expects when trying to load a mod.

if we modify the example mod code slightly

We can extract the data that is attached to our  ExampleMod class

Here you can see that the class effectively contains more data members than we specified and that the values for version and modid correspond to the values of our members  MODID and  VERSION . FML will interrogate our generated classes in much the same way to get the values it requires to load and operate the mod.

Additionally we can see that within our  ExampleMod  class there is also an annotated method   @EventHandler  which tags the init method as special. Note that the name of the method is completely independent of the Tag and could be anything. However the signature of the function is important and the parameter be one of the following:

These events represent points in the lifecycle of the mod, for example just before initialising your mod FML will call a method which takes the  FMLPreInitializationEvent , and in this you can load up any configuration for your mod which will change things in initialisation (E.G. Block IDs could be read and configured so users could change them to manually avoid conflicts between mods).

More details on how this works lie in the FMLModContainer class in the FML sources, for example method  gatherAnnotations extracts the methods annotated with @EventHandler  and stores them in a map so they can be called for the class.

Next…  @Sidedproxy