back in late june, i was messing around in prism launcher, when an idea came into my mind; i wanted to make a Minecraft modpack, just to figure out the needs of modders and modpack makers for whatever future projects i had in mind. i did not realize at the time just how much work goes into doing so, and just how cursed minecraft gets. this is a warning tale. enjoy!

the beginning

the initial idea for the modpack was clear from the start - i wanted to make a vanilla+ experience that focused on quality over quantity, picking smaller but higher quality mods and putting the spotlight on brand new and lesser known mods, all exclusively from Modrinth (no janky extra downloads here!). i also decided to go with the then recently released 1.20.1 version, not just to highlight the previous points but also because i was tired of all the packs being on 1.12 or whatever.

the initial lineup didn’t get shuffled around much throughout the pack’s development. it included all the classic performance mods, some minor single-tweak mods and some more major block and biome mods. i initially planned to replace advancements with a questing tree system, but obviously the closed off FTB ecosystem wasn’t available on Modrinth. fortunately, TerrariumMC partnered up with Modrinth and released their own set of alternatives, including a questing mod called Heracles literally days before i started working on my pack. unfortunately, it was extremely broken on release. i then proceeded to take a multi-day detour to thoroughly debug it, filing just over 20 issues on the project’s repo, with ThatGravyGuy dutifully squashing them all one by one. the mod was relatively stable after a week! then i proceeded to ditch it and just use advancements instead, sorry!

there was one key difference in my initial approach; i wanted to modify the game’s progression to be a bit more engaging than a mad dash for diamonds. i wanted to make a mod which forced you to use a refiner block to make iron (and above) by combining it with quartz, which before gaining access to the nether you’d need to find in loot chests as you explored the world. entering the nether, as well as the end was also gated being major milestones such as defeating bosses and completing difficult advancements. in order to implement that, i had to make a mod of my own. small problem - i had no idea how to work with java!

even after i watched Modding by Kaupenjoe’s tutorials, i found the task of making a GUI for the block too daunting, and i didn’t even know how to properly deal with stuff like registries yet. ultimately, this caused me to drop the pack for the time being. it would take a few months before i picked it up again.

the reboot

at the very end of october, i wanted to take a short break from working on Collective Unconscious. i foolishly turned my gaze upon that tempting little modpack icon in my launcher - and so, i got back to work. firstly, i got to grow the mod list with mods that were released for the version since then - 1.20.1 became the new big modding version after 1.19.2, since Mojang broke some major stuff in 1.20.2 and modders were tired of changing half of their mods to comply with the constant unexpected changes (quaternary has an excellent blog post about this phenomenon). i also started to do what really separates a mod list from a modpack; compatibility tweaks. unfortunately, this is where working with Minecraft starts to become annoying at best and a nightmare at worst.

the good, the bad and the worldgen

some things in Minecraft are stored using “datapacks”, giant smorgasbords of JSON files that can modify advancements, crafting recipes, loot tables, worldgen settings (within tight confines), tags (not to be confused with the hardcoded registries, which are used whenever a dictionary is needed over a list of stuff, despite JSON having dictionaries), structures (good luck getting these running right) and probably some more stuff nobody bothers with. it’s a great system on paper, but it’s limitations and frustrating decisions make it a pain in the butt to deal with (a common complaint from here on out).

while making advancements and crafting recipes wasn’t that much of an issue, working with worldgen was nothing but an uphill battle. most annoyingly, you can only replace entire files (except for tags, which have a unique option for it, but don’t get read half the time, and invalidate the entire tag if you add an entry for something that doesn’t exist) which means that any mod features and structures get completely overwritten. fortunately, you can find mods which offer a patch file system which were instrumental in making sure i don’t have to write files for every biome.

during the process of adding various modded features to all the biomes for consistency’s sake, i noticed that my game started to crash on occasion. i thought nothing of it at first - i assumed it was freaking out because i changed the datapack on a live save. it was only when i tried to make a full world to test my changes when i realized something went horribly wrong. something was breaking worldgen, and i had no clue what it was! the error messages were extremely cryptic, citing a “feature order cycle” or whatever. i looked it up, and i found a page explaining the bug and pointing to a mod called Cyanide (made by the dev of TerraFirmaCraft, small world!) which improved worldgen error handling. i didn’t even bother reading the page and downloaded the mod right away.

unfortunately, Cyanide is made for developers making standalone datapacks, and so, what Minecraft would usually let slide, it treats as an outright error. and it just so happens that in the fervor of random changes, Mojang removed the music.overworld.jungle_and_forest sound effect (sound effects are used for music as well), and nobody really noticed it. i had to go over all my installed mods and patch the jar files to remove it. after way more work that was necessary, i finally got to see the error message i was looking for. it seemed to be something about the order of features? then i went back to the article, and realized what it meant:

if two completely unrelated features are added in a different order in two unrelated biomes, the game will refuse to work.

why is that a thing? in what world would even acknowledging this be convenient? what kind of nightmarish worldgen bug, if it wasn’t just pure stupidity, would necessitate this? unlike some of the other annoyances like tags wiping themselves when coming across invalid entries, there is no mod to fix this. since i was working with simple patches, and since fabric has no mod load order by design (this is extremely stupid as well and will come up later), i had to figure out a solution. ultimately i just copied out the features i wanted to use to a separate spot in the datapack. it worked, but it was the time when i realized the game itself is working against me.

draw the rest of the owl

for a while, things went surprisingly smoothly - save for a few strange occurrences and the occasional mod conflict (special mention to the three-way conflict between ElytraTrims, C2ME and FancyMenu). i got a good hang of working with FancyMenu and CraftTweaker, arguably some of the most important tools in a modpack maker’s toolbox. the latter allowed me to work around some of my issues with registries and easily remove crafting recipes without annoying error messages in the logs, and EMI had an easy way to block items in it. i’d later find Item Obliterator which made the entire process far smoother, and also dealt with creative mode tabs.

however, not everything can be done with tweaker mods and datapacks - namely, adding blocks. i initially toyed around with the idea of using KubeJS for it, but it had too much feature overlap with CraftTweaker to be worth it and it couldn’t even handle the task of making a block that can only be placed on a full block without delving into a crop API or using the janky and costly reflection functions. i couldn’t get around it this time - i had to make a mod.

fortunately, since then, i’ve started learning rust, which got me to understand some java concepts a little better, as someone coming from just python. some blocks were simple to add code-wise, but some were a little trickier to get working in the same way their counterparts did. case in point, Wilder Wild’s hollowed logs - blocks with special hitboxes and a bunch of other features to keep track of. i wanted to directly use the code they used to generate them, but the function was marked as private. i decided to ask around to see if there was anything i could do about this - and to my surprise, i actually got a response from the devs of Wilder Wild, Treetrain1 and Luna (AViewFromTheTop)! with their help i was able to debug some odd issues, make the hollowed logs and properly add them to the registries (remember when i said Fabric’s lack of mod load order would hinder me? there’s ways to get around it. crafttweaker’s registry functions could only get me so far…).

ultimately though, the biggest hurdle was drawing all the textures. i was already worn out from working on the pack since i had Collective Unconscious work to do, and constantly had to manage conflicts in an ever growing mod list. so, when one of the mods updated and broke compatibility with another one of the mods that hadn’t been in active development anymore, i decided to do the wise thing and simply drop it. anticlimactic, i know, but at the end of the day it’s always best to drop a side project if it’s going too far.

conclusion

the answer to the question “what should i do to make a modding ecosystem that’s good for users, modders and modpack makers” is apparently “you can’t do worse than Minecraft unless you really try”. between modders having no trust in the developers, inconsistent and broken customization functions that have to be worked around with mods and having to deal with java (okay, that last one’s opinionated, but you can’t pretend that maven isn’t a nightmare to work with, and slow to boot) Minecraft’s a bit rough around the edges.

over the entire process i sent a combined total of 84 github issues (meta issues in my own repos and issues filed on discord servers not included), and the prism launcher instance i constructed the pack on reached just under 198 hours of playtime (though it may have been more, as i experienced a minor drive corruption that broke at least one of my other instances. thanks, windows). it definitely was an experience and i don’t know if i’ll do it again, but it was worth a shot anyways!

had i released the pack, i’d put a link to it here. instead, i guess you could listen to its main menu theme. i think it turned out pretty great!