👋🏻 Welcome back

I know this has been teased ages ago on the Second Cup - and yes, I was still working on this on and off. I also lost the last iteration of this script, so I had to go off the top of my head for large parts, but I'm tired of this thing still laying around and not being released, as I by now have more topics I want to talk about. The Second Cup isn't really the place for my long-form ramblings.

(008) Stirring the cup
Second Cup icon
Second Cup

(008) Stirring the cup

The next issue of your weekly, coffee-flavored newsletter spotlighting Minecraft 1.12 mods, makers, and community news.

Enderman
(008) Stirring the cup

🤔 The Paradox

Alright, so let's pick up where I left off in the Second Cup - after becoming a modder myself, creating modpacks became even harder for me, even if you think it should be the other way around. Like, "Now that I can make whatever I want, my modpacks should become better than before." But once you sit down, plan out the overall vibe, the first iteration of the progression, and the basic gameplay loop, you get to the point of assembling the modlist of the projects you want to utilize in realizing your ideas. Sadly, it is not as simple as it sounds. It's quite rare that there is a mod that covers a specific idea you want to implement.

Before picking up programming and making mods, the usual approach a pack dev takes is utilizing the tools that are available and finding a compromise between what is possible and what you originally aimed for. But now that I am a modder, it became, "Well, I could write this myself." So you quickly come across the situation where you have to write a mod for half the mechanics you want to realize in the pack, and instead of working on the list of projects you already have in your backlog, you just added another 3 projects to it. By the time you worked through all of it to get back to the pack, there already are ideas for new shinier packs you could make now, as our ecosystem keeps evolving and maintained mods get new features all the time and entirely new mods hit the scene.

🧐 Wait, there is more than just "playing" this game?

So I picked up Minecraft shortly before it hit the official 1.0 release (which at the point of writing was like 15 years ago, aka half my life ago).1 Though after "beating" the game itself by killing the dragon and experimenting with the limited redstone components in creative, the base game got boring fast. Luckily, only 3 months later version 1.1 was released2, which marked the beginning of my modded journey, as it was the first time I came in contact with legendary mods such as BuildCraft, IndustrialCraft and later RedPower2, Forestry and Applied Energistics. There was no thinking about how to integrate these with each other - either they shipped crossover recipes by default or not. It wasn't about tweaking configs to make "a good experience". It was only "get as many of them working in one instance as possible and see where it leads me".

Anyway, fast forward to 1.7.10 (so only 12.5 years ago)3, which by today's general opinion is known as one of the first "golden versions" where modding actually became more serious, with modpacks still being played by thousands of people to this day (GTNH wink wink). Though back in 2014, it was time for me to properly dive into pack dev territory with actually picking up MineTweaker (which became CraftTweaker in later versions) to change recipes, the FTB mod suite, which allowed multiple packmodes in a single pack with different recipes based on the packmode, and even trying myself at setting up a questbook.

🐺 Zerblands

By 20164, I transitioned from school to university where I studied physics and CS. After experimenting with some Python on my own before, this was my first step into "real programmer" territory. Working with Git, the terminal, managing dependencies - you name it. But still no Java and Minecraft modding in mind. By that time, I got in contact with a small streamer5 I found on Twitch who struggled with accomplishing something in the pack he was playing. I just sat there in chat and explained multiple ways how he could accomplish what he was trying to do, and he recognized that I was quite knowledgeable and invited me to his TeamSpeak6, which eventually led to me participating (and after a short while, somewhat dominating everyone else) on said server.

I remember how nervous I was as I never talked to "a stranger on the internet" before, but I can assure you that most of the people I got to know during that time are some of my closest friends today. Why am I telling you that? I dunno, maybe just so I tell myself I'm a somewhat normal person, doing normal social interaction in the time of the internet and I haven't lost my sanity yet? Who knows.

So after that server went stale and there wasn't really any new pack we wanted to tackle, they approached me asking if I could make a pack for us to play. This is how the original "Zerblands" was made (not the remastered version which is available on CF, I'll get to that later). It was mostly a collection of the mods everyone wanted to play with, but with unified resources, alternative world generation, and some slightly tweaked recipes to motivate players to test out the other mods available in the pack. This pack became a huge success in the little micro-community we formed, with up to 20+ active players on the same servers. Some of the memories I'm most fond of originated in that time.

In the following years, 1.10.2 grew somewhat stale, we switched to more modern versions and modpacks, and eventually arrived in 1.12.27, and oh boy, that version would be the main one for myself by a long shot. As our micro-community broke down and multiple attempts at the next iteration of Zerblands never became a reality, I eventually dropped out of university in 2019 as my life hit a wall with full force. After slowly getting back to myself, traveling through the country, and looking for something new, I eventually moved to another city and started an apprenticeship. Though with my prior knowledge obtained during my time at university, I found myself with a lot of free time.

Most people from that time carried on and, with a few exceptions, it was mostly me and my computer. It didn't take long to get back into Minecraft. But instead of playing any of the modpacks that were published during my hiatus, I loaded up Zerblands and just started playing Singleplayer, and god, has it aged. Not like it became bad overnight, but all the bugs I encountered were still present (who would have guessed that, when nothing got updated ever since, duh). So I started looking through CurseForge to check what mods had any fixes since I last checked. I quickly realized that most of them already had published a build for 1.12, and with that, I decided to update the whole pack to 1.12.2 just to see if I was still as knowledgeable as before.

It took me 5 days - that's it, no controversy, no major issue, just me working away at my to-do list - what a great feeling. This time I actually published the pack to CurseForge, and with that, Zerblands-Remastered was made public. It didn't receive the hype (if you can call it that) the original one had, but me together with a few of the people from back then had a server we spent hundreds of hours on. But besides being a remake of the original, there wasn't really anything innovative in it, except the newer version.

Zerblands-Remastered
Slightly tweaked progression based Modpack (Includes a second more complex Packmode) 4.9K Downloads | Modpacks
https://www.curseforge.com/minecraft/modpacks/zerblands-remastered

🔥 Getting into modding by accident

During playtesting said packmode, I encountered a bug in the Embers Rekindled mod. The mod itself has a gimmick where it changes some recipe requirements based on the world seed. The author however forgot to add a check for when that requirement returned an item with the stack size of 0, which made the recipe uncraftable, thus blocking any further progression.

Instead of simply removing the recipe and adding it back while making sure it can't become 0, I looked up the source, found out it would be a trivial fix and decided to fork the mod instead. In the beginning, I still had the intention to just make a pull request and that it would be fixed in the next release.

So aiming for a PR was a fruitless endeavor, as the current maintainer of the mod left the scene altogether. So instead of just fixing that one bug, I continued working on my fork. Small refactors, new config options, more bugfixes from the original bugtracker.

Fun fact: to this day Zerblands-Remastered still uses the original instead of my fork, but this is just due to the fact that my to-do lists exploded after picking up my first mod.

So after picking up half of the Embers suite89 and starting to maintain them, I once had the idea for another new modpack - how original, I know. There I encountered the paradox again. Minutes after starting to tweak the small mod base I had in the pack, I encountered something that didn't exist, and instead of compromising, I switched right back to my IDE, and that was the birth of EMT, aka Ender's Modpack Tweaks. One of my most used mods to this day.

Ender's Modpack Tweaks
General Tweaker mod inspired by Universal Tweaks, with a focus on modpacks. 211.8K Downloads | Mods
https://www.curseforge.com/minecraft/mc-mods/ender-modpack-tweaks

🍮 Where is the sauce?10

First reason: while CraftTweaker and GroovyScript are powerful tools when it comes to scripting custom content and mechanics in a pack, they either provide an abstraction layer on top of the Minecraft methods, or you're forced to open an IDE anyway to look at the decompiled source if you wanna import and call a specific method. So when you already have your IDE open, why not just write the mechanics in there? This also comes with all the benefits of auto-import, proper highlighting, etc.

🌌 One mod, many packs

The second reason is re-usability. Yes, you could share your scripts folder and someone else could use it - CurseForge even offers uploading scripts to share with others - but it is much more likely, if put into a proper mod with a config etc., that others may pick up said mod for their projects as well, benefiting the whole community and not just my own modpack.

🗨️ Gotta pick a language

The last big reason is more of a personal preference. See, CraftTweaker for example uses ZenScript as its language, which was specifically created for that mod, so even if it has similarities with other known languages, there isn't any tooling you can use to make things easier, as they need to be written to explicitly support it. Even though I spent an immense amount of time actually writing it and did some interesting things with it in the past11, I prefer to adapt to newer alternatives.

The final nail in the coffin on this whole language thing for me personally is that I somewhat recently picked up Kotlin as a programming language. This happened more because I was kinda forced to, as I created a fork12 of the Alchemistry mod, which by surprise was written in Kotlin. So to wrap my head around its codebase, it was necessary to pick up a basic understanding of said language. I'm by no means an expert in it yet, but there are a lot of nice features I would like to see in base Java. This is also the reason why most of the newer projects of Ender-Development.org are written in Kotlin and utilize our Catalyx library we've been writing in the background.

Alchemistry - Redox
Fork of Alchemistry for 1.12.2 with fixes and improvements 2.0K Downloads | Mods
https://www.curseforge.com/minecraft/mc-mods/alchemistry-redox

🎀 Wrapping things up

Going back over all of this - the block id juggling back in 1.1, the questbooks in 1.7.10, Zerblands, the nightmare mode, the Embers fork, EMT, Kotlin, Catalyx - there's one pattern running through the whole thing. Every single time I wanted something that didn't exist yet, I ended up building it myself. First with MCreator, then with config files, then with scripts, and eventually with an IDE and the compiler.

Which is the paradox in a nutshell. Learning to mod was supposed to make making packs easier, and in a way it did - I can build almost any mechanic I dream up now. But it also moved the goalposts. Every compromise I used to shrug at now looks like a detour around a problem I could just solve properly. So instead of finishing packs, I collect projects. Instead of playing the game, I maintain the tools that let other people play it.

And honestly? I wouldn't trade it. The three reasons above are exactly why: the source is right there in my IDE, one jar travels further than a folder of scripts, and I get to write in a language I actually enjoy. The trade-off is that the pack list in my head keeps growing while the packs themselves stay sketches.

So no grand resolution here. The paradox isn't solved, it's just documented - and now it's finally out of my drafts folder and onto the page.

🔭 What next?

It may come as a surprise, but I don't intend to write about modpack philosophy all the time. Honestly speaking, tracing how one hobby turned into another was worth doing once, but it's not the only thing rattling around in my head.

What I'm aiming to write about here is the stuff that's on my mind on a more day-to-day basis. I have a lot of niche interests - I research a ton of things for fun because I like the feeling of "falling into a rabbit hole". Some of it will be dev logs, some of it deep dives into tools and workflows, and some of it just whatever I couldn't stop thinking about that week.

So you may as well see this as the outlet for all the lingering thoughts I come across, loose ideas, or topics I have the urge to talk about. And if there's something in here you'd like me to expand on - the Kotlin and Catalyx side, the 1.12 maintenance grind, or how any of this actually gets built - the comments are open.

If this sounds like something you wanna follow along, I'm happy to entertain you. If you want something with more substance or structure, feel free to check out my other publications. Hope you have a nice day, and I'll be back later.

~ Enderman