Those tasks take a list of mods and check on the mod providers for
updates. They assume that the mods have metadata already.
Signed-off-by: flow <flowlnlnln@gmail.com>
The Modrinth changelog is fairly straight-forward, as it's given to us
directly with the API call we already did. Flame, on the other hand,
requires us to do another call to get the changelog, so it can introduce
quite a heavy performance impact. This way, we make it optional to get
such changelog.
Signed-off-by: flow <flowlnlnln@gmail.com>
Calls added:
- Get version from hash
- Get versions from hashes
- Latest version of a project from a hash, loader(s), and game version(s)
- Latest versions of multiple project from hashes, loader(s), and game version(s)
Some of those are not used yet, but may be of use later on, so we have
it if we need it :)
Signed-off-by: flow <flowlnlnln@gmail.com>
Prevents a massive inload of Scrumplex ditto's :)
I didn't add it to every file modified in this PR because the other
changes are pretty minor, and would explode the diff of the PR. I hope
that's not a problem O_O
Things that don't work / work poorly (there's more for sure but those
are the evident ones):
- Icons are broken in the import dialog
- No way to search for private packs
- Icons are not downloaded when downloading a mod
- No support for multiple download URLs
- Probably a lot more...
Right now we want to include Fabric mods in our searches where possible.
Modrinth allows definining multiple loaders, while Flame only allows a
single value.
As a compromise we ask for Fabric mods only on Flame and for both Fabric
and Quilt mods on Modrinth.
This uses more arguments in the GET request for mod versions on the
Modrinth API, filtering what versions can be returned, decreasing load
on Modrinth servers and improving a little the time it takes for the versions to be
available to the user.
This also removes the now unneeded check on correct modloaders in
ModrinthPackIndex, since it is now filtered by the Modrinth server.
Lastly, this adds a couple of helper functions in ModModel.
The checks used are roughly the same as the ones proposed in the
clang-tidy PR (except perhaps that I used modernize-* instead of listing
them individually,though I don't think this caused any readability
detriments).
In ModrinthModel.cpp and FlameModModel.cpp I ignored the
modernize-avoid-c-arrays one, mostly because making the sorts array an
std::array would most likely increase the code complexity because of the
virtual function. Aside from that, the static_cast warning from
Application.h was not dealt with, since it's not in this PR's scope.
This is done so that 1. ModAPI behaves more like an actual API instead
of just a helper, and 2. Allows for more easily creating other mod
providers that may or may not use network tasks (foreshadowing lol)
