FO actually has a development workflow based on the scripts located in the "CLI tools" folder. These scripts are themselves based on independent tools, like multimc-export and packwiz.

We can note that many people fork FO. Some for helping its development, others just to make their own Modpack based on it. But FO scripts are not made for that. It's not an easy task for beginners to adapt the script and the environment of FO.

On my side, I already received some demands for python scripts to help with modpack development.

A good solution to all these problems would be to create a development environment for modpacks that FO, but also most of the modpacks could use.

An idea of the features that would be great:

• Be able to develop from any base (FO actually uses CurseForge as base for adding mods)
• Be able to convert to any format (CurseForge, Modrinth, Packwiz, and others)
• Be able to have multiple versions of the same pack (Example: with or without a mod/configuration/included resource pack/other)
• Be able to integrate more steps like verifications, virtual steps (for example, when the user have to export a CurseForge instance manually), file manipulation ect...
• Be able to work in collaboration without conflict

To sum up, a modular tool to create modpack using a workflow paradigm.

In details, how I imagine the workflows for now:

• A command line tool that makes it possible to execute a workflow
• A workflow is defined by a .json file containing a list of steps and a configuration, and can be created/edited to fit any need
• Steps are classes inheriting from an abstract Step class. Like that, it's easy for anyone to create their own steps
• Steps may have a different abstract class inheriting from the first one that will make them easier to develop and use (format converter, verifier, wait user action ect...)

For the main Workflow of FO manage the update and the convertion of the pack, the steps could be:

• Updating the version in CurseForge (direct action on the file, basic step)
• Export CurseForge version (step that wait for the user to export the pack)
• Convertion to MultiMC (converter step)
• Ect...

But another workflow that could fit FO could contain an action that prepare a next update. An example of what these steps could do:

https://github.com/Brancieq-Paul/mod-update-list

In the end, this tool could make it easier to create a new mod pack for beginners while providing a freedom of customization for advanced users.

Made a repo https://github.com/Fabulously-Optimized/modpack-creator and we've agreed upon Brancieq first forking and making a feature-complete alternative for current scripts and then, if all goes well, will get full access and contributor :)

A "little" update on the development.

First, what this post will be about: until now, I developed a workflow system, and even if it works, I realized that it's not that great, it would need at least as much working time as what I have provided so far to make it better, and maybe I got the priority wrong.

So I decided to take a step back and summarize my thought here, and explain where I decided the project would go from now.

The following spreadsheet will help you to visualize the explanation:

*: in brackets: potential but need more work

The idea I originally described is too complex and focuses more on the workflow system and concepts abstraction than modpack development, which should be the main focus.

The new idea is to use a task paradigm, a command line tool that proposes different actions, a little bit like FO have multiple scripts.

The basic tasks that apply to all modpacks will be built-ins with the tool, offering a basic way to develop a modpack for beginners. Specific tasks will be addable directly in the modpack project directory. (Examples: the task for updating FO display version, which depends on a specific mod (isxander-main-menu-credits)).

The tasks will be easily configurable depending on the project and the user machine (paths to curseforge and MMC, files to include or exclude when exporting...).

The most important: it will be lighter for me to develop and maintain. It was a bad idea to make a complex thing from the beginning, and I prefer to begin simple, see if anyone uses it and send feedback, use it myself to see what is missing and what is useless, and then improve it if needed.

What's the status of this?

Alright, no problem. If you'd like, you can contribute to the existing scripts to fix or improve something (note the meta issues).

Hey !

So I must update the status of this project. I'll go straight to the point: I think it will never be finished.
I don't think it's impossible to do it. But there are different facts that discourages me:

• I wanted a simple and modular tool. But modularity add complexity.
• The state of the minecraft modding community (Curseforge doing... Curseforge things, Modrinth becoming more and more popular), things change fast, and it's hard to keep up.
• Multiple tools already exist for modpacks, and I find it easier to create a simple script for my own if I need it than creating a new "task", ensure that it work with the tool api ect...
• Finally, the time I don't spend of this tool, I can use it to work on other smaller tools ot mods for my modpack

Sorry for the expectations that I did not meet.