init commit

This commit is contained in:
2026-06-03 12:00:20 +08:00
commit 5c5da072b4
+56
View File
@@ -0,0 +1,56 @@
# PackWeave requirement analysis
## problem
Nowaday, the modpack of minecraft is a vary developed field, we can see a lot of excellent modpack in curseforge or modrinth. However, the develop of a minecraft modpack is not a very standard and engineering work now. Many peopel consider that modpack just integrate the mod together. But actually, the modpack will use tool like kubejs to make their own modified and they have too process the confilct between different mod. Therefore, the modpack develop is a entirally 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 while 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 do so -- the packwiz. It create a format to discribe to modfile in modrinth or curseforge. But packwiz is not engouth, it can only export the modrith or courseforge 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 nesseary 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 solve 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 define, the tool should sync the change to the game client in an incremental and high performance way. Beside, many mod will create extra file in the root directory, and the tool should sync the nessary file of this to the modpack project.
To inplement 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 park of 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 can make the IDE better than others in community and it is also unnessary in such a tool.
Another the way is divide them into two parts. Use the project file to generate client also increment in other 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 courseforge to generate 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 exsist modpack as dependency. By this way, the project can import the nesseary mod group by one line and concerate on their own idea.
we can also create many mod group by a topic(eg. magic,technic), and the develop can easily intergrate the scheme.
The key problem is the format to reuse. If we want to use the exsist modpack in modrinth of courseforge as dependency, we should change it to our format. And except for the modlist, there must be a lot of the author's own modifition of the modpack, the key is how to process the conflict between different modpack.