Tag Archives: howto

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

agrarian skies bootstrap

Agrarian Skies is a modpack and hardcore questing mod challenge map from Jadedcat and Morvelaira. It’s pretty awesome. It’s also pretty intimidating if you’ve never played skyblock before. I’d like to take a moment and go over some basic advice for getting started that should hopefully save you a lot of frustration.

Hardcore 101

First off. This modpack uses HQM, the hardcore questing mod. It also uses hunger tweaks and disables numerous low level recipes and increases the cost of a few others… many things are more difficult.

The most important thing to be aware of early on in the game (before you have a factory that makes you barrels of ham and cheese sandwiches) is your food consumption.

Actually, that’s second most important. The most important thing to be aware of is that you have a limited number of lives. When you die, it keeps track… and if you die too many times, you get booted from the world and can’t log back in without some major hassle on the part of the server administrator. By default, you have two lives.

You will earn more lives by turning in quests, but some early stupidity can ruin things very easy if you don’t pay attention. So pay attention. Don’t fall off of the world, don’t starve to death.

Starvation is probably your biggest enemy – you will not start off with much/any food. Some early quests give you apples, but they have been nerfed hard – you could eat 10 apples from starving and still not be full. Oh, and if you ever hit zero hunger, you die immediately. So there’s that too.

NB: Do not eat zombies. It will kill you. Horribly.

Continue reading agrarian skies bootstrap

life without industrialcraft

So I’ve been back to playing Minecraft again recently. After the barren vanilla wasteland that was 1.3.2, 1.4.x is like a breath of fresh air – I think they’ve got an even vs odd numbered build thing (1.0 was good, 1.2 was good, 1.4 is good).

Unfortunately, some major mods are still reeling from the changes that 1.3 hit them with and have STILL not yet updated. IndustrialCraft 2 is one of the best mods out there and it was the core element of my 1.0 & 1.2 play. But… they’ve been slow to update. IC2 for 1.3/1.4 is still technically in beta and I have observed enough nightmarish bugs and half-implemented features that I’ve sworn it off until they at least declare a release candidate build. Hopefully that’ll happen before 1.5 reboots everything again 🙂

For a lot of my friends, IC2 is all they know. And for a long time, it was for good cause. IC2 provides a good variety of tools that are very easy to become dependent on – and until fairly recently, they were the only major mod to do a lot of the things they did. But times, they are a changin’.
Continue reading life without industrialcraft

dwarf fortress loadout manifesto

Dwarf Fortress is a notoriously complex game, and it isn’t getting any simpler. The barriers to entry are enormous. One of the worst culprits is the process of saying “Hey, I want to start a new game”. Before you start actually bossing dwarves around, you must:

  1. Create a world. This is trivial but time consuming, even on modern hardware – the process is increasingly complex with each build. Thankfully, you only have to do this once, so I consider this the final part of “installing” the game.
  2. Choose an embark location. This is fairly simple but possibly equally time consuming – because see #1. The world is big and there are a lot of possible places you might want to go. Some simple advice can help you get through this quickly enough, and I’ll address this later.
  3. Choose an embark loadout. This should be simple but is one of those choices that can bite you. You can either choose your own dwarves and equipment or you can trust the ever-changing default loadout. Traditionally, the default loadout is pretty mediocre and leaves a lot of room for improvement. I would like to go over my preferred build and the reasons behind it – as well as some reasons to do something else.

I have taken various levels of notes during 14 different playthroughs over the years (starting with 40d up to and including v0.34 builds). Using my notes as reference, I’d like to propose exactly how a person might consider going about the process of choosing an initial loadout.

The current (v0.34.11) default starting loadout is better imho than previous initial loadouts, but it’s still suboptimal – and leaves you open to several potential problems during your first year. If you are aware of your loadout and take care in your embark, you’ll be fine – but isn’t part of the point of the default that it should “just work”?
Continue reading dwarf fortress loadout manifesto

mechromantic specifications

So, it is no secret that Borderlands is one of my favorite games of all time. Steam lies and says I’ve spent almost 400 hours between the two games. That is a gross underestimate. I believe I probably have finally spent more time on BL2 now than I did with BL1 and all of its DLC’s combined, and between the two games, they probably do add up to the “individual” FPS with which I have squandered the most time now.

When Gaige the Mechromancer was released as BL2’s fifth playable class, we were stoked. A coworker and I decided to try her out as a dedicated duo. Last week, we finished our second playthrough with our pair of mechros. These characters were never more than 15% of a level apart – mostly the result of spec experimentation on random mobs.

As we played to level 50 and beyond, we experimented with every imaginable character spec possible. He spent the entire time as some variety of Anarchy build and I spent most of my time in the lightning damage tree but occasionally tried heavy BFF or other random combinations. I even tried running Gaige in melee with a roid shield.

The end result is that we’ve returned to a pair of builds that are interesting and effective.
Continue reading mechromantic specifications

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.