Project Sanity

For lack of a better name, the goal here is to identify why writing Minecraft mods makes me feel stressed/upset, and then address those problems. Hopefully this will make me more excited to write Minecraft mods in the future.

Performance problems

I can address A by killing ModDevGradle and installing Forge with binpatches, which I am attempting in InstallerToolsRuntime. Early results are promising; it takes about 60 seconds to install Forge like an end-user, compared to ~11 minutes to let ModDevGradle chug.

I can address A and B by using a monorepo to hold the source to all my mods. This means I only need to set up O(version support × loader support) minecraft workspaces, not O(version support × loader support × mods).

I can try and address C by configuring a JDK like DCEVM or JetBrainsRuntime, which has better support for class redefinition. This should allow “hot swap” to work in more situations. I can also make sure appropriate performance mods are in my development environments where relevant (maybe lazydfu).

Friction

I could solve D using a library mod. However I would not enjoy needing to keep it in-sync with my main mod or foisting that complexity onto users. Also, I like the ability to easily change the library; I noticed splitting Zeta off from Quark kind of killed its development momentum.

I experimented with solving D in modfest-oneoffs by writing a library which exists in the same repo as the other mods, and gets shaded into all jars using it (although I went back on the shading trick before Modfest, to avoid creating complexity right before the event).

I solved E in modfest-oneoffs by using a “one mod per source set” approach. This meant I could easily spin up a new mod by creating a new source-set and copying over a few fabric.mod.json files. I could hopefully generate even more files automatically and automate more things from the buildscript.

Just don’t like it

I can solve F by simply dropping support for some versions and loaders. I could look at CurseForge and Modrinth download statistics to find which versions people don’t seem to care about.

I can solve G by finally setting up automatic publishing.

Monorepo design

Normally I write multiloader where you have two “axes”, minecraft version and modloader choice. Moving to a monorepo means “the mod” becomes a third axis.

Due to limitations in Minecraft plugins I need to make “vanilla 1.x”, “fabric 1.x”, and “forge 1.x” entirely separate Gradle subprojects. It should be fine to do one mod per source-set within those subprojects.

Wrt run configs, i would like the ability to make one giant run config containing all the mods at once, and/or smaller run configs containing just one mod at a time

In modfest-oneoffs, my shading setup for Loom was like this https://github.com/quat1024/modfest-oneoffs/blob/1bc756d43b86a56e573fcf11787a4456e3ca7b02/build.gradle#L65-L110 . I never wrote anything like that for neoforge so I’ll have to puzzle out how MDG works

Action items!