Meaning we don't have to wait for the searches to finish in the
background to finally start the modpack download, when we have already
selected it -_-
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>
On first run, the condition for the wizard would return, before running
updateCapabilities(). This moves that call up, as its only dependency is
the settings system.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
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 avoids loading all settings for all instances when searching for
one with a specific managed pack name.
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>
By now, it's a recurring pattern of wanting to restrict aborting in
certain situations. This avoids further code duplication, and adds a
signal that external users can hook up to to respond to such change.
Signed-off-by: flow <flowlnlnln@gmail.com>
