- Get Project: Already existed but required a specific caller type. This
is more general.
- Get Projects: A single call to multiple of the above
Both providers support these calls.
Signed-off-by: flow <flowlnlnln@gmail.com>
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)
Moves all things related to creating the URLs of the mod platforms
that go to network tasks to a single place, so that:
1. Maintaining and fixing eventual issues is more straightforward.
2. Makes it possible to factor out more common code between the
different modplatform pages
