This checks the URL of the path of the file to be downloaded,
ensuring that it always contains the root .minecraft target folder,
following the warning in the mrpack documentation.
Signed-off-by: flow <flowlnlnln@gmail.com>
This turns issues like creating two shared ptrs from a single raw ptr
from popping up at runtime, instead making them a compile error.
Signed-off-by: flow <flowlnlnln@gmail.com>
The spec says that this can be null, and indeed some mods have it set to
null, and should still be considered as valid.
Signed-off-by: flow <flowlnlnln@gmail.com>
This prevents a crash in which the pack list gets updated in a search
request meanwhile a versions / extra info request is being processed.
Previously, this situation would cause the reference in the latter
callbacks to be invalidated by an internal relocation of the pack list.
Signed-off-by: flow <flowlnlnln@gmail.com>
This refactors the sorting methods to join every bit of it into a single
list, easing maintanance. It also removes the weird index contraint on
the list of methods by adding an index field to the DS that holds the
method.
Lastly, it puts the available methods on their respective API, so other
resources on the same API can re-use them later on.
Signed-off-by: flow <flowlnlnln@gmail.com>
This makes it so that we don't need a reference to the parent page in
the model. It will be useful once we change the page from a widget-based
one to a QML page.
It also makes tasks be created in the dialog instead of the page, so
that the dialog can also have the necessary information to mark versions
as selected / deselected easily. It also makes the task pointers into
smart pointers.
Signed-off-by: flow <flowlnlnln@gmail.com>
Firstly, this abstract away behavior in the mod download models that can
also be applied to other types of resources into a superclass, allowing
other resource types to be implemented without so much code duplication.
For that, this also generalizes the APIs used (currently, ModrinthAPI
and FlameAPI) to be able to make requests to other types of resources.
It also does a general cleanup of both of those. In particular, this
makes use of std::optional instead of invalid values for errors and,
well, optional values :p
This is a squash of some commits that were becoming too interlaced
together to be cleanly separated.
Signed-off-by: flow <flowlnlnln@gmail.com>
This makes it so that the later call to parse the old manifest doesn't
change the class data, so that the new data con continue there and be
reflected on the component list later.
Co-authored-by: Sefa Eyeoglu <contact@scrumplex.net>
Signed-off-by: flow <flowlnlnln@gmail.com>
Since the exact version string is only available in the manifest,
there's no easy way of getting it before commiting to the update, so
there's not much of a good way of showing the updated name in the UI,
and using the displayName is weird and gives some buggy behavior.
We may want to re-enable it in the future if we find a reliable way of
showing the correct info on the UI before starting the update.
Signed-off-by: flow <flowlnlnln@gmail.com>
This allows us to pass to the creation instances their actual pack ID
and version ID, that in Flame's case, are only available before starting
to create an instance.
Signed-off-by: flow <flowlnlnln@gmail.com>
This would cause ODR violations when those headers were included in
other places that also included stuff like "Version.h" (note the
"meta/Version.h"), which can cause problems, especially in LTO.
Signed-off-by: flow <flowlnlnln@gmail.com>
Now that #333 is merged and FS::copy works on non directory copyFile can be removed.
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
If a version on Modrinth has more than a single mod loader associated,
it means that it's possible we might get the wrong file for download,
since individual files don't really have this kind of metadata in the
API response.
So, in such cases, it's best to let the user take care of it instead.
Signed-off-by: flow <flowlnlnln@gmail.com>
In particular, this changes the order so that the instance gets created
before downloading the mods (like other install tasks), and the mod download
directly puts the files in the staging folder (like the others), instead
of that weird makeCached and copy stuff.
This fixes some issues with modpack downloads from FTB, like creating an
instance with no mods in it.
Signed-off-by: flow <flowlnlnln@gmail.com>
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>
