🛠️ Modpack Creation Studio (mod grouping and mrpack repositories)

[SalmonSnaked]

Table of contents

	1. Introduction
		- Briefly explains the root issue and first proposition.
	2. Explaining the Modpack Studio
		- Describing the general purpose, functionality, and need for a Modpack Studio.
	3. Breakdown of content repositories
		- Clarifying the nature of content repositories.
	4. Implementation of branches
		- Explaining the benefits of repository branches.
	5. Instances from repositories
		- Showing how instances built from repositories work.
	6. Indexed content repositories
		- Proposing a feature to index repositories in an extended mrpack format.
	7. Key takeaway
		- Summarising the point of having a Modpack Studio.

---

Introduction

• Modpack developers should be given more powerful tools to update, manage, and deploy modpacks within the Modrinth App. Currently, things can get really messy with large modpacks that modify several areas of the game. Trying to focus on one task, for example finding all structure generation mods in a modpack, is impossible without getting distracted by several unrelated projects while scrolling the long mod list. You have to realise how beneficial the ability to categorize the mods of a modpack into distinct groups could be. It would allow creators to atomically assess one group at a time and make changes much cleaner!

🛠️ Explaining the Modpack Studio

• Although the feature to group mods inside an instance would allow it to be managed and expanded with ease, creating new instances would still require time installing and grouping the desired mods. This problem is brilliantly solved with the Modpack Studio. In all simplicity, the Modpack Studio allows you to create mod groups as template building blocks for the creation of modpacks. It's essentially a repository store outside of instances, containing different bundles of mods you created, which you can freely pick and combine when building a modpack.

• The main features of Modpack Studio are creating content repositories and building instances with those repositories. A content repository defines a specific set of mods (or any projects) and optionally their configurations. When you create a new instance, you can select to "Build from repositories" and then pick compatible repositories whose content you want installed to your new instance. This approach to creating instances will save so much time from repeatedly adding the same mods, especially when leveraged into larger setups where a modpack could consist of several modules!

• This is a rough depiction of the Modpack Studio page. It demonstrates how content repositories display their content statistics and supported version for the currently selected branch.
• This page should contain the same filtering, grouping, and searching capabilities as the regular instance library, as well as a button to create a new content repository.

The need for a Modpack Studio

• To understand why a feature like this would be so important, let me tell you my personal use case. I have multiple ever-expanding categories of mods which I'm having trouble keeping in normal instances or documenting in text files. These categories could include boss fight mods, creative utilities, visual enhancements, and so many more! Keeping all of these installed in active instances is a mess, keeping external notes for each Minecraft version is also a mess, but categorizing them in the Modpack Studio would not be a mess!
• The bigger your modpacks become and the more you have to maintain modpacks, the more you will realise how insanely effective a feature like this could be. I personally have arrived at a stop in my modpack development, since the current tools simply do not favor scalability. And before someone says GitHub already exists, I'll mention how those workflows could never compete with the integrated and accessible nature of a Modpack Studio like this.

---

🗃️ Breakdown of content repositories

• Although content repositories are used for completely different purposes than usual instances, they are created and managed almost exactly the same way. The only notable difference is that content repositories can't launch the game, since they only store data.
• So in essence, content repositories are just small static modpacks, which means that the fully established mrpack format can be used to export and import content repositories.
• Since the mod list of a content repository might also get messy, it wouldn't hurt to include categorization here as well.

📑 Implementation of branches

• You can create branches for a content repository, which allow you to have multiple different repositories under the same title. A typical example of this would be having two branches 1.21.1 and 1.21.4 for the content repository "Optimization mods", each with their own mod versions and configurations.
• These branches would allow you to neatly organize and update your content repositories, as opposed to having different repositories for every Minecraft version and modloader. Each branch will be stored under its own folder ModrinthApp/repositories/<repository>/<branch>.
• When creating a new branch, you may choose to either start from scratch or mirror one of the existing branches in the repository. Mirroring would retrieve compatible versions of each project and install those to the new branch. Incompatible projects would still be copied to the new branch but disabled.
• When you try to install or remove any content from a branch, it will ask whether you also want to install or remove this specific project from the other branches of this content repository. This pop-up has a checkbox list with all branches selected by default. The checkbox list should clearly indicate which branches have a compatible version available and which do not.

This is what a content repository looks like. It looks very much like a regular instance, but you don't have the ability to launch the game here. These repositories are essentially mini-modpacks, which you can combine with others to create the perfect instance you want.

📥 Instances from repositories

• When creating an instance and choosing to "Build from repositories", you'll first select the Minecraft version and modloader. After this, you will see a checkbox list of all the available branches across every content repository that match your specified versions. After selecting the desired branches, you can build the instance.
• If multiple selected branches modify or include the same mods or content, the user will be prompted to choose which one gets priority. You could also predefine a weight priority for branches or specific projects within them, making the merging of multiple branches mostly unattended. Configuration files should be able to merge instead of only letting one branch win.
• Updating repository-built instances' content is very clean and centralized. You only need to change the upstream branches, and all linked instances will automatically synchronize the changes. This will unlock the ultimate workflow for modpack developers: no longer do you need to keep track of mod versions across a plethora of instances, since everything is controlled from one place.
• And if it wasn't clear, no changes made in a repository-built instance will be reflected in the upstream content repositories. This is crucial to maintain authority in the Modpack Studio.

• The branches you used to build an instance with will automatically be grouped and placed in the "Repository content" pop-up, which opens by pressing "View content". This menu allows you to expand the content list of each branch you're using, manage per-instance overrides, and open the respective branch pages.

ㅤ

• This instance has been built with 4 branches and is currently using 3 of them. Two mods under "Utility mods" and the whole "Creative tools" branch have been disabled as instance-specific overrides. The disabled content will simultaneously stay disabled and get updated with the new assets pushed from the upstream branch.
• Aside from just disabling/enabling individual content or entire branches in this "Repository content" menu, it should also include actions to completely remove, include new, change existing, and unlink branches of your instance.
• Explicitly unlinking a specific branch from this pop-up will move its content to the regular content list (and keep it grouped), but this content would no longer be synchronized.

ㅤ

• You may completely unlink your instance from the repositories you were using. This would move each repository-provided branch into the regular content list (while keeping them grouped), but they would no longer be synchronized.
• You could also rebuild an instance from the repositories you have installed. This would remove all content you have added on top and reset the instance to the state defined by repositories, also resetting instance-specific overrides.

📁 Indexed content repositories

• Modrinth App could save disk space by storing content that's hosted on Modrinth as index files instead of full assets. This is possible because content repositories are static images that do not need to include the full assets to launch the game.
• The directory structure of an indexed branch looks exactly like a regular branch, with the only exception being that the Modrinth-hosted files are small metadata JSONs in place of the whole projects.
• In practice, indexed branches would usually have their mods folder populated with JSON files that define the download URL and other metadata for the actual JARs. When the user wants to create an instance from indexed branches, the Modrinth App would then download the full assets to the created instance, based on the index files' instructions.
• Traditional mrpack files group all Modrinth-hosted content into a single modrinth.index.json file, but the parsing of mrpacks should be expanded to support a format where independent files can also work as indexes. This would make it much easier to manage an indexed content repository without relying on the Modrinth App UI.

---

Key takeaway

• Since these repositories are just modpack template files after all, people could use the Modpack Studio to store anything from a mod category exclusive for tick optimizations to an entire modpack. The point is to use this studio to have granular control over which "modules" your new modpack would include and to propagate updates from a centralized system. Regardless of the use case, this would make mapping the modding scene much cleaner and allow you to manage large projects with ease.

[SalmonSnaked]

Issues to be merged here:

• Content filtering by project tags in instances #1190
• Manual content groups within instances #4234
• Folder/Collection Mass Update Suggestion #6486
• Being able to see the genres of mods in our modpack content #6538
• Mod Grouping inside a Profile #7284

I thought it would be reasonable to count these suggestions as ones to merge here, as my idea only briefly touches on the concepts proposed in these suggestions and uses them as the starting point for a completely different system.

[Prospector]

this sounds rather out of scope for Modrinth app. we of course, plan to make it easier to create and publish modpacks within the app, but that would be by making instances better, not making another system like is being proposed