What is this? I’ve liked many things throughout the years. While some have fallen out of my attention, others remain firmly cemented in my memories and feelings. So, I’ve decided to start a mini-series where each week (hopefully), I pick something random that I like or have liked and discuss it, why I like it, and its impact on me. These things can be varied, and range from more trivial matters such as my favourite animal, to books, games, and movies I’ve liked, to topics that have shaped who I am as a person. The posts, accordingly, will vary in length.
> weekly series
> doesn’t post for three months
Anyways, my third “Thing I Like” is “Minecraft Modding”.
I’ve been a Minecraft player for quite some time. I got the game a month after its 1.0.0 release late 2011, and have played it on and off ever since. In the 1.2.5 era, I began playing modded, and was one of many who enjoyed the Tekkit (now called Tekkit Classic) modpack. At the time, modding was in a very young state, and the idea that mods could be compatible enough to form a “pack” of them was a breakthrough.
You see, before those days modding was done by simply opening the game JAR and adding or replacing certain classes within it, so called “base editing”. (Of course, deleting META-INF was crucial so the game’s checksums wouldn’t reject the modification) Mods made in this manner usually were not compatible, and modders tiptoed carefully to avoid touching more than they had to. There was a “mod of mods” called “ModLoader” by Risugami that provided some low-level coordination between mods, but even then incompatibilities abounded.
The MinecraftForge API changed all of this. Starting life as a humble set of base edits, it later expanded to even include a reimplementation of ModLoader. It provided an API against which modders developed; Forge would make all or most of the base edits necessary to Minecraft, and modders would call Forge’s abstractions over those edits.
With each step and with help from Mojang, each version of the game has gotten easier and easier to modify. Nowadays, making a new mod only requires the ability to run a couple scripts and write standard Java code.
What I Do
So what have I done in modding? I started out as a player in the 1.2 era, and played mostly up to the 1.7 era. In the 1.8 era, Mojang released an update with some challenging rendering changes, and some mods in the community were not willing to or did not have the resources to cope with such changes. I stepped in and helped a few of them (see about me), and have maintained a couple ever since
I also contribute frequently to Forge itself, either to fix bugs or add the occasional new feature that mods might find useful.
One of my favourite things to do, however, is helping map things. You see, the game code released by Mojang is
obfuscated, that is, the variable names scrambled to hide the organization. Throughout the years, people have built
up an infrastructure that is able to decipher most of these class, method, and variable names immediately on release,
but every release there’s always new code, new systems, and new things that need new deciphered names.
We basically pore over the source code, which the decompiler infrastructure gives mechanical names such as
and attempt to reverse-engineer what Mojang was trying to do, and give the item a suitable human-readable name for others
to use when modding.
Overall, the majority of my non-school non-work coding time has gone to modding, and it’s been a great deal of fun (and tedium). There’s lots to explore and contribute to, though I still think I may need to diversify a bit :P
See you in the next one!