This is adapted from something I wrote for the EbXL team, but it applies to any active mod development.

NB: I am assuming a moderate degree of technical ability here. If you don’t understand what I’m talking about and can’t Google the missing pieces for yourself… I’m sorry.

I have been working for ages (read over a year) on a tutorial on fully customizing and massaging a modding environment capable of handling multiple mods at once. But the community shift to backing Gradle has thrown enough kinks into the process that I’m largely unmotivated to work very hard on it any more.

But it has been long enough – I just need to put something out there. So here we go, a quickstart for using Eclipse to compile an existing mod.

While some people recommend IDEA, I can’t get used to it. I used IDEA for the entirety of EbXL’s 1.6 to 1.7 port and hated every minute of the process… so am personally giving up – and going back to Eclipse (a decade of experience trumps all else in this case).

Step 0: Install tools

I’m not in a position to go into details on this right now. But suffice it to say that you need modern versions of:

• git
• eclipse – a current version of the Java IDE (Juno or above, anything else is WAY too old; J2EE version is unnecessary)
• jdk – Oracle’s OpenJDK (others are not guaranteed to work). Ideally, your mod will compile against Java 7 or 8, but it is probably best to use 7 for now as that is what most players should have installed – but you should probably refrain from using anything that doesn’t work in Java 6, just in case.

Continue reading minecraft modding environment quickstart →

NB: The following only applies to Minecraft 1.4, the process is a lot simpler in MC1.6+

This is a bit of a non sequitur from my normal content, but truth be told, I’ve just never had a chance to talk about anything Minecraft-related on here yet 😛

One of my least favorite parts of Minecraft modding is the testing and iteration process. If you use MCP’s Eclipse project, rudimentary iteration is simple. You can rebuild and launch a client or server directly from the IDE without having to reobfuscate the code first. This is great for tracking down bugs like forgetting to actually register your blocks and simple stuff like that.

It’s not so great for testing something that requires survival mode mechanics plus arbitrary items that aren’t simply going to worldgen right next to you (ie, almost every real test case).

Case in point, we wanted to test carrots. By making a creative mode world, I was able to spawn a carrot and confirm that I could craft seeds out of it. I was even able to confirm planting the seed and that it grew over time… but I couldn’t test breaking the block to harvest or that the seeds were being consumed on planting…

Normally, I’d use something like NEI for this. But NEI is one of those tricky mods that requires installation in the jarfile. Also, running the game from Eclipse renders it incompatible with obfuscated mods (ie, any distributed mod). After a lot of trial and error and 3 corrupted MCP installs, I finally stopped being stupid and realized that ChickenBones has released his sourcecode (no need to fail miserably at deobfuscating it).

Original source in hand, it was only a few minutes and we had glorious useful NEI for testing. Assuming you have already set up MCP+Forge with Eclipse, the install process goes something like this:

1. Download source for CCC and NEI (from the thread here).
2. Decompress somewhere useful.
3. Link both common and client folders to your project’s build path.
4. DELETE GuiContainer from MCP’s client src.
5. Profit.

I put both CCC and NEI in an external/ folder and just copied their common and client source into a single sub-directory for simplicity, but it may be better to leave them separate – especially when working with server code as well.

GuiContainer appears to be the only base class that NEI overrides, so simply ensuring that his version is in the classpath while the vanilla version is not is enough to get things to compile and run.