[HowXu]

Summary

from #206 , which discusses some features for the users who do not have a good networks or for the situation that network not work well

This PR adds resumable installation for Modrinth and CurseForge modpacks, helping users avoid downloading completed files again when their connection is unreliable. And one new global setting, disabled by default, lets users keep incomplete instances automatically without dialog. Choosing not to keep the instance preserves the existing cleanup behavior.

Large scope changes

This feature involves one large scope of adjustment in launcher/modplatform/modrinth/ModrinthInstanceCreationTask.cpp and launcher/modplatform/flame/FlameInstanceCreationTask.cpp. I move the core download functions to the XXXInstallTask.cpp. I think if there is one class named XXXInstallTask, it should contains the code about download (but they are in the XXXInstanceCreationTask). Meanwhile, the download codes will be reused in the resume task.

If it's not suitable for the project, just tell me and I will do the modification

Test

Some simple tests

Manual testing of Modrinth and CurseForge installation and recovery was performed on Kali Linux, kernel 7.0.12, using Wayland with niri.

Keep

Unfortunately, this feature only implement for modrinth and curseforge modpack. other platforms are outside the scope of this PR. Platforms such as FTB, ATLauncher, and Technic use different manifests or installation workflows and require separate adaptations.

[so5iso4ka]

Couldn't we achieve the same goal by keeping the current behavior and caching modpack content instead?

[s0me1newithhand7s]

Couldn't we achieve the same goal by keeping the current behavior and caching modpack content instead?

+++
we wanna keep current behaviour

ed: stupid fucking idiot, absolute bafoon

[HowXu]

Couldn't we achieve the same goal by keeping the current behavior and caching modpack content instead?

uhh, my bad English makes me do not completely understand your lines. The behavior of this pr is: I add one dialog when abort download or the download was aborted by bad networks, If choose "Yes" meaning keeping the content we have downloaded, then the modpack will be cached and one new instance was also created. If choose "No", the content was dropped, just behave like recent.

So does the line above meaning, uhh, like defaultly keeping the modpack cache and create one new instance ?

Just tell me more details

[notwindstone]

Couldn't we achieve the same goal by keeping the current behavior and caching modpack content instead?

uhh, my bad English makes me do not completely understand your lines. The behavior of this pr is: I add one dialog when abort download or the download was aborted by bad networks, If choose "Yes" meaning keeping the content we have downloaded, then the modpack will be cached and one new instance was also created. If choose "No", the content was dropped, just behave like recent.

So does the line above meaning, uhh, like defaultly keeping the modpack cache and create one new instance ?

Just tell me more details

He was saying that the solution to the problem might be more simple - just keep the downloaded modpack files in a shared cache folder. if something failed, the cached modpack files will be still present, and following retries will download only those files that are absent from cache

[notwindstone]

Couldn't we achieve the same goal by keeping the current behavior and caching modpack content instead?

uhh, my bad English makes me do not completely understand your lines. The behavior of this pr is: I add one dialog when abort download or the download was aborted by bad networks, If choose "Yes" meaning keeping the content we have downloaded, then the modpack will be cached and one new instance was also created. If choose "No", the content was dropped, just behave like recent.

So does the line above meaning, uhh, like defaultly keeping the modpack cache and create one new instance ?

Just tell me more details

He was saying that the solution to the problem might be more simple - just keep the downloaded modpack files in a shared cache folder. if something failed, the cached modpack files will be still present, and following retries will download only those files that are absent from cache

probably need to clarify as well these things:

• no need for the dialog - so yes, treat it as "by default, keep the downloaded files"
• the proposed implementation keeps downloaded modpack files in the instance folder instead of the cache folder, independent of instance

[HowXu]

Then I get.

Thanks a lot

[HowXu]

some more details needs discuss below:

Where to keep the files already downloaded? Typically when install one mod pack, there will be modpack files(almost be downloaded from one single archive, and unzip, this will always keep stable), download mod files. The game sources download have already been cached.So what we care is the mod downloaded. In recent implement, I record one another manifest cut from the modpack mainfest, then the download will always be started if the files in the cut json do not be done. the downloaded mod files will directly send to the modpack instance's mods folder.

One more thing, if my understanding is right, after any abort of the modpack installation, there will always be one new instance?(so users can decide whether to delete) Or manage one another cache folder for the aborted instance? I do not suggest the second because we must control how to clean the cache, when to clean the cache and if the user restart the installation, we need check whether it's continuation or new installation, and even so more(but if it's better for the project, I will try my best).