# PackWeave requirement analysis

## problem

Nowadays, the modpack of minecraft is a very developed field, we can see a lot of excellent modpacks in curseforge or modrinth. However, the development of a minecraft modpack is not a very standardized and engineering work now. Many people consider that modpack just intergrate the mod together. But actually, the modpack will use tool like kubejs to make their own modifications and they have to process the conflict between different mod. Therefore, the modpack development is a entirely software engineering project. And most importantly, when there are more than one person to develop a modpack, it is hard for them to use version control tools like git. Because, when the mod loader load mod, it directly load the .jar file, and the most of the launcher just download the .jar file and use the metadata in .jar. Someone choose to push them to github, however, these .jar will occupy too much storage. What's more, if the repo is public, it is an actual distribution which may violate the eula(although the eula is useless like sand, but I still want to try to obey it as possible as I can). 

If we design a file format which can describe the metadata of a mod file, process the dependency of it, and this file is simple and small, we can easliy solve the problem. Actually, someone has done so -- the packwiz. It creates a format to discribe the modfile in modrinth or curseforge. But packwiz is not enough, it can only export the modrinth or curseforge format and use launcher to import. If we want to use it to develop, we can only use packwiz serve, and use a start hook for game client to load the mod. I think generating a real client file is necessary for develop the modpack. Therefore, I decide to implement this and add new feature.

## requirement analysis

### 1. use a text format to represent the .jar file of mod

the problem have been solved by the packwiz, so we just need to adapt the format of the packwiz

example

```toml
name = "Just Enough Items (JEI)"
filename = "jei-1.21.1-neoforge-19.27.0.340.jar"
side = "both"

[download]
url = "https://cdn.modrinth.com/data/u6dRKJwZ/versions/YAcQ6elZ/jei-1.21.1-neoforge-19.27.0.340.jar"
hash-format = "sha512"
hash = "8bad8eb3c8e974f867e23e4d74598f603c5fbf03eb5356a386dd37cb9fa23e08ad1f58be6b7be50d2fbf9d3fbfaeac8584c70ced736df4b8f82c7c75be242998"

[update]
[update.modrinth]
mod-id = "u6dRKJwZ"
version = "YAcQ6elZ"

```

However, in some modpack, there may be other mod which don't update to modrinth and curseforge or create by the modpack author. So, the format should have a way to process them.

### 2. generate the project to real minecraft client

this is the key feature of this project. the PackWeave should have the ability to download the minecraft core jar and the mod loader, for every change of the modpack definintion, the tool should sync the change to the game client in an incremental and high performance way. Besides, many mods will create extra file in the root directory, and the tool should sync the necessary files from this to the modpack project.

To implement this, we can make the project in the same directory with the client and use .gitignore or other ignore technic. So that the project just need to process the part of the project and the other file will create in the same path with the project. The way is the same with the Tritium-Launcher, but we don't create the editor and lsp. We could make the IDE better than others in the community and but it is also unnecessary in such a tool.

Another way is divide them into two parts. Use the project file to generate the client also incrementally in another path. The benefit is to divide the runtime environment and develop environment.

### 3. export and import the pack format

Another key feature is to support the format of curseforge and modrinth. The tool should have the ability to import the modrinth or curseforge to generate a format like the packwiz

### 4. the modpack reuse

this is the most innovative feature of this tool. In most of the modpack, some mods will always appear, like the jei. This mod is the useful and universal mod. There is no doubt that we will add them to modpack. Therefore, we can make this progress more convenient by the reuse. 

This feature make the modpack can import other existing modpack as dependencies. By this way, the project can import the necessary mod group by one line and concerate on their own idea.

we can also create many mod group by a topic(eg. magic,technique), and the developer can easily integrate the scheme.

The key problem is the format to reuse. If we want to use the existing modpack in modrinth of curseforge as dependency, we should change it to our format. And except for the modlist, there must be a lot of the author's own modification of the modpack, the key is how to process the conflict between different modpack.