search

packwiz / packwiz-installer

An installer for packwiz modpacks, with automatic auto-updating and optional mods! Works well with MultiMC and on servers.
https://packwiz.infra.link/
MIT License
54 stars 23 forks source link

Skip "failed file downloads" if a matched file exists #41

Open copygirl opened 2 years ago

copygirl commented 2 years ago

I figured a good way to get around some of the third-party download restrictions for my private modpack would be to just place the mods' .jar files in the mods/ folder along with the .pw.toml files. (Of course I only intend to do this for mods where I have the distribution rights or the license allows as such.) This way, I can have the client download the mod directly through the modpack, but also get the benefit of being able to check for and manage updates. And if I forget to update the .jar file when updating the metadata, I will get a "failed file download" message during testing.

However, packwiz doesn't download the .jar files before showing the "failed file downloads" message. (And that's reasonable, so you can skip the update altogether.) It would however be nice if it could not only skip mods that have been manually downloaded by the player, but also those that will be provided by the modpack directly. (Perhaps there is also a more elegant solution, but this is what I figured was most straightforward.)

comp500 commented 2 years ago

Hmm, I don't think it's a good idea to allow two external/internal files to "download" the same destination file (if they aren't mutually exclusive). Being able to attach update metadata to internal files would be cool, but adds a bit of complexity in the CLI, and means that mod jars are stored in the Git repository (which is bad for many reasons); I do wonder if an option to upload external jars to a server as an alternative download source would be a good idea?

I've looked into Git LFS before, and it might be possible to add support for it, for something native to the Git repository host. It'd be really cool to have a pack format based entirely upon Git smudge/clean filters so a simple git checkout will download the JAR files, but the APIs available don't really allow storing and matching metadata in an intelligent enough way for it to work cleanly.

copygirl commented 2 years ago

In this particular case I don't mind binary files being in the git repository - and I haven't even made this project into one. This is for a private pack running on a private server for friends. I just wanted something that works for now, without too much adding additional work involved.

Now that I had a night's sleep, something that might semi-resolve the issue as well is if the metadata files allowed for downloads from multiple sources if one were to fail. CurseForge if possible, otherwise over HTTP from our server. This could be useful in other cases too, but I understand it might require a more significant rewrite on packwiz' end.