Category Archives: programming

minecraft modding environment quickstart

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

minecraft modding – integrated nei

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.

virtualbox rules

Nothing much to say here, but with absolutely minimal pain and suffering, I have 64-bit linux virtual machines running on top of my 32-bit windows XP install. This pleases me.

The recipe:

  1. Compatible CPU with VT-x/AMD-V enabled in the BIOS
  2. Innotek/Oracle/Sun VirtualBox (a current version) with hardware virtualization enabled
  3. Profit!

The one downside to this? 64-bit VM’s running on 32-bit host OS can’t see multiple cpu’s. Boo. Hoo. I’ll just run more VM’s!

64-bit centos installer 64-bit ubuntu livecd

dead simple traditional style rotation

In response to my two-step rotation post earlier this week, I figure I may as well share the logic I use for a more traditional logfile rotation scheme.

I think this is as simple as I can possibly make it:

A sample series of executions might look like this:
[code]
ammon@wernstrom:/path/to/log/file$ touch abc.log
ammon@wernstrom:/path/to/log/file$ php rotate.php
– rotating /path/to/log/file/abc.log -> 0
– creating /path/to/log/file/abc.log
ammon@wernstrom:/path/to/log/file$ php rotate.php
– rotating /path/to/log/file/abc.log.0 -> 1
– rotating /path/to/log/file/abc.log -> 0
– creating /path/to/log/file/abc.log
ammon@wernstrom:/path/to/log/file$ php rotate.php
– rotating /path/to/log/file/abc.log.1 -> 2
– rotating /path/to/log/file/abc.log.0 -> 1
– rotating /path/to/log/file/abc.log -> 0
– creating /path/to/log/file/abc.log
ammon@wernstrom:/path/to/log/file$ php rotate.php
– deleting /path/to/log/file/abc.log.2
– rotating /path/to/log/file/abc.log.1 -> 2
– rotating /path/to/log/file/abc.log.0 -> 1
– rotating /path/to/log/file/abc.log -> 0
– creating /path/to/log/file/abc.log
[/code]

This doesn’t have any failsafes, doesn’t compress anything, depends on an external call to ‘ls’, and it actually deletes old files in stead of overwriting them… but it is the shortest, simplest method I’ve come up with to get the job done.

If I feel like making this a full-fledged series, I might actually post a more thorough implementation later 😉

simple two-step logfile rotation

This is the result of 10 minutes of pounding on the keyboard after yet another disappointing experience with trying to get logrotate to do something vaguely more flexible.

This simple script scans all normal files in a log directory, and if they are older than a certain cutoff, moves them into a holding directory for old logs. Future passes will check files in the old directory for another age setting and will delete them. That’s all there is to it.

Configure your cutoffs, directories of interest, and optionally plug in a better logging mechanism and you’re set. (Oh, and change the #! if necessary, of course).

lazy php profiler

Caveman profiling with a side of “where were you at 9pm on the night in question?” As always, season to taste.

Continue reading lazy php profiler