This prevents custom names from being lost when updating, by only
changing the name if the old instance name constains the old version,
so that we can update it if the user whishes to.
Signed-off-by: flow <flowlnlnln@gmail.com>
This makes it harder for problems in the updating process to affect the
current instance. Network issues, for instance, will no longer put the
instance in an invalid state.
Still, a possible improvement to this would be passing that logic to
InstanceStaging instead, to be handled with the instance commiting
directly. However, as it is now, the code would become very spaguetti-y,
and given that the override operation in the commiting could also put
the instance into an invalid state, it seems to me that, in order to
fully error-proof this, we would need to do a copy operation on the
whole instance, in order to modify the copy, and only in the end
override everything an once with a rename. That also has the possibility
of corrupting the instance if done without super care, however, so I
think we may need to instead create an automatic backup system, with an
undo command of sorts, or something like that. This doesn't seem very
trivial though, so it'll probably need to wait until another PR. In the
meantime, the user is advised to always backup their instances before
doing this kind of action, as always.
What a long commit message o.O
Signed-off-by: flow <flowlnlnln@gmail.com>
These help us keep track of relevant metadata information about
overrides, so that we know what they are when we update a pack.
Signed-off-by: flow <flowlnlnln@gmail.com>
While working on pack updating, instance naming always gets in the way,
since we need both way of respecting the user's name choice, and a
standarized way of getting the original pack name / version.
This tries to circunvent such problems by abstracting away the naming
schema into it's own struct, holding both the original name / version,
and the user-defined name, so that everyone can be happy and world peace
can be achieved! (at least that's what i'd hope :c).
Signed-off-by: flow <flowlnlnln@gmail.com>
This allows us to create other resources that are not Mods, but can
still share a significant portion of code.
Signed-off-by: flow <flowlnlnln@gmail.com>
Even though it was using a QMutableHashIterator, sometimes it didn't
work quite well, so this is a bit better.
Signed-off-by: flow <flowlnlnln@gmail.com>
Don't update disabled mods to prevent mod duplication. Also, chop
filename in the metadata with a '.disabled'.
Signed-off-by: flow <flowlnlnln@gmail.com>
- 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>
This makes the metadata generation code a lot messier and harder to use,
but there's not really much else that can be done about it while
preserving all it's capabilities :(
At least we now have speed
Signed-off-by: flow <flowlnlnln@gmail.com>
This is, in many cases, more reliable than name comparisons, so it's
useful specially in cases where a mod changes name between versions
Signed-off-by: flow <flowlnlnln@gmail.com>
This subclasses the Review mods dialog to make a "Update review" one.
Also, all the necessary components built until now are put together in a
coherent unity that checks and generates metadata on-the-fly and checks for
mod updates, while giving and receiving feedback to the user.
Signed-off-by: flow <flowlnlnln@gmail.com>
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>
This task is responsible for checking if the mod has metadata for a
specific provider, and create it if it doesn't.
In the context of the mod updater, this is not the best architecture,
since we do a single task for each mod. However, this way of structuring
it allows us to use it later on in more diverse scenarios.
This way we decouple this task from the mod updater, trading off some performance
(though that will be mitigated when we have a way of running arbitrary tasks
concurrently).
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>
* Use the bulk endpoint on mod resolution for faster download
* Search on modrinth for api blocked mods
* Display a dialog for manually downloading blocked mods
Often times, mods can have their name in different forms, changing one
letter to caps or the other way (e.g. JourneyMaps -> Journeymaps).
This makes it possible to find those as well, which is not perfect by
any means, but should suffice for the majority of cases.
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
Shows a more helpful message if there's a parsing error when reading the
index file.
Also fixes a clazy warning with using the `.data()` method in a
temporary QByteArray object.
We have been asked by CurseForge to remove this workaround as it
violates their terms of service. This is just a partial revert, as the
UI changes were otherwise unrelated.
This reverts commit 92e8aaf36f, reversing
changes made to 88a93945d4.
Sometimes, the version field, that is supposed to be a string, was a
null instead. Inspecting other entries, seems like the default for not
having a version should be "", so I made it like that in case the
version was null.
I hope this fixes the issue :^)
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)
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
Fixes#206 partially. Although we don't list mods that have no
compatibility with the mod loader we are using, mods that have support
for both loaders still show up, and the versions for both the loaders
are still shown.
Also simplifies a little the logic in
FlameModIndex::loadIndexedPackVersions
